Moodle PHP Legado Após o PHP2Shell: Risco, Custo e Plano

Um Moodle PHP legado — aquele AVA que ainda roda em PHP 7.4, 8.0 ou 8.1 — virou o servidor mais exposto da sua instituição na semana de 21 de outubro de 2026. O PHP2Shell abriu execução remota de código sem login, e o PHP só lançou correção oficial para as versões 8.2 a 8.5. Neste guia eu mostro o que os backports mínimos resolvem, quanto custa ficar parado e o plano de migração que eu seguiria.

TL;DR

• O PHP2Shell são duas falhas no núcleo do PHP: CVE-2026-109618 (corrupção em out-of-memory) e CVE-2026-109619 (estado global obsoleto entre requisições). Nota 9,2 no CVSS 4.0, exploráveis sem autenticação.
• Correção oficial saiu em 21/10/2026 nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para 7.4, 8.0 e 8.1 existem só backports mínimos de código-fonte, sem binário oficial. De 5.4 a 7.3, nenhuma correção.
• As mitigações de php.ini reduzem a superfície, mas o próprio PHP avisa: não existem mitigações completas.
• Um Moodle 3.9, 3.11, 4.0 ou 4.1 não roda em PHP 8.2+. A saída real é subir o Moodle para o 4.5 LTS (suporte de segurança até 06/10/2027) em PHP 8.3.36.
• Ficar parado custa incidente, LGPD e reputação. A migração custa semanas de trabalho planejado.

O que é o PHP2Shell e por que ele atinge o Moodle PHP legado

O PHP2Shell não é um bug do Moodle. É um bug do interpretador PHP que roda embaixo dele — por isso atualizar plugin, tema ou o próprio Moodle não fecha a porta.

Segundo o aviso oficial do php.net de 21/10/2026, são duas falhas:

• CVE-2026-109618 (corrupção em OOM): quando a memória acaba no meio de uma requisição, o PHP é interrompido com dados internos só parcialmente inicializados. A limpeza da requisição trata esse lixo como válido.
• CVE-2026-109619 (estado global obsoleto): um estado interno da requisição sobrevive depois que a memória dele foi liberada — um use-after-free (uso de memória já devolvida ao sistema) que vaza de uma requisição para a seguinte.

O FAQ da Tenable resume o pior ponto: segundo o PHP, as duas podem ser exploradas por um atacante remoto sem autenticação. Não precisa de conta de aluno, de professor, de nada.

A linha do tempo que importa

Data	Fato
17/10/2026	Amazon Threat Intelligence registra tentativa de exploração na rede de honeypots MadPot, quatro dias antes da divulgação
20/10/2026	Identificadores vazam; o PHP publica aviso prévio e antecipa a release
21/10/2026	Saem 8.5.12, 8.4.27, 8.3.36 e 8.2.35, mais os backports para 7.4, 8.0 e 8.1
21/10/2026	Cortex Xpanse, da Palo Alto, conta mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis (Unit 42)
23/10/2026	O PHP publica alerta informativo sobre o CVE-2026-115560, um vetor improvável ligado ao upload progress de sessão, com correção prevista na próxima release regular

O detalhe que deveria tirar o sono de quem administra EAD: a Unit 42 relata um ataque contra um órgão de governo europeu em que, em menos de duas horas após a exploração inicial, o invasor obteve hashes de senha e segredos de MFA e tentou escalar até administrador de domínio. Um Moodle guarda exatamente isso — senhas de milhares de alunos, tokens de integração, chaves de API.

Qual PHP o seu Moodle roda (e por que ele está preso)

Quase todo Moodle PHP legado que encontro não está assim por descuido. Está presa porque a versão do Moodle trava a versão do PHP. A tabela oficial de compatibilidade da MoodleDocs deixa isso claro:

Versão do Moodle	PHP suportado	Recebe a correção oficial do PHP2Shell?
3.9	7.2 a 7.4	Não — só backport mínimo (7.4) ou nada (7.2/7.3)
3.11 / 4.0	7.3 a 8.0	Não — só backport mínimo (7.4/8.0)
4.1 LTS	7.4 a 8.1	Não — só backport mínimo
4.2 / 4.3	8.0 a 8.2	Sim, se rodar em 8.2.35
4.4 / 4.5 LTS	8.1 a 8.3	Sim, em 8.2.35 ou 8.3.36
5.0 / 5.1	8.2 a 8.4	Sim

Leia a coluna do meio com atenção. Num Moodle PHP legado em versão 4.1 não aceita PHP 8.2. Trocar só o PHP quebra o AVA; manter o PHP deixa o AVA aberto. Esse é o beco sem saída do legado.

E há um agravante: o Moodle 4.1 LTS saiu do suporte de segurança em 08/12/2025. Quem está nele já acumulava falhas do próprio Moodle sem correção antes mesmo do PHP2Shell.

Como descobrir em dois minutos

1. No Moodle, vá em Administração do site → Notificações: a versão aparece no rodapé.
2. Em Administração do site → Servidor → Informações do PHP, confira a linha PHP Version.
3. No servidor, rode php -v e confira a versão do PHP-FPM que atende o site. Já peguei servidor com PHP 8.3 na linha de comando e FPM 7.4 servindo o Moodle.

Backports mínimos: o que eles cobrem e o que deixam de fora

O php.net foi direto: "PHP 8.1 and older no longer receive updates from the PHP project". Para ajudar quem não pode subir de versão, a equipe de segurança publicou backports mínimos de código-fonte para 7.4, 8.0 e 8.1 — branches no GitHub do php-src, sem pacote, sem binário, sem release.

Para um Moodle PHP legado em produção, isso significa:

• Você compila o PHP. Alguém precisa aplicar o patch, compilar com as mesmas extensões que o Moodle exige (intl, sodium, zip, gd, soap, mbstring…) e substituir o binário em produção.
• Cobre só essas duas CVEs. Todo o resto que foi corrigido depois do fim de vida da sua versão continua aberto.
• Não há próxima vez garantida. O CVE-2026-115560, de 23/10, já será tratado "na próxima release regular" — e versões fora de suporte não têm release regular.

Quando o backport faz sentido

Faz sentido como ponte de dias ou semanas, enquanto a migração do Moodle é executada. Também faz sentido via fornecedor: a Tenable registra que distribuições Linux e fornecedores de LTS receberam os patches antes, então Debian, Red Hat e similares podem ter pacote corrigido para a versão que você usa. Confira o aviso de segurança da sua distro.

Quando NÃO faz sentido

Não faz sentido como estratégia. Se o plano da instituição é "aplicar o backport e esquecer", o Moodle PHP legado vai continuar no mesmo lugar no próximo alerta — e o próximo alerta já foi publicado.

Mitigações de php.ini no Moodle PHP legado: ajudam, mas cobram um preço

O PHP listou mitigações para quem não consegue atualizar na hora. Todas reduzem risco; nenhuma resolve. Nas palavras da própria release: "There are no complete mitigations, updating is the only safe choice."

memory_limit=-1 contra o CVE-2026-109618

A recomendação é memory_limit=-1, aplicado de forma que a aplicação não consiga sobrescrever — php_admin_value[memory_limit] = -1 no pool do FPM. Junto, post_max_size baixo: 8M sem uploads, 32M com uploads.

No Moodle PHP legado em servidor único, isso tem efeito colateral sério:

• Sem teto de memória, um backup de curso grande ou um relatório pesado pode consumir toda a RAM. No servidor tudo-em-um (web + MariaDB na mesma máquina), quem morre primeiro costuma ser o banco, derrubado pelo OOM killer do Linux.
• post_max_size de 32M quebra restauração de arquivos .mbz e envio de vídeos maiores pela interface. Restaurações grandes passam a ser feitas pelo servidor.
• O PHP pede para não substituir por RLIMIT_AS ou RLIMIT_DATA, porque esses limites podem disparar justamente a falha de alocação vulnerável.

