Falha grave no PHP: o que fazer se o seu servidor não foi atualizado

Em 21 de outubro de 2026, o projeto PHP publicou correções urgentes para duas falhas críticas, apelidadas de PHP2Shell. Desde então, a pergunta de muita empresa é simples: o meu site está seguro, e quem resolve isso? Este guia responde de forma direta, para quem tem Moodle, site institucional ou loja em PHP.

No Brasil: até a Anatel tirou sistema do ar

A falha grave no PHP não ficou no noticiário de tecnologia. Em 21 de outubro, a Anatel retirou do ar, de forma preventiva, o seu Sistema Eletrônico de Informações (SEI), que ficou indisponível das 12h15 às 22h05; não há confirmação pública de invasão. Outros órgãos da Justiça Federal também restringiram o acesso a sistemas digitais, e o governo federal orientou os órgãos públicos a identificar sistemas vulneráveis e, quando a correção não fosse imediata, restringir temporariamente o acesso externo (InvestNews, 23/10/2026; Tecnoblog, 21/10/2026).

O alerta oficial do Centro Integrado de Segurança Cibernética do Governo Digital (CISC GOV.BR) pediu aos órgãos federais atualização imediata e, quando ela não fosse possível, restrição temporária do acesso pela internet. Universidades como a UFCG e a UFSC chegaram a restringir o acesso externo ao Moodle: contamos em PHP2Shell no Moodle.

Se órgãos públicos preferiram tirar sistemas do ar a correr o risco, deixar o site da sua empresa exposto não é uma opção.

O que a Moodle HQ comunicou

Em 22 de outubro de 2026, a equipe da Moodle HQ enviou um comunicado à comunidade. Em resumo:

• Por precaução, a Moodle HQ tirou do ar os próprios sites públicos depois que a falha foi divulgada, em 21 de outubro.
• As correções já foram lançadas; o moodle.org foi corrigido e voltou ao ar, e os demais sites estão sendo corrigidos e validados.
• Quem hospeda o próprio Moodle deve avisar o responsável pelo PHP do servidor e planejar a atualização com as correções imediatamente.

O recado final do comunicado não deixa dúvida: "Unpatched sites remain vulnerable to potential exploits related to PHP2SHELL" (sites sem a correção continuam vulneráveis). Leia o comunicado original no fórum do moodle.org.

Em 1 minuto: o seu PHP está vulnerável?

Onde ver a versão:

• Moodle: Administração do site > Servidor > Informações do PHP.
• WordPress: Ferramentas > Saúde do site > Informação > Servidor.
• Painel da hospedagem: na área de configuração do PHP do domínio.

Pacotes de distribuições Linux podem trazer a correção com outro número de versão. Na dúvida, pergunte ao seu suporte, com o modelo abaixo. Fonte das versões: avisos de segurança do projeto PHP.

Quem é responsável por atualizar

O ponto mais esquecido: em servidor próprio, atualizar o pacote não basta. É preciso reiniciar o PHP-FPM ou o Apache, senão os processos antigos continuam rodando com a versão vulnerável.

Como atualizar o PHP no painel da hospedagem

Na maioria das hospedagens, a versão do PHP é escolhida por domínio, no painel de controle. O nome da opção muda de um painel para outro:

• cPanel: procure "Selecionar versão do PHP" ou "MultiPHP Manager", marque o domínio e escolha a série (por exemplo, 8.3).
• Plesk: abra o domínio e procure "Configurações de PHP".
• Painéis próprios das hospedagens: procure a área "PHP" ou "Versão do PHP" dentro do site ou domínio.

Atenção a um detalhe que confunde muita gente: no painel você escolhe a série (8.2, 8.3, 8.4), não a correção. Quem instala a versão corrigida dentro da série (8.3.36, por exemplo) é o provedor. Depois de mudar, confira a versão exata no seu sistema e, se ainda aparecer uma versão anterior à corrigida, cobre o suporte com o modelo abaixo.

• Antes de trocar de série, confira se o seu sistema aceita a versão nova. O Moodle 4.5, por exemplo, aceita PHP 8.1 a 8.3; o 5.3 pede 8.3 ou 8.4. Veja os requisitos do Moodle.
• Depois de trocar, teste o essencial: login, páginas principais, envio de formulários e, no Moodle, o cron.
• Em VPS ou servidor próprio não há painel: a atualização é pelo gerenciador de pacotes, seguida de reinício do PHP-FPM ou do Apache.

O suporte ainda não respondeu? Peça assim

Peça por escrito, por e-mail ou ticket, para ficar registrado. Copie e adapte:

