Atualizar PHP Moodle: 8.3.36 ou 8.4.27 sem Quebrar Plugins

Atualizar PHP Moodle deixou de ser tarefa de "quando der": desde 21 de outubro de 2026, quem roda o AVA em PHP sem as correções do PHP2Shell está exposto a execução remota de código sem login. Neste guia eu mostro qual versão do PHP cada Moodle aceita, como homologar sem derrubar plugins e como deixar o rollback pronto antes de mexer em produção.

TL;DR

• O PHP2Shell (CVE-2026-109618 e CVE-2026-109619) tem nota 9,2 no CVSS 4.0 e não exige autenticação. A correção saiu em 21/10/2026 nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35.
• Moodle 4.5 LTS só aceita até PHP 8.3, então o alvo é 8.3.36. Moodle 5.0 e 5.1 aceitam 8.2 a 8.4: o alvo recomendado é 8.4.27 (ou 8.3.36).
• Antes de atualizar PHP Moodle em produção, separe duas operações: o patch dentro do mesmo branch (8.3.x para 8.3.36) quase não quebra plugin; a troca de branch (8.1 para 8.3) exige homologação.
• Ajustes como memory_limit=-1 reduzem o risco, mas não resolvem. Só a versão corrigida resolve.
• Rollback de PHP é barato se você mantiver o pool antigo instalado. Planeje isso antes, não durante o incidente.

Por que atualizar PHP Moodle virou urgência em outubro de 2026

O PHP2Shell é o apelido de duas falhas no núcleo do PHP. A CVE-2026-109618 é uma corrupção de memória quando a requisição estoura o limite de memória (out-of-memory): o tratamento é interrompido e deixa dados internos meio inicializados. A CVE-2026-109619 é um problema de estado global obsoleto: uma informação da requisição sobrevive depois que a memória dela foi liberada (use-after-free) e contamina a requisição seguinte.

As duas levam a execução remota de código com os privilégios do processo web, sem usuário nem senha. No Moodle, isso abre o config.php (com a senha do banco), o moodledata e os dados de todos os alunos.

A linha do tempo que importa para quem administra o AVA

• 17/10/2026: a Amazon Threat Intelligence registrou uma tentativa de exploração na rede de honeypots dela, quatro dias antes da divulgação, segundo o FAQ da Tenable. A recomendação é investigar logs a partir dessa data, não da divulgação.
• 20/10/2026: os identificadores vazaram em redes sociais e o time de segurança do PHP antecipou a release em um dia.
• 21/10/2026: saíram as versões corrigidas. A Datadog Security Labs passou a ver varredura ampla e não direcionada. A watchTowr relatou tentativas contra as duas CVEs.
• 23/10/2026: a Unit 42, da Palo Alto Networks, atualizou o alerta. A telemetria do Cortex Xpanse aponta mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis. No mesmo dia, o php.net divulgou a CVE-2026-115560, de vetor considerado improvável, com correção prevista para a próxima release regular.

Quem tem correção e quem não tem

Branch do PHP	Situação após o PHP2Shell
8.2, 8.3, 8.4, 8.5	Corrigido em 8.2.35, 8.3.36, 8.4.27 e 8.5.12
7.4, 8.0, 8.1	Só backports mínimos de código-fonte, para quem compila o PHP
5.4 a 7.3	Sem correção nenhuma

Se o seu Moodle ainda roda em PHP 8.1, não existe pacote oficial corrigido. A saída é trocar de branch, e é aí que mora o risco de quebrar plugin.

Matriz de compatibilidade: Moodle 4.5, 5.0 e 5.1 x PHP

Antes de atualizar PHP Moodle, confira o que a sua versão do AVA aceita. A política oficial de PHP do Moodle define um mínimo e um máximo por branch.

Moodle	Suporte de segurança (Moodle HQ)	PHP mínimo	PHP máximo	Alvo pós-PHP2Shell
4.5 LTS	até 04/10/2027	8.1	8.3	8.3.36
5.0	encerrado em 05/10/2026	8.2	8.4	8.4.27 ou 8.3.36, e planejar sair do 5.0
5.1	até 19/04/2027	8.2	8.4	8.4.27 (ou 8.3.36)
5.2	até 04/10/2027	8.3	8.4	8.4.27
5.3 LTS	até 01/10/2029	8.3	8.4 (8.5 em desenvolvimento)	8.4.27

