PHP2Shell Moodle: o Que o Administrador do AVA Faz Agora

O PHP2Shell Moodle é o tipo de alerta que não espera a próxima janela de manutenção: duas falhas críticas no próprio PHP permitem executar código no servidor sem login nenhum, e todo AVA Moodle roda em cima desse PHP. Neste guia eu mostro, na ordem em que faço no terminal, como verificar a versão, aplicar o patch, reiniciar o PHP-FPM e procurar sinais de invasão.

TL;DR

• PHP2Shell é o apelido de duas falhas no PHP (CVE-2026-109618 e CVE-2026-109619), com nota CVSS 4.0 de 9.2 e exploração sem autenticação. O Moodle não tem culpa, mas é atingido porque roda sobre o PHP.
• A correção saiu em 21/10/2026 nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Do 7.4 ao 8.1 só há backports mínimos de código-fonte; do 5.4 ao 7.3 não há correção.
• Atualizar o pacote não basta: é preciso reiniciar o PHP-FPM (ou o Apache, se usar mod_php) para os workers carregarem o binário novo.
• As mitigações por php.ini reduzem o risco, mas não resolvem. Houve tentativa de exploração já em 17/10, então investigue a partir dessa data.
• No cenário PHP2Shell Moodle mais difícil, o AVA está em PHP 8.1 ou anterior, e o problema vira projeto: subir de PHP exige checar a compatibilidade da versão do Moodle.

O que é o PHP2Shell e por que ele chega ao seu Moodle

Trabalho com Moodle há mais de 15 anos, e quase toda vulnerabilidade que tira o sono de um gestor de EAD está em plugin, tema ou configuração. O PHP2Shell é diferente. A falha está no interpretador PHP, a camada que executa cada página do AVA. Não importa se o seu Moodle está na última versão: se o PHP embaixo dele está vulnerável, o servidor está exposto.

Por isso, quando alguém pergunta sobre PHP2Shell Moodle em fórum de administradores, a resposta certa começa no servidor, não no painel do AVA.

As duas falhas em uma frase cada

• CVE-2026-109618 (OOM Corruption): quando uma alocação de memória falha no meio da inicialização da requisição, o PHP depois limpa esse estado incompleto como se fosse válido. Daí sai a execução remota de código (RCE, na sigla em inglês).
• CVE-2026-109619 (Stale Global State): um use-after-free, ou seja, o uso de memória que já foi liberada. Restos de uma requisição são reaproveitados pela requisição seguinte no mesmo worker. O PHP lista também vazamento de memória como impacto confirmado.

Segundo a Tenable, as duas receberam nota 9.2 no CVSS 4.0 pela equipe de segurança do PHP. Os identificadores que circularam antes do anúncio traziam um 10.0, que a PHP Foundation diz ser incorreto.

A linha do tempo que importa para quem administra AVA

• 17/10/2026: a Amazon registrou uma tentativa de exploração no seu honeypot MadPot, quatro dias antes da divulgação pública.
• 20/10/2026: os detalhes vazaram nas redes sociais antes da data combinada (22/10), como relatou a watchTowr. O PHP antecipou o lançamento.
• 21/10/2026: saem as versões corrigidas, e a CISA, agência de cibersegurança dos EUA, pede atualização imediata.
• 23/10/2026: o PHP publica um alerta adicional, o CVE-2026-115560, que explico mais abaixo.

A escala também assusta. A Palo Alto Networks contou mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis, segundo a TechTarget. Isso significa que o PHP2Shell Moodle alcança todo servidor de AVA com IP público.

PHP2Shell Moodle e as versões em risco

A pergunta que eu recebo primeiro é se o Moodle da instituição está vulnerável. A resposta depende do PHP, não do Moodle. A tabela abaixo cruza o ramo do PHP com o status da correção e com as versões do Moodle que aceitam aquele PHP, segundo a documentação oficial do Moodle.

Ramo do PHP	Status do PHP2Shell	Moodle que roda nesse PHP	O que fazer
8.5	Corrigido na 8.5.12	Confira o suporte da sua versão nas notas de release	Atualizar para 8.5.12 e reiniciar
8.4	Corrigido na 8.4.27	5.0, 5.1 e 5.2	Atualizar para 8.4.27 e reiniciar
8.3	Corrigido na 8.3.36	4.5 LTS, 5.0, 5.1 e 5.2	Atualizar para 8.3.36 e reiniciar
8.2	Corrigido na 8.2.35 (ramo encerra em 31/12/2026)	4.5 LTS, 5.0 e 5.1	Atualizar agora e planejar a saída do 8.2
7.4 a 8.1	Só backports mínimos de código-fonte	4.5 LTS (no 8.1) e versões antigas	Pacote da distribuição com backport, ou migrar de PHP
5.4 a 7.3	Sem correção	Moodle muito antigo	Isolar da internet e migrar

