Segurança Servidor Moodle Pós-PHP2Shell: Checklist Completo

A segurança servidor Moodle deixou de ser um item de checklist anual em 20 de outubro de 2026, quando vazaram os detalhes do PHP2Shell: duas falhas no próprio PHP que permitem executar código remotamente sem login. Se o seu AVA roda em PHP, ele está no escopo. Neste guia eu mostro o que corrigir primeiro, o que as mitigações não resolvem e como montar um servidor que aguente a próxima falha.

TL;DR

• O PHP2Shell é a dupla CVE-2026-109618 (corrupção de memória em out-of-memory) e CVE-2026-109619 (estado global obsoleto reaproveitado entre requisições). CVSS 4.0 de 9.2, sem autenticação.
• A correção saiu em 21/10/2026: PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Do 7.4 ao 8.1 só existem backports mínimos de código-fonte; do 5.4 ao 7.3 não há correção.
• Moodle 4.1 LTS (PHP 7.4 a 8.1) e Moodle 4.5 rodando em PHP 8.1 estão na pior posição: não existe pacote oficial corrigido para esses PHPs.
• Ajustes como memory_limit=-1 e session.upload_progress.enabled=0 reduzem o risco, mas não resolvem. Só o patch resolve.
• Patch em horas é a primeira camada. As outras são isolamento, WAF, backup imutável, moodledata fora do webroot e monitoramento.

O que é o PHP2Shell e por que ele atinge a segurança servidor Moodle

O PHP2Shell não é bug do Moodle. É bug do interpretador que executa o Moodle. Essa diferença importa: atualizar o Moodle para a última versão não fecha a falha, e nenhum plugin de segurança do AVA enxerga o ataque, porque ele acontece antes do código da aplicação rodar.

São duas vulnerabilidades distintas:

• CVE-2026-109618 — quando o PHP estoura o limite de memória no meio do processamento de uma requisição, parte dos dados fica meio inicializada. Um atacante consegue provocar esse estado de propósito e transformar a corrupção de memória em execução de código.
• CVE-2026-109619 — um estado global da requisição sobrevive depois que a memória dele foi liberada (use-after-free) e pode ser reaproveitado pela requisição seguinte no mesmo worker. Worker é o processo do PHP-FPM ou do Apache que atende várias requisições em sequência.

O anúncio oficial do PHP classifica as duas com CVSS 4.0 de 9.2. Segundo o resumo publicado pela Huntress, o próprio time do PHP afirma que toda instalação que atende requisições web está em risco: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. O mod_php é o caso mais grave, com exploit validado sobre HTTP usando os limites padrão de entrada e memória.

A linha do tempo que você precisa conhecer

Data	O que aconteceu	Fonte
17/10/2026	A AWS registra tentativas de exploração, quatro dias antes da divulgação	Datadog Security Labs
20/10/2026	Detalhes vazam em redes sociais antes do embargo; o PHP antecipa a release	watchTowr
21/10/2026	Saem 8.5.12, 8.4.27, 8.3.36 e 8.2.35; watchTowr vê exploração no seu honeypot	watchTowr
21-23/10/2026	Palo Alto Cortex Xpanse conta mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis	Unit 42
23/10/2026	O PHP alerta para a CVE-2026-115560, vetor improvável, correção prevista na próxima release regular	The Hacker News

O número de 22,6 milhões é exposição potencial, não servidores comprovadamente exploráveis. Mas ele dá a escala: o atacante não precisa procurar Moodles. Ele varre PHP, e o seu AVA aparece na varredura.

Segurança servidor Moodle começa pela versão do PHP

Aqui está o ponto de segurança servidor Moodle que quase nenhum alerta genérico de PHP trata: o Moodle amarra você a uma faixa de versões do PHP. Não dá para simplesmente instalar o PHP 8.5.12 em qualquer AVA. Segundo a documentação oficial do Moodle sobre PHP, as faixas suportadas são estas:

Versão do Moodle	PHP suportado	Correção oficial do PHP2Shell disponível?
4.1 LTS	7.4 a 8.1	Não. Só backport de código-fonte ou pacote de distribuição
4.5 LTS	8.1 a 8.3	Sim, desde que esteja em 8.2.35 ou 8.3.36
5.0 e 5.1	8.2 a 8.4	Sim: 8.2.35, 8.3.36 ou 8.4.27
5.2	8.3 a 8.4	Sim: 8.3.36 ou 8.4.27

Repare que nenhuma versão estável do Moodle listada suporta o PHP 8.5. Na prática, o patch do seu AVA é o 8.4.27, o 8.3.36 ou o 8.2.35, conforme a versão.

