PHP2Shell: o que fazer agora no seu Moodle

Em 22 de outubro de 2026, a equipe da Moodle HQ avisou a comunidade que tirou do ar, por precaução, os próprios sites públicos por causa do PHP2Shell, e pediu a quem hospeda o próprio Moodle que planeje a atualização do PHP imediatamente. O aviso está no fórum oficial do moodle.org. Este guia explica o que isso significa para quem tem Moodle numa empresa ou instituição.

O que é o PHP2Shell, a falha grave no PHP

São duas vulnerabilidades no próprio PHP, a linguagem em que o Moodle é escrito, corrigidas pelo projeto PHP em 21 de outubro de 2026:

• CVE-2026-109618: uma falha no tratamento de falta de memória que pode deixar dados internos da requisição corrompidos.
• CVE-2026-109619: um estado interno que sobrevive de uma requisição para outra depois de a memória ter sido liberada.

As duas foram classificadas pelo projeto PHP como críticas (nota 9,2 no CVSS 4.0) e permitem execução remota de código sem autenticação: uma requisição de quem nem tem login pode bastar, antes de qualquer código do Moodle rodar. O PHP lista como afetadas todas as instalações que atendem requisições web, inclusive PHP-FPM, Apache com mod_php, php-cgi e LiteSpeed, com risco maior no mod_php. Empresas de segurança relataram tentativas de exploração já nos dias da divulgação. No Brasil, a vulnerabilidade no PHP levou até a Anatel a tirar um sistema do ar por precaução: contamos em falha grave no PHP: o que fazer se o servidor não foi atualizado.

Por que afeta o Moodle

O Moodle roda em cima do PHP. Se o PHP do servidor é vulnerável, o Moodle está exposto, por mais atualizado que esteja. Por isso:

• Atualizar o Moodle não corrige o PHP2Shell. A correção é no servidor.
• Plugins e configuração do Moodle não protegem, porque o ataque acontece antes de o código do Moodle ser executado.
• Quem hospeda o próprio Moodle é o responsável pela atualização: é o recado da Moodle HQ.

Universidades brasileiras restringiram o Moodle

No Brasil, o alerta chegou a quem usa Moodle em escala. O Centro Integrado de Segurança Cibernética do Governo Digital (CISC GOV.BR) publicou em 21/10/2026 um alerta aos órgãos federais pedindo atualização imediata do PHP e, se ela não fosse possível, restrição temporária do acesso pela internet (alerta do CISC GOV.BR). Na prática:

• UFCG: a Universidade Federal de Campina Grande restringiu à rede interna os sistemas em PHP, entre eles o Moodle, até aplicar e validar as atualizações. Fora da universidade, só por VPN (comunicado da UFCG).
• UFSC: a Universidade Federal de Santa Catarina manteve o seu Moodle aberto pela internet só para consulta; a entrega de trabalhos passou a exigir VPN (comunicado da UFSC).

Se instituições com equipe de TI própria preferiram fechar o Moodle a correr o risco, a pergunta para qualquer empresa ou escola é direta: o PHP do seu Moodle já foi atualizado?

Checklist das primeiras 24 horas

1. Descubra a versão do PHP do site e a da linha de comando (cron). As duas precisam estar corrigidas.
2. Se for hospedagem, peça por escrito a versão e a data da atualização. Use o modelo de mensagem para o suporte.
3. Se for servidor próprio, atualize os pacotes do PHP e reinicie o PHP-FPM ou o Apache.
4. Se não der para atualizar hoje, aplique as mitigações abaixo e avalie restringir o acesso externo, como fizeram as universidades.
5. Depois da correção, teste login, curso, envio de arquivo e cron, e procure sinais de invasão.
6. Registre o que foi feito e quando. Se houver incidente com dados pessoais, esse registro ajuda a demonstrar diligência perante a LGPD.

Versões corrigidas do PHP

Distribuições Linux e fornecedores de suporte estendido receberam as correções antes da divulgação, e por isso a versão do pacote do seu sistema pode ter outro número, com a correção incluída. Confira o aviso de segurança da sua distribuição ou da sua hospedagem.

Como conferir o seu servidor

1. Pelo Moodle: em Administração do site > Servidor > Informações do PHP, a primeira linha mostra a versão do PHP que atende o site.
2. Pela linha de comando: php -v mostra a versão do PHP de linha de comando, usada pelo cron. Ela pode ser diferente da versão que atende o site: confira as duas.
3. Hospedagem compartilhada ou gerenciada: a atualização é do provedor. Pergunte por escrito se o PHP do seu plano já está nas versões corrigidas e peça a data. Use o modelo de mensagem para o suporte.
4. Servidor próprio (VPS): atualize os pacotes do PHP pela sua distribuição e reinicie o PHP-FPM ou o Apache. Sem reiniciar, os processos antigos continuam rodando com a versão vulnerável.