Duas lições saem dessa tabela. A primeira: um Moodle 4.5 LTS em PHP 8.1, combinação comum em instituição que fez o último upgrade às pressas, não tem mais release oficial do PHP. A saída é ir para o 8.2 ou o 8.3, que o 4.5 aceita. A segunda: um Moodle anterior ao 4.5, que só roda em PHP 8.1 ou mais antigo, transforma o PHP2Shell Moodle em projeto de atualização de versão, não em patch de dez minutos.

Passo 1: descubra qual PHP o seu Moodle usa de verdade

Antes de qualquer correção do PHP2Shell Moodle, você precisa saber qual binário atende o site. O erro mais comum aqui é rodar php -v no terminal e dar o assunto por encerrado. O php -v mostra o PHP de linha de comando (CLI). O site é servido pelo PHP-FPM ou pelo módulo do Apache, que podem ter outra versão e outro php.ini. A Datadog faz exatamente esse alerta.

Três formas de checar o PHP que serve o AVA:

1. Pelo próprio Moodle: em Administração do site > Servidor > Informações do PHP (o admin/phpinfo.php). A primeira linha traz a versão, e o campo Server API diz se é FPM/FastCGI ou Apache 2.0 Handler (mod_php).
2. Pelo gerenciador de pacotes: no Debian e no Ubuntu, dpkg -l | grep php8 lista a versão exata de cada pacote instalado, incluindo o php8.x-fpm.
3. Pelo processo em execução: ps aux | grep php-fpm mostra qual pool está de pé. Se aparecerem dois ramos (por exemplo, 8.1 e 8.3), confirme no vhost do Nginx ou do Apache qual socket o Moodle usa.

Um detalhe pesa na prioridade: o risco é maior com mod_php. A Tenable relata que, nesse modo, há exploit demonstrado que dispara com uma requisição não autenticada antes de qualquer código da aplicação rodar. PHP-FPM, php-cgi, FrankenPHP e LiteSpeed também estão no escopo. Ninguém está dispensado, mas quem roda Moodle em Apache com mod_php vai para o topo da fila: no PHP2Shell Moodle o mod_php é a prioridade número um.

Passo 2: aplique o patch do PHP2Shell Moodle sem quebrar o AVA

Antes de tocar em produção, faça duas coisas que levam dez minutos: um backup do banco e do config.php, e uma anotação dos módulos PHP instalados (php -m). Atualização de segurança dentro do mesmo ramo (8.3.x para 8.3.36, por exemplo) raramente quebra o Moodle, mas sem esse registro você não sabe o que mudou se algo der errado.

Servidor próprio (Debian, Ubuntu, RHEL)

Atualize os pacotes do ramo que você já usa, no FPM e no CLI. O cron do Moodle roda pelo PHP CLI e precisa do binário corrigido tanto quanto o site. Atenção a uma pegadinha: distribuições como Debian, Ubuntu e Red Hat costumam aplicar o backport da correção sem mudar o número da versão. A Red Hat, por exemplo, publicou o boletim RHSB-2026-013 cobrindo os três CVEs. Nesses casos, confira o changelog do pacote ou o rastreador de segurança da distribuição, e não só o php -v.

Moodle em contêiner Docker

Atualizar o host não corrige o contêiner. É preciso trocar a imagem base por uma com o PHP corrigido, reconstruir e subir de novo. Imagem com tag fixa antiga é o caso clássico do servidor que todo mundo acha que está atualizado.

Hospedagem compartilhada ou painel (cPanel, Plesk, HestiaCP)

Você depende do provedor. Abra um chamado sobre o PHP2Shell Moodle pedindo, por escrito, a versão exata do PHP que serve o seu domínio e a confirmação do reinício dos workers. Se o painel deixa escolher o PHP por domínio, selecione o ramo corrigido e teste o AVA logo depois.

PHP 8.1 ou mais antigo

Aqui não existe atalho seguro. As opções são três: usar um pacote de distribuição ou de fornecedor LTS que tenha feito o backport, compilar o PHP com os backports mínimos publicados pelo projeto, ou migrar para um PHP suportado. Para quem está no Moodle 4.5 LTS, a migração natural é para o PHP 8.3. Para versões mais antigas, o caminho passa por migrar o Moodle de servidor já com a stack nova, conferindo os requisitos de servidor para Moodle 5.x.

Passo 3: reinicie o PHP-FPM e tudo que roda PHP