Três leituras práticas para atualizar PHP Moodle sem sair da faixa suportada:

1. Moodle 4.5 não roda em PHP 8.4. A política lista o 8.4 só a partir do Moodle 5.0. Quem está no 4.5 LTS vai para 8.3.36 e ponto.
2. PHP 8.2 é atalho curto. Segundo o calendário oficial do PHP, o 8.2 recebe correções de segurança só até 31/12/2026. Instalar 8.2.35 hoje resolve o PHP2Shell, mas obriga uma nova troca em dois meses.
3. O 8.3 vai até 31/12/2027 e o 8.4 até 31/12/2028. Para Moodle 5.x, o 8.4 dá mais fôlego.

Patch no mesmo branch ou troca de branch?

Essa é a decisão que define o tamanho do trabalho. Um patch dentro do mesmo branch (8.3.30 para 8.3.36) traz só correções: não muda a linguagem, não remove função, não cria deprecation.

A troca de branch (8.1 para 8.3, ou 8.3 para 8.4) muda a linguagem. Plugin escrito há quatro anos, tema customizado e integração caseira podem quebrar. Esse caso pede homologação completa.

Em 8.2 ou 8.3, aplique o patch agora e planeje a troca de branch. Em 8.1 ou abaixo, não há patch: a troca é obrigatória e urgente.

O que quebra plugins quando você troca o branch do PHP

Ao atualizar PHP Moodle trocando de branch, o núcleo raramente é o problema, porque é testado na faixa oficial. O que quebra está fora dele: plugins de terceiros, temas e código próprio. Detalhei a avaliação de cada um em plugins essenciais do Moodle e como checar compatibilidade.

O version.php não fala de PHP

O arquivo version.php de um plugin declara $plugin->requires (versão mínima do Moodle) e, nos plugins mais novos, $plugin->supported (faixa de branches do Moodle). Nenhum dos dois declara versão de PHP. Um plugin "compatível com Moodle 4.5" pode nunca ter sido testado em PHP 8.3. Só teste real responde.

As mudanças de linguagem que mais pegam

• PHP 8.2: criar propriedade dinâmica em objeto passou a gerar aviso de deprecation. Código antigo faz isso o tempo todo. Não quebra, mas enche o log.
• PHP 8.4: parâmetro com valor padrão null sem o tipo marcado como anulável (?string) gera deprecation. Também saíram do núcleo as extensões IMAP, Pspell e OCI8, que agora vivem no PECL. Se algum plugin ou integração depende delas, o erro é fatal.
• Extensões do sistema: cada branch tem pacotes próprios (php8.3-intl, php8.4-intl). Esquecer um pacote, como intl, soap, sodium ou redis, é a causa mais comum de "funcionava ontem".
• php.ini novo: o arquivo de configuração do branch novo vem com os valores padrão. O Moodle exige max_input_vars de pelo menos 5000 e o padrão do PHP é 1000. Sem ajustar, formulários grandes (notas, permissões) perdem campos sem aviso.

Como descobrir o problema antes do aluno

Em homologação, ligue a depuração em nível desenvolvedor e leia o log do PHP-FPM depois de cada roteiro de teste. Procure por Deprecated, Fatal error e Uncaught. Cada linha aponta o arquivo e a linha do plugin culpado.

Ambiente de homologação: o passo que ninguém quer pagar e todo mundo precisa

Homologar é testar a mudança numa cópia fiel da produção antes de aplicar de verdade. Para atualizar PHP Moodle trocando de branch, eu não conheço atalho seguro que pule esta etapa.

Como montar a cópia