Moodle 4.1 ou mais antigo: o problema maior

O Moodle 4.1 aceita no máximo o PHP 8.1, e versões mais antigas do Moodle, PHPs ainda mais antigos. Essas séries do PHP não recebem mais correções oficiais. Na prática, quem está no Moodle 4.1 ou anterior não tem uma versão oficial corrigida do PHP para usar: depende de correções de terceiros ou de compilar o PHP a partir do código-fonte, o que raramente é viável em hospedagem.

Para esses casos, o PHP2Shell é o empurrão que faltava para atualizar o Moodle para uma versão que rode num PHP com suporte, como o 4.5 LTS ou o 5.3 LTS. Veja os requisitos do Moodle 5.x, qual PHP cada versão do Moodle aceita e, para saltos grandes, o upgrade encadeado.

Se não der para atualizar hoje

O projeto PHP é claro: não existe mitigação completa, atualizar é a única opção segura. As medidas abaixo só reduzem a exposição enquanto a atualização é providenciada:

• Desativar o progresso de upload de sessão: session.upload_progress.enabled = 0 no php.ini ou na configuração do pool do PHP-FPM, reiniciando os processos. O projeto PHP avisa que ini_set() e o .user.ini não servem para isso.
• Firewall de aplicação (WAF): se o site passa por um serviço com regras para as falhas conhecidas, confirme que elas estão ativas.
• Limites de requisição no servidor web: o projeto PHP sugere limitar tamanho e número de campos das requisições. No Moodle, cuidado para não travar o envio de arquivos dos alunos.
• Em último caso, tirar do ar: foi o que a própria Moodle HQ fez com os seus sites até aplicar as correções.

Sinais de que alguém já entrou

Atualizar fecha a porta, mas não expulsa quem já entrou. Se o servidor ficou exposto por dias, confira:

• No Moodle: administradores do site que você não reconhece, plugins instalados que ninguém pediu e código estranho nos campos de HTML adicional da aparência. Num caso real que atendemos, um invasor usou esses campos para injetar links de apostas escondidos em todas as páginas.
• No servidor: arquivos PHP novos ou alterados em pastas onde não deveriam estar, tarefas agendadas desconhecidas e processos que você não reconhece.
• Nos registros: quedas repetidas de processos do PHP, picos de erro e requisições incomuns perto de 21 de outubro de 2026.

Encontrou algo? Não apague antes de registrar: preserve as evidências, troque as senhas de administrador e do banco e avalie a comunicação de incidente à ANPD com o seu jurídico. Veja um caso de arquivos infectados detectados pelo monitoramento.

Erros comuns

• Atualizar e não reiniciar. Os processos antigos do PHP continuam rodando a versão vulnerável.
• Conferir só o php -v. O PHP que atende o site pode ser outro.
• Trocar de série sem checar o Moodle. O Moodle 4.5 aceita PHP 8.1 a 8.3; o 5.3 pede 8.3 ou 8.4. Veja os requisitos do Moodle.
• Confiar só no firewall. As regras de WAF ajudam contra os ataques conhecidos, mas não substituem a correção.
• Pedir para os alunos reenviarem tarefas. A falha é no servidor; as entregas já registradas continuam lá.

Depois de atualizar

• Confirme a versão nova em Informações do PHP e com php -v.
• Faça um teste rápido: login, abrir um curso, enviar um arquivo numa tarefa e rodar o cron.
• Se o servidor ficou exposto por dias, vale uma revisão de segurança: administradores que você não conhece, arquivos estranhos nas pastas do site e configurações alteradas. Veja o Moodle é seguro? e um caso de arquivos infectados detectados pelo monitoramento.

Informações conferidas nos avisos de segurança do projeto PHP de 21 e 23 de outubro de 2026 e no aviso da Moodle HQ de 22 de outubro de 2026. Atualizado em 27 de outubro de 2026.

Perguntas frequentes

Leia também

SegurançaPHP desatualizado e vulnerável: o que fazerInfraestruturaQual versão do PHP usar no Moodle (tabela 4.1 a 5.3 e comandos)SegurançaO Moodle é seguro? O que realmente define isso

Leia também

SegurançaFalha grave no PHP: o que fazer no seu servidorInfraestruturaQual versão do PHP usar no Moodle (tabela 4.1 a 5.3 e comandos)SegurançaO Moodle é seguro? O que realmente define isso