Esse é o passo que mais vejo ser esquecido. Sem reinício, a correção do PHP2Shell Moodle fica só no disco. O PHP-FPM mantém workers vivos entre requisições, e enquanto eles não forem recriados continuam executando o código antigo carregado na memória. A watchTowr é direta: reinicie todo worker PHP depois de atualizar.

Na prática, o reinício do PHP2Shell Moodle cobre:

• PHP-FPM: systemctl restart php8.3-fpm (troque pelo seu ramo). Prefira restart a reload nesse caso, para garantir que todos os processos sejam recriados.
• Apache com mod_php: reinicie o Apache, porque o PHP mora dentro dele.
• Contêineres: recrie o contêiner com a imagem nova. Reiniciar o contêiner antigo não troca o binário.
• Workers de fila e cron: processos longos de CLI também precisam ser reiniciados.

Depois do reinício, volte a Informações do PHP no Moodle e confirme a versão. Teste o login, o envio de arquivo em uma tarefa e um questionário. O reinício do FPM derruba as requisições em andamento por alguns segundos; fora do horário de prova, isso não é problema. Em semana de avaliação, avise a coordenação e escolha a madrugada, mas não adie para depois da prova.

Mitigações temporárias: o que elas fazem e o que não fazem

Se você não consegue atualizar hoje, o advisory do PHP lista ajustes de configuração. Eles servem para atravessar as horas entre o alerta PHP2Shell Moodle e a janela de atualização. Todas as fontes técnicas que consultei, da Tenable à Datadog, repetem o mesmo aviso: os ajustes reduzem a exposição, mas não tornam a instalação segura.

Os três ajustes

• memory_limit=-1, definido de forma que a aplicação não consiga sobrescrever, contra o CVE-2026-109618.
• session.upload_progress.enabled=0, contra o CVE-2026-109619.
• fatal_error_backtraces=0, também contra o CVE-2026-109619, apenas no PHP 8.5.

Depois de qualquer mudança, reinicie os workers, como no passo 3.

O que muda no Moodle

O Moodle eleva o próprio limite de memória em operações pesadas, como backup e restauração de curso. Por isso, um memory_limit comum no php.ini não basta: no PHP-FPM, use php_admin_value[memory_limit] = -1 no pool, valor que a aplicação não consegue alterar. O preço é que um script descontrolado pode consumir toda a RAM. Compense limitando o número de workers (pm.max_children) e a memória do contêiner ou do cgroup, lembrando que o próprio PHP diz que isso é fronteira de disponibilidade, não mitigação completa.

Já o upload progress é um recurso nativo do PHP do qual o Moodle não depende para o envio de arquivos. Desligar costuma ser seguro, mas teste o envio de uma tarefa depois.

WAF ajuda, mas tem limite

A Cloudflare publicou regras de WAF para os vetores conhecidos e chama isso de paliativo, válido só para o tráfego que passa por ela. Um atacante que descobre o IP de origem do servidor passa por fora.

E o CVE-2026-115560?

Em 23/10/2026, o PHP publicou um alerta informativo, o CVE-2026-115560. Ele só se aplica quando a aplicação define o session.serialize_handler como php_binary ou php_serialize, troca para php em tempo de execução antes do session_start() e mantém o upload progress ligado. O PHP chama essa configuração de improvável na prática, não há exploração relatada e a correção virá na próxima release regular, conforme a The Hacker News. A mitigação é a mesma: session.upload_progress.enabled=0. Quem já aplicou não precisa fazer mais nada.

Passo 4: procure sinais de invasão no servidor do Moodle

Atualizar fecha a porta, mas não diz se alguém entrou antes. Como a Amazon viu tentativa de exploração já em 17/10, a recomendação da Tenable é investigar a partir dessa data, e não da divulgação. Este é o checklist PHP2Shell Moodle que eu sigo.

No sistema operacional

• Processos filhos do PHP: a Huntress orienta procurar php-fpm, php-cgi, httpd ou apache2 iniciando sh, bash, python, perl, curl, wget ou nc. A Datadog chama o shell aberto pelo worker PHP de a evidência mais direta de exploração bem-sucedida.
• Comandos de reconhecimento rodados pelo usuário do servidor web, como whoami, id e uname -a, e padrões de reverse shell como /dev/tcp/, mkfifo e fsockopen.
• Cron e contas: crontab -l -u www-data e novos usuários no sistema.

No Moodle