1. Mesmo sistema operacional e mesma versão do servidor de produção.
2. Dump do banco de produção e cópia do moodledata. Se o filedir for grande demais, copie a estrutura e uma amostra; o que não pode faltar são os arquivos de curso usados no roteiro de teste.
3. Corte o e-mail. No config.php da cópia, use $CFG->noemailever = true;. Sem isso, o cron da homologação manda notificação de prazo para milhares de alunos reais.
4. Desligue integrações de saída que cobram ou alteram dados: gateway de pagamento, envio por WhatsApp, sincronização com ERP.
5. Instale os dois PHPs lado a lado (por exemplo, php8.1-fpm e php8.3-fpm). O virtual host aponta para o socket de um ou de outro.

O roteiro mínimo de teste

• Login local e por SSO (OAuth2, SAML, LDAP), se houver
• Abrir curso, assistir vídeo, baixar arquivo
• Fazer um questionário do começo ao fim e conferir a nota
• Enviar tarefa com upload e corrigir como professor
• Exportar o livro de notas
• Rodar o cron manualmente: php admin/cli/cron.php
• Testar o app Moodle (web services) e qualquer integração por API
• Abrir os relatórios e plugins pagos mais usados

Antes dos testes, abra Administração do site > Servidor > Ambiente e confirme que tudo aparece em verde. Esse painel aponta extensão faltando e configuração abaixo do exigido.

Passo a passo para atualizar PHP Moodle em produção

Com a homologação aprovada, atualizar PHP Moodle em produção vira execução de roteiro. A sequência que uso:

1. Backup completo e testado: banco, moodledata e código.
2. Aviso aos usuários com antecedência e janela fora do horário de pico.
3. Modo de manutenção: php admin/cli/maintenance.php --enable.
4. Instale o PHP corrigido com as mesmas extensões validadas na homologação e copie os ajustes de php.ini (max_input_vars, memory_limit, upload_max_filesize, post_max_size).
5. Troque o socket do PHP-FPM no virtual host e recarregue o servidor web.
6. Purge de caches: php admin/cli/purge_caches.php. Isso evita cache compilado da versão anterior.
7. Confira o ambiente no painel do Moodle e o phpinfo da versão em uso (php -v no terminal pode mostrar outro binário que não é o do FPM).
8. Rode o roteiro curto de teste e só então saia da manutenção.
9. Reinicie todos os workers do PHP-FPM. As orientações do PHP2Shell reforçam isso: configuração só vale para processos novos.

E se a sua distro diz que a versão é outra?

Ubuntu, Debian e Red Hat costumam aplicar a correção sem mudar o número da versão upstream. A Datadog alerta para isso: o pacote pode estar corrigido mesmo mostrando 8.3.6, por exemplo. Nesse caso, confira o boletim de segurança da distribuição e o changelog do pacote, não o número do php -v.

Rollback: como voltar em minutos sem perder dados

A boa notícia: trocar o PHP não altera o banco do Moodle. Diferente de atualizar o Moodle 4.5 para o 5, em que o upgrade mexe no esquema do banco e voltar exige restaurar backup, a troca de PHP é reversível só repontando o socket.

Deixe o caminho de volta pronto

Quem vai atualizar PHP Moodle precisa ter a volta escrita antes de começar.

• Não desinstale o PHP antigo no dia da troca. Mantenha o pool configurado e parado.
• Documente o comando de volta: qual arquivo do virtual host muda e qual serviço recarregar.
• Defina o gatilho: qual erro justifica voltar (login quebrado, questionário sem salvar) e quem decide.
• Depois de voltar, rode de novo php admin/cli/purge_caches.php.

A armadilha do rollback em outubro de 2026

Voltar para um PHP sem correção reabre o PHP2Shell. Rollback, agora, não pode ser para "o que funcionava". Tem que ser para a versão corrigida do branch anterior. Se o branch anterior é 8.1 ou mais antigo, não existe volta segura: ou você corrige o plugin, ou desativa o plugin, ou isola o servidor até resolver. A CISA chegou a recomendar tirar do ar sistemas em PHP 8.1 ou anterior que não possam ser atualizados.

Mitigações enquanto a atualização não sai (e por que não bastam)

O próprio time do PHP publicou ajustes de configuração para reduzir a exposição. Eles ajudam a ganhar horas, mas não substituem atualizar PHP Moodle para a versão corrigida.