O caso mais perigoso: Moodle 4.1 ou PHP 8.1

Quem ainda roda Moodle 4.1 LTS, ou um 4.5 em cima de PHP 8.1, está num beco. O PHP 8.1 e anteriores estão fora de suporte, e a única saída oficial são os backports mínimos de código-fonte publicados pelo time do PHP — você compila e mantém por conta própria. Algumas distribuições Linux com suporte estendido empacotam a correção sem mudar o número da versão; por isso o guia da Datadog recomenda conferir o boletim do fornecedor, não só o php -v.

A recomendação honesta é: use o backport ou o pacote da distribuição como ponte de dias, não de meses, e planeje a subida para Moodle 4.5 em PHP 8.3 ou para a linha 5.x. Se a sua instalação está em PHP 7.3 ou anterior, o watchTowr confirma que não há correção nenhuma: tire da internet até migrar.

Checklist de segurança servidor Moodle: as primeiras 24 horas

Este é o procedimento de segurança servidor Moodle que eu sigo quando sai uma falha crítica de PHP. A ordem importa mais do que a velocidade de cada passo.

1. Inventarie o PHP que atende a web, não o da linha de comando. O CLI e o PHP-FPM podem ter versões diferentes. Crie temporariamente um arquivo com phpinfo() fora do Moodle, ou consulte Administração do site > Servidor > Informações do PHP, e anote a versão real do runtime. Inclua containers e imagens Docker antigas.
2. Aplique o patch da sua linha. Atualize o pacote do PHP para 8.2.35, 8.3.36 ou 8.4.27. Em Ubuntu e Debian, o pacote corrigido pode vir com outro número de versão; confira o changelog do pacote.
3. Reinicie todos os workers. Atualizar o binário sem reiniciar o PHP-FPM ou o Apache deixa os processos antigos, vulneráveis, atendendo requisições. É o erro mais comum depois de um patch de urgência.
4. Ative o modo de manutenção só se precisar. Em servidores que não podem ser atualizados no mesmo dia, o NCSC britânico e o CERT-UE recomendaram isolar ou tirar do ar. Para um AVA, isso significa bloquear o acesso público e liberar só a rede da instituição ou uma VPN até o patch.
5. Procure sinais de que já entraram. Shell aberto por processo php-fpm, apache2 ou httpd; comandos como whoami, id, uname -a; arquivos .php novos no diretório do Moodle; crons e usuários que ninguém criou.
6. Rode o cron do Moodle e teste os fluxos críticos. Login, envio de tarefa, questionário e emissão de certificado. Patch que quebra prova em semana de avaliação também é incidente.

Cada item de segurança servidor Moodle desta lista leva minutos num ambiente bem documentado. Leva horas — ou dias — quando ninguém sabe qual PHP está rodando onde. Se você já percebeu que o seu caso é o segundo, é exatamente esse inventário que vem pronto numa hospedagem Moodle gerenciada.

Mitigações temporárias de segurança servidor Moodle: o que reduzem e o que não resolvem

Quando o patch não pode entrar na hora, o PHP e os pesquisadores listaram ajustes de configuração. O guia da Datadog resume os três principais, todos com a mesma ressalva: só o patch corrige as falhas.

Ajuste	Contra qual CVE	Efeito colateral no Moodle
memory_limit=-1 (na configuração do administrador)	CVE-2026-109618	Remove o teto de memória por processo; um relatório pesado pode consumir a RAM do servidor inteiro
session.upload_progress.enabled=0	CVE-2026-109619 e CVE-2026-115560	Desliga o recurso nativo de progresso de upload por sessão do PHP; teste plugins de envio de arquivo antes
fatal_error_backtraces=0 (só PHP 8.5)	CVE-2026-109619	Irrelevante para quem segue as faixas oficiais do Moodle, que não incluem o 8.5

Quando não confiar na mitigação

O memory_limit=-1 exige par: limite de memória no container ou no cgroup e limite de tamanho de corpo de requisição no Nginx ou no Apache. Sem isso, você troca um RCE por um servidor que cai no primeiro relatório de notas de 30 mil linhas. A própria documentação do Moodle pede pelo menos 96 MB e recomenda 128 MB de memory_limit em operação normal — tirar o teto é uma medida de emergência, não uma configuração de produção.

O session.upload_progress.enabled=0 é a mitigação que vale manter mesmo depois do patch, porque é ela que bloqueia a CVE-2026-115560, o alerta de 23 de outubro que afeta inclusive o 8.5.12 e só será corrigido na próxima release regular. O PHP descreve o vetor como improvável — depende de uma combinação incomum de configurações de sessão —, mas é uma linha no php.ini.