• Arquivos PHP novos: find /caminho/do/moodle -name '*.php' -newermt 2026-10-17 lista o que foi criado ou alterado depois de 17/10. Cruze com as atualizações que você mesmo fez.
• O moodledata: a pasta de dados nunca deveria conter arquivo .php executável. Qualquer um ali é suspeito.
• Administradores: confira em Administração do site > Usuários > Permissões > Administradores do site se apareceu alguém novo, e revise as contas criadas recentemente.
• Plugins desconhecidos: compare as pastas local/, mod/ e blocks/ com a lista da Visão geral dos plugins.

Nos logs

A Datadog lista sinais úteis no log de erro: Allowed memory size of 16777216 bytes exhausted com Unknown on line 0, e crashes exit signal Segmentation fault (11) no Apache. No log de acesso, procure envios multipart com os campos PHPSESSID e PHP_SESSION_UPLOAD_PROGRESS. Na investigação do PHP2Shell Moodle, um erro de memória isolado não prova ataque; vários juntos, em sequência, merecem investigação.

Se encontrar sinal de comprometimento, isole o servidor e preserve os logs antes de limpar qualquer coisa. Reinstalar por cima apaga a evidência e não garante que o invasor saiu.

Erros comuns e quando não fazer

Na resposta ao PHP2Shell Moodle, algumas decisões parecem prudentes e pioram a situação. As que mais vejo:

• Confiar só no php -v. O CLI não é necessariamente o PHP do site.
• Atualizar e não reiniciar. O pacote novo fica no disco e o worker antigo continua atendendo.
• Pular de ramo do PHP às pressas. Não troque 8.1 por 8.4 em um Moodle 4.5 LTS só para ficar no mais novo: o 4.5 aceita PHP até o 8.3. Dentro do mesmo ramo, atualize hoje; troca de ramo pede teste em homologação.
• Tratar mitigação como solução. memory_limit=-1 e upload progress desligado compram tempo, não segurança.
• Desligar o AVA sem comunicar. A CISA recomenda tirar do ar sistemas que não podem ser atualizados ou que rodam PHP 8.1 ou anterior. Se for o seu caso, faça, mas com aviso para alunos e tutores e uma data de retorno.
• Esquecer os ambientes esquecidos. Homologação, Moodle antigo de arquivo, subdomínio de teste: tudo que está na internet com PHP entra no inventário do PHP2Shell Moodle antes de você dar o caso por encerrado.

Como a Agathas Web resolve isso

O PHP2Shell Moodle expõe o ponto fraco de quem hospeda o AVA sem equipe dedicada: a correção existe, mas alguém precisa saber que ela saiu, aplicar no binário certo, reiniciar os workers, testar o AVA e investigar se houve intrusão. Na hospedagem Moodle gerenciada da Agathas Web, esse trabalho é nosso.

O que está incluso na prática:

• Stack mantida por quem opera Moodle: PHP-FPM com pool dedicado por instância, OPcache, Redis, MariaDB e Nginx afinados para o Moodle, com o PHP no ramo compatível com a sua versão do AVA.
• Atualização de segurança com teste: patch aplicado, workers reiniciados e verificação do AVA depois. Mudanças maiores, como troca de ramo do PHP ou de versão do Moodle, passam por staging antes de tocar a produção.
• Camadas de proteção: Cloudflare WAF com proteção contra DDoS, Fail2ban e rate limit nas rotas críticas.
• Monitoramento e backup: Sentry, Grafana e UptimeRobot sobre a plataforma, backup incremental do banco a cada 15 minutos e restauração testada.
• Suporte sênior em português: canal direto pelo WhatsApp e por e-mail, com resposta em até 15 minutos para incidentes críticos.

Como funciona a contratação: você fala com a equipe, fazemos um diagnóstico do ambiente atual (versão do Moodle, PHP, plugins e tamanho do moodledata) e planejamos a migração para a nossa stack. Se o seu Moodle está preso em PHP antigo, a migração resolve as duas coisas de uma vez. Se você ainda está decidindo entre manter um servidor próprio ou terceirizar, este comparativo de VPS para Moodle ou hospedagem gerenciada mostra o custo real de cada caminho.

Conclusão: o que fazer hoje

O roteiro do PHP2Shell Moodle cabe em uma tarde: confirme o PHP que serve o AVA, atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou para o pacote com backport da sua distribuição), reinicie o PHP-FPM e o cron e investigue desde 17/10. Se o seu servidor está em PHP 8.1 ou anterior, trate como migração urgente, não como patch.

E se essa tarde não existe na sua agenda, ou se você descobriu agora que não sabe quem atualiza o PHP do seu AVA, é exatamente o caso de conhecer a hospedagem Moodle da Agathas Web. A próxima falha crítica vai chegar; a diferença é quem estará olhando o servidor quando ela chegar.