Ajuste	Contra o quê	Limitação
memory_limit=-1, fixado via php_admin_value no pool	CVE-2026-109618	Remove o limite de memória controlável, mas uma falha de alocação ainda pode chegar ao trecho vulnerável. Use limite de memória no container ou cgroup
session.upload_progress.enabled=0	Rota de sessão da CVE-2026-109619	Não cobre outras variantes; a Datadog relata que não protege sozinho. Também é a orientação provisória para a CVE-2026-115560
fatal_error_backtraces=0 (só PHP 8.5)	CVE-2026-109619	Não se aplica a Moodle em 8.3 ou 8.4

Dois cuidados específicos de Moodle. Primeiro, deixar memory_limit=-1 de forma permanente permite que um relatório pesado ou uma restauração de curso consuma toda a RAM do servidor. Segundo, desligar o upload progress não quebra o upload de arquivos do Moodle, mas teste o envio de tarefas mesmo assim.

Quando não atualizar (ainda) e erros caros

Há momentos ruins para atualizar PHP Moodle trocando de branch. Patch de segurança dentro do mesmo branch quase sempre deve entrar logo. Já a troca de branch merece calendário.

Não troque o branch do PHP:

• Na semana de prova, de fechamento de notas ou de matrícula.
• Junto com o upgrade do Moodle. Duas mudanças no mesmo dia tornam impossível saber qual quebrou o quê.
• Sem homologação, só porque "o fornecedor disse que é compatível".

Erros que vejo se repetir:

• Atualizar PHP Moodle só na linha de comando e esquecer o PHP-FPM. O php -v mostra a versão nova e o site continua vulnerável.
• Esquecer o cron. Ele roda com o binário de linha de comando; se apontar para o PHP antigo, tarefas agendadas rodam na versão errada.
• Copiar o php.ini inteiro do branch antigo para o novo, carregando diretivas que já não existem.
• Ignorar o log de deprecation. Hoje é aviso; na próxima versão vira erro fatal.

Se o servidor é uma VPS que ninguém da equipe administra de verdade, vale reler a conta de VPS para Moodle ou hospedagem gerenciada. O PHP2Shell é o tipo de evento em que essa diferença aparece.

Como a Agathas Web resolve isso

Trabalho com Moodle e servidores Linux desde antes da série 2 do AVA, e a rotina de atualização que descrevi acima é a que aplicamos nos ambientes que administramos. No serviço de Moodle da Agathas Web, atualizar PHP Moodle entra como projeto fechado:

• Inventário: versão do Moodle, branch e build do PHP, pacote da distro, lista de plugins e temas, integrações por API e WhatsApp.
• Diagnóstico de exposição: se o ambiente está coberto contra o PHP2Shell e quais mitigações valem enquanto a troca não acontece.
• Homologação clonada com e-mail e integrações cortados, PHP lado a lado e roteiro de teste combinado com a coordenação.
• Correção ou substituição de plugins que quebram no branch novo, com nosso time de desenvolvimento PHP.
• Janela de manutenção em horário combinado, com rollback documentado e testado.
• Revisão de logs a partir de 17/10/2026, para checar sinais de tentativa de exploração.

Como contratar: você fala com a gente pela página de serviços Moodle, conta a versão do Moodle e onde ele está hospedado, e devolvemos o diagnóstico e o plano com prazo. Se preferir não ter mais esse trabalho, a operação pode continuar com a gente na hospedagem gerenciada.

Conclusão: corrija agora, troque de branch com método

O caminho seguro para atualizar PHP Moodle tem duas velocidades. Patch no mesmo branch (para 8.3.36 ou 8.4.27) entra agora, porque o risco de compatibilidade é mínimo e a exploração já começou. Troca de branch, obrigatória para quem está em 8.1 ou abaixo, passa por homologação, roteiro de teste e rollback para uma versão também corrigida.

Se você não sabe qual PHP o seu AVA roda de verdade, o primeiro passo para atualizar PHP Moodle é descobrir. Peça um diagnóstico em serviços Moodle da Agathas Web e saia da dúvida antes que um scanner tire por você.