Olá. Sobre as vulnerabilidades críticas do PHP divulgadas em 21/10/2026 (CVE-2026-109618 e CVE-2026-109619), preciso de três informações por escrito:
1. Qual a versão do PHP em uso no meu site, e a de linha de comando, se houver.
2. Se ela já está em 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou num pacote equivalente com a correção.
3. Se ainda não está, qual a data prevista para a atualização.
Obrigado.

Se a resposta não vier, vier genérica ("nossos servidores são seguros") ou sem data, esse é o sinal de que a sua plataforma depende de alguém que não está acompanhando. É exatamente o cenário de o fornecedor que some, e vale conferir também o checklist de controle do Moodle.

Por que não dá para esperar: riscos e LGPD

As falhas permitem executar código no servidor sem login, e empresas de segurança já relataram tentativas de exploração. Um servidor invadido pode expor nomes, e-mails, CPFs, notas e documentos de alunos, clientes e colaboradores.

Quando há dados pessoais, entra a Lei Geral de Proteção de Dados (Lei 13.709/2018):

• Dever de segurança: quem trata dados pessoais deve adotar medidas de segurança técnicas e administrativas para protegê-los de acessos não autorizados (art. 46 da LGPD).
• Comunicação de incidente: o controlador deve comunicar à ANPD e aos titulares o incidente de segurança que possa trazer risco ou dano relevante (art. 48 da LGPD). O regulamento da ANPD fixa o prazo de 3 dias úteis para essa comunicação (Resolução CD/ANPD nº 15/2024).
• Sanções: entre elas, multa simples de até 2% do faturamento da empresa no Brasil no último exercício, limitada a R$ 50 milhões por infração (art. 52, II, da LGPD). Os critérios de cálculo estão no regulamento de dosimetria da ANPD (Resolução CD/ANPD nº 4/2023).

A lei não diz que todo servidor desatualizado gera multa: a ANPD avalia cada caso, a gravidade e as medidas adotadas. Mas manter uma falha crítica conhecida sem correção, depois de o aviso ser público, é difícil de justificar como "medida de segurança adequada". Conteúdo informativo; para o seu caso concreto, consulte o seu jurídico ou o encarregado de dados (DPO).

PHP legado: quando não existe versão corrigida

PHP 8.1 e anteriores não recebem mais correções oficiais. O projeto PHP publicou apenas correções em código-fonte para 7.4, 8.0 e 8.1, para quem compila o PHP por conta própria, e recomenda migrar para uma versão com suporte. Na prática, quem está preso a PHP legado tem uma causa, quase sempre o sistema que roda em cima:

• Moodle 4.1 ou anterior não roda em PHP com suporte. O caminho é atualizar o Moodle. Veja qual PHP cada versão do Moodle aceita e o upgrade encadeado.
• Site ou loja com tema e plugins antigos que quebram no PHP novo. O caminho é atualizar ou trocar esses componentes, testando numa cópia.
• Sistema feito sob medida e nunca mais mantido. Exige uma revisão do código antes de mudar o PHP.

Se o seu Moodle roda no mesmo servidor de um site antigo, a falha de um expõe o outro. Contamos um caso real em um WordPress vulnerável que chegou ao banco do Moodle. Para o Moodle especificamente, veja PHP2Shell: o que fazer no seu Moodle.

Servidor atualizado e no Brasil

Falhas como essa vão continuar aparecendo. O que muda o resultado é ter um servidor que é atualizado como rotina, com alguém responsável por acompanhar os avisos, e não só quando alguém lembra.

Ter o servidor no Brasil também ajuda. A LGPD permite guardar dados fora do país, mas só em hipóteses específicas, como países com proteção adequada ou garantias contratuais comprovadas (art. 33 da LGPD). Com o servidor no Brasil, essa camada de exigência sai da conta, o contrato de operador de dados fica mais simples e o suporte trabalha no seu fuso e no seu idioma. Sem falar na latência menor para quem acessa daqui.

É o que entregamos no Moodle gerenciado da LMS Brasil: servidor no Brasil, atualizações de segurança, backup diário com cópias fora do servidor, contrato com cláusula de operador de dados e atendimento 24 horas para quedas e problemas graves.

Fontes: projeto PHP, avisos de 21 e 23/10/2026; Lei 13.709/2018 (LGPD), arts. 33, 46, 48 e 52; Resolução CD/ANPD nº 4/2023; Resolução CD/ANPD nº 15/2024. Conferido em 27 de outubro de 2026.

Perguntas frequentes

Leia também

SegurançaPHP2Shell no Moodle: o que fazer agoraCaso técnicoUma falha do WordPress que chegou ao banco do MoodleCompliance & LGPDLGPD no treinamento corporativo: o checklist que ninguém te dá