A saída é dimensionar pm.max_children do FPM pela RAM disponível e, se possível, isolar o PHP em container ou cgroup com limite — a Tenable cita isso como fronteira de disponibilidade, não como correção.

session.upload_progress.enabled=0 contra o CVE-2026-109619

Desligar o upload progress de sessão bloqueia os caminhos confirmados do CVE-2026-109619 — e, segundo o alerta de 23/10, também o vetor do CVE-2026-115560. Tem que ir no php.ini ou no pool do FPM e exige reiniciar todos os workers. ini_set() e .user.ini não servem.

O núcleo do Moodle envia arquivos pelo seletor de arquivos via AJAX, sem depender dessa barra de progresso nativa do PHP. Mesmo assim, valide em homologação: plugin de terceiro pode depender dela.

O ajuste fatal_error_backtraces=0 só existe no PHP 8.5 — irrelevante para quem está em 7.4 a 8.1. E esconder erros com display_errors ou @ não ajuda em nada.

Quanto custa ficar parado com um Moodle PHP legado

Ninguém publica uma tabela de preço de incidente em AVA, e eu não vou inventar uma. Mas quem mantém um Moodle PHP legado precisa olhar a conta inteira. Dá para listar, com base legal, o que entra nela.

Custos diretos de um incidente

• Indisponibilidade: prova online, matrícula e emissão de certificado param. Em semana de avaliação, isso vira reembolso, reaplicação de prova e atendimento em massa.
• Resposta a incidente: perícia, reinstalação limpa do servidor, troca de todas as credenciais, revisão de integrações. É trabalho emergencial, cobrado como emergencial.
• LGPD: a Resolução CD/ANPD nº 15/2024 exige comunicar incidente relevante à ANPD e aos titulares em até três dias úteis. O art. 52 da Lei 13.709/2018 prevê multa de até 2% do faturamento no Brasil, limitada a R$ 50 milhões por infração.

Custos que não aparecem na hora

• Reputação: aluno que recebe aviso de vazamento lembra disso na rematrícula.
• Contratos B2B: universidade corporativa e cliente de treinamento costumam ter cláusula de segurança. Um incidente vira renegociação.
• Dívida técnica composta: cada mês parado aumenta o salto. Sair do 3.9 hoje exige mais degraus do que exigia há dois anos.

O que custa migrar

Tirar um Moodle PHP legado do lugar não é barato, mas é previsível. O esforço cresce com quatro variáveis: distância de versão, quantidade de plugins de terceiros, tema customizado e — o maior vilão — alterações feitas direto no código do núcleo. Um AVA limpo com poucos plugins sobe rápido. Um AVA com o core editado à mão exige auditoria antes de qualquer data.

O plano de migração que eu seguiria

O Moodle não deixa pular degraus à vontade. A documentação de upgrade do 4.5 é clara: só se chega ao 4.5 a partir do 4.1.2 ou superior. Quem tem um Moodle PHP legado em 3.9, 3.11 ou 4.0 precisa passar pelo 4.1 primeiro.

Etapa 0 — Conter (primeiras 48 horas)

• Aplicar pacote corrigido da distro ou backport compilado, se houver.
• Aplicar as mitigações do php.ini com os cuidados acima e reiniciar todos os workers.
• Colocar o AVA atrás de WAF — a Cloudflare publicou regras para o PHP2Shell, que ela mesma chama de paliativo.
• Procurar sinais de exploração nos logs a partir de 17/10/2026, a primeira data com tentativa registrada.
• Trocar segredos que estejam no config.php e nas integrações se houver qualquer indício.

Etapa 1 — Inventário (semana 1)

Listar versão exata, plugins (com versão e compatibilidade com o 4.5), tema, customizações no core, integrações e tamanho do moodledata. É aqui que se descobre se o Moodle PHP legado sai em duas semanas ou em dois meses.

Etapa 2 — Homologação em cópia (semanas 1 a 3)