Isolamento e WAF: as camadas que seguram o próximo zero-day

O patch resolve o PHP2Shell. As camadas de segurança servidor Moodle abaixo resolvem o que ainda não tem nome. Elas reduzem o estrago quando a próxima falha vazar numa sexta-feira à noite.

Isolamento de processo e de rede

• Um pool PHP-FPM por instância, com usuário próprio. Se dois Moodles (ou um Moodle e um WordPress) dividem o mesmo usuário de sistema, um RCE em um vira RCE nos dois.
• Banco de dados sem porta pública. O MariaDB ou PostgreSQL escuta só na rede interna ou no socket local.
• Saída de rede restrita. O primeiro passo de quem ganha shell num servidor é baixar ferramenta. Bloquear conexões de saída do usuário do PHP, liberando só o que o Moodle precisa (SMTP, APIs integradas, repositórios), corta boa parte da cadeia de ataque.
• Funções perigosas desabilitadas quando o Moodle não usa: disable_functions com cautela, porque o Moodle usa exec para alguns conversores. Teste em homologação.

Os detalhes de SSH, firewall e kernel estão no meu checklist de hardening de servidor Linux, que vale para qualquer servidor web.

O WAF compra tempo, não imunidade

Na segurança servidor Moodle um WAF (Web Application Firewall, o filtro que inspeciona as requisições antes de chegarem ao servidor) foi útil no PHP2Shell: a Cloudflare publicou regras e a Palo Alto informou cobertura por assinatura desde a noite de 20 de outubro. Mas regra de WAF é feita para o exploit conhecido. Variações passam. Use o WAF para atravessar as horas entre o vazamento e o patch, nunca como substituto dele.

Moodledata fora do webroot e a nova pasta public do Moodle 5.1

Um RCE dá ao atacante a permissão do usuário do PHP, e é aqui que a segurança servidor Moodle se decide na montagem do disco. O que ele consegue ler e escrever com essa permissão depende de como o servidor foi montado.

Para a segurança servidor Moodle o ponto central é o moodledata, que guarda os arquivos enviados, o cache e as sessões. Ele nunca pode ficar dentro do diretório servido pela web. Se ficar, qualquer falha de upload vira arquivo executável acessível por URL. O instalador do Moodle avisa, mas já vi muita instalação feita em painel compartilhado que ignorou o aviso.

A partir do Moodle 5.1, o projeto deu um passo a mais: a documentação de atualização determina que só a pasta /public seja acessível pela web, com o document root apontando para moodle/public, e a atualização é bloqueada até essa configuração estar feita. O config.php passa a ficar um nível acima. Na prática, código-fonte, scripts administrativos e configuração saem do alcance direto do navegador.

Três verificações rápidas de segurança servidor Moodle para esta camada:

• O config.php não pode ser gravável pelo usuário do PHP. Dono root, leitura para o grupo do servidor web.
• O código do Moodle também não deve ser gravável pelo PHP em produção. Instalar plugin pela interface é conveniente, e é exatamente o que um invasor também vai usar.
• O moodledata precisa de escrita, mas não de execução. Monte o volume com noexec quando possível.

Backups imutáveis: a única defesa quando tudo falha

Se alguém executou código no seu servidor, você não sabe o que ele alterou. O backup feito pelo próprio servidor também está sob suspeita: um invasor com acesso ao usuário do PHP, ou pior, ao root, pode apagar ou criptografar as cópias.

Na segurança servidor Moodle, backup imutável é a cópia que nem o próprio servidor consegue apagar durante um período definido. Exemplos práticos:

• Object storage com bloqueio de objeto (object lock) em modo de retenção, por 14 a 30 dias.
• Repositório de backup em modo append-only, no qual o servidor de origem só adiciona e nunca remove.
• Cópia puxada por um servidor externo (pull), com credenciais que o servidor do Moodle não possui.

Um backup de Moodle completo tem três partes: banco de dados, moodledata e código com plugins. Faltando qualquer uma, a restauração não fecha. E vale a regra que repito para todo cliente: backup que nunca foi restaurado é hipótese, não backup. Teste a restauração em um ambiente separado pelo menos uma vez por mês.

O custo de não ter

Um AVA comprometido em semana de provas significa reemitir notas, reabrir avaliações e explicar o incidente ao jurídico, por causa da LGPD. Comparado a isso, o storage de backup imutável costuma ser a menor linha da conta de infraestrutura.

Monitoramento: saber em minutos, não pelo aluno

O PHP2Shell deixa rastros previsíveis, e a segurança servidor Moodle depende de alguém enxergá-los. O Datadog Security Labs e a Huntress listaram os principais, e todos cabem num monitoramento de servidor Moodle sem ferramenta cara:

• Log de erro do PHP com "Allowed memory size ... exhausted" apontando "Unknown on line 0", ou segfaults (AH00052) em sequência curta.
• Formulários estranhos: campos PHP_SESSION_UPLOAD_PROGRESS, uploads multipart gigantes ou muito aninhados, nomes de arquivo contendo <?php.
• Processos: qualquer shell, curl, wget ou interpretador iniciado por um processo do PHP. Em servidor sem EDR, ferramentas abertas de vigilância de processos já resolvem.
• Arquivos: .php novo ou alterado no diretório do código, que em produção deveria ser imutável.

Uma auditoria de segurança servidor Moodle que termina em relatório e não em alerta não protege ninguém. O alerta precisa chegar a alguém que pode agir — no nosso caso, ele cai no WhatsApp da equipe técnica.

Quando não faz sentido operar sozinho

Montar essas camadas de segurança servidor Moodle uma vez não é difícil para quem administra Linux. O difícil é manter: acompanhar boletins de PHP, Moodle e distribuição; aplicar patch no mesmo dia; testar restauração todo mês; olhar alerta às 23h de uma sexta. Se a sua instituição tem um sysadmin dedicado com esse tempo, ótimo. Se o Moodle é responsabilidade de uma pessoa que também cuida da rede, das impressoras e do sistema acadêmico, o PHP2Shell provavelmente foi a semana em que essa conta não fechou.

Comparei os custos reais de cada caminho de segurança servidor Moodle no post sobre VPS para Moodle ou hospedagem gerenciada. A decisão depende menos do preço do servidor e mais de quem atende o alerta. E se você está dimensionando um servidor novo, os números de CPU, RAM e versão estão no guia de requisitos de servidor para Moodle 5.x.

Como a Agathas Web resolve isso

Eu trabalho com Moodle desde 2008, sou certificado como desenvolvedor Moodle e opero servidores Linux para EAD há mais de 15 anos. A Hospedagem Moodle da Agathas Web foi montada para tratar a segurança servidor Moodle como rotina, para que um evento como o PHP2Shell seja um procedimento, não uma emergência. O que está incluso:

• Patch de segurança como rotina. Acompanhamos os boletins do PHP, do Moodle e do sistema operacional, aplicamos primeiro em homologação e depois em produção, com reinício controlado dos workers.
• Stack dedicada e isolada. PHP-FPM com pool próprio por instância, sessões e cache em Redis, MariaDB sem exposição pública. Sem WordPress dividindo processo com o seu AVA.
• Rede e borda. Cloudflare WAF com proteção DDoS, Fail2ban e rate limit em rotas críticas, SSL com renovação automática e hardening do sistema com auditoria de logs.
• Backup que restaura. Backup completo diário, binlog incremental a cada 15 minutos, cópia offsite criptografada em AES-256 e restauração testada todo mês.
• Monitoramento 24/7. Grafana, Prometheus, Sentry e verificação externa de disponibilidade, com alertas direto no WhatsApp da equipe.
• SLA em contrato. Resposta em até 15 minutos para incidente crítico e uptime mensal de 99,9%.

Como funciona a contratação: você fala com a equipe técnica (não com um robô de vendas), fazemos um diagnóstico da sua versão de Moodle, PHP e plugins, e propomos o plano. A migração assistida leva até 5 dias úteis, com validação em homologação antes da virada e o ambiente antigo preservado por 30 dias. Se o seu AVA está preso em Moodle 4.1 ou PHP 8.1, a migração de versão entra no mesmo projeto.

Conclusão: o próximo PHP2Shell já está a caminho

O PHP2Shell vai sair do noticiário em algumas semanas. A lição fica: a segurança servidor Moodle depende de uma camada que nem aparece no painel do AVA, e o intervalo entre o vazamento de uma falha e a primeira tentativa de ataque já é medido em horas — neste caso, a AWS viu tentativas antes mesmo da divulgação.

Resumo do checklist de segurança servidor Moodle para fazer agora: confirme a versão do PHP que atende a web, aplique 8.2.35, 8.3.36 ou 8.4.27, reinicie os workers, mantenha session.upload_progress.enabled=0, tire o moodledata do webroot e garanta um backup que o próprio servidor não consiga apagar.

Se você prefere que a próxima falha crítica seja problema de quem opera Moodle todos os dias, conheça a Hospedagem Moodle da Agathas Web e peça um diagnóstico do seu ambiente.