1. Clonar banco e moodledata para um ambiente isolado.
2. 3.9 / 3.11 / 4.0 → 4.1.x ainda em PHP 7.4 a 8.1.
3. 4.1.x → 4.5 LTS, trocando o PHP para 8.1 no meio do caminho e depois para 8.3.36.
4. Rodar a verificação de ambiente, testar prova, nota, certificado, pagamento e SSO.

Se o AVA usa login por Google ou Microsoft, revise as integrações nesse momento — o guia de OAuth2 no Moodle 5.3 mostra o que muda quando você seguir para a próxima LTS.

Etapa 3 — Virada (uma janela de manutenção)

Modo manutenção, backup verificado, upgrade em produção com o roteiro ensaiado, smoke test e reabertura. Com a homologação bem feita, a virada cabe numa madrugada.

Por que 4.5 e não 5.x

O 4.5 LTS tem suporte de segurança até 06/10/2027 e aceita PHP 8.3. O 5.0 já saiu do suporte de segurança em 05/10/2026, e o 5.1 vai pelo mesmo caminho — explico o calendário no post sobre o fim do suporte do Moodle 5.1. Para quem tira um Moodle PHP legado do ar, o 4.5 é o degrau estável; o 5.3 LTS vem depois, sem pressa.

Armadilhas comuns na migração

• Atualizar só o PHP. Um Moodle PHP legado em 4.1 não sobe no PHP 8.2. O erro aparece na verificação de ambiente — ou, pior, em tela branca.
• Esquecer o FPM. O apt upgrade atualiza o CLI e o FPM antigo segue servindo o site.
• Plugin abandonado. Plugin sem versão para o 4.5 precisa ser substituído, reescrito ou removido antes da virada, não depois.
• Sem rollback. Upgrade de Moodle altera o banco; não existe "desfazer". Backup de banco e moodledata, testado, antes de começar.
• Cron parado. Depois do upgrade, tarefas agendadas acumuladas podem travar o servidor no primeiro minuto.
• Servidor errado. Muita instituição descobre na migração que a VPS não comporta o Moodle novo. Comparo os dois cenários em VPS para Moodle ou hospedagem gerenciada.

Como a Agathas Web resolve isso

Trabalho com Moodle há mais de 15 anos, tenho a Moodle Developer Certification e opero servidores Linux de ambientes de EAD no dia a dia. Para um Moodle PHP legado, o serviço de migração e sustentação de Moodle funciona assim:

1. Diagnóstico gratuito: levantamos versão do Moodle, PHP, FPM, plugins, tema, customizações e integrações. Você recebe o tamanho real do problema.
2. Contenção imediata, se necessário: pacote corrigido ou backport, mitigações de php.ini ajustadas ao Moodle (sem derrubar backup e restore) e revisão de logs desde 17/10.
3. Proposta técnica: documento com caminho de versões, plugins a substituir, infraestrutura, cronograma e investimento.
4. Migração em homologação e virada: cada degrau testado em cópia, com roteiro, backup verificado e janela combinada.
5. Sustentação contínua: SLA mensal com atualizações de segurança, monitoramento e backup verificado — para o próximo alerta não virar emergência.

Você continua dono dos dados, do tema e dos plugins. Somos uma empresa independente de serviços, com suporte em português, e quem atende entende o código do Moodle. Para começar, peça o diagnóstico na página de serviços de Moodle da Agathas Web ou fale conosco pelo WhatsApp.

Conclusão: o PHP2Shell só antecipou a conta

O Moodle PHP legado já era um risco antes de 21/10/2026: versão do Moodle fora de suporte, PHP sem correção, plugins parados no tempo. O PHP2Shell transformou esse risco em uma janela de exploração sem login, com 22,6 milhões de instâncias expostas na contagem da Unit 42.

O caminho seguro tem três passos: conter agora, migrar para o Moodle 4.5 LTS em PHP 8.3.36 nas próximas semanas e manter o ambiente com sustentação contínua. Se você quer saber em que degrau o seu AVA está e quanto falta para sair dele, solicite o diagnóstico em /servicos/moodle.