Vulnerabilidades críticas no PHP (CVE-2026-109618 e CVE-2026-109619): o que aconteceu e o que fazer

A 21 de outubro de 2026, o projeto PHP publicou as correções de duas falhas críticas e, no mesmo dia, o CERT-EU divulgou o aviso 2026-018. Ambas estão classificadas com 9,2 e ambas são descritas como execução remota de código sem autenticação. Se gere um site WordPress, uma loja em linha ou qualquer outra aplicação PHP, isto diz-lhe respeito, e a solução é uma atualização, não uma definição de configuração. Este artigo explica o que se sabe, como o ataque entra e o que deve fazer. Ponto de situação a 22 de outubro de 2026, com base na versão 1.1 do aviso do CERT-EU.

O que aconteceu

O PHP anunciou uma versão de segurança a 20 de outubro e publicou as correções a 21 de outubro, às 13:30 UTC. O CERT-EU intitulou o seu aviso «Critical Vulnerabilities in PHP» e indica dois CVE: CVE-2026-109618 e CVE-2026-109619, cada um com uma pontuação de 9,2. O CERT-EU escreve ainda que os detalhes técnicos já são discutidos publicamente e que começou a circular um primeiro código de prova de conceito. O aviso não confirma ataques em curso, mas refere que isso torna mais provável que os atacantes já estejam a explorar as falhas. Trate o assunto como urgente.

Quem é afetado

As versões afetadas são todas as versões do PHP anteriores à corrigida num ramo com suporte, e todos os ramos que chegaram ao fim de vida.

O CERT-EU menciona PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. Segundo a equipa do PHP, o mod_php apresenta o risco mais elevado. Também os produtos que incorporam o PHP podem ser afetados; o CERT-EU remete para uma lista do NCSC neerlandês no final deste artigo. Conta qualquer instalação que responda a pedidos web, tenha ou não um formulário de envio de ficheiros.

Como um atacante chega à primeira falha

Ninguém tem de iniciar sessão. Segundo o CERT-EU, uma exploração demonstrada prova que um único pedido sem autenticação pode desencadear o ataque antes de qualquer código da aplicação ser executado. É este o ponto que a maioria ignora: não importa se o seu WordPress está atualizado, se os seus plugins estão corrigidos ou se o seu formulário de contacto está protegido. O pedido chega primeiro ao motor do PHP.

A primeira falha, CVE-2026-109618, funciona assim:

1. Chega um pedido a um endereço que o PHP serve. Sem início de sessão, sem conta.
2. O PHP começa a ler o corpo do pedido. O CERT-EU dá como exemplo a análise dos envios de ficheiros através de formulários.
3. O PHP aplica o seu memory_limit com longjmp(). Quando o limite é excedido, abandona de repente o que estava a fazer e termina o pedido.
4. Se isso acontecer a meio da preparação dos dados internos do pedido, esses dados ficam construídos apenas em parte.
5. A limpeza posterior trata os dados inválidos como válidos e liberta memória que nunca foi inicializada. Essa memória pode ainda conter dados de atribuições anteriores que o atacante controlava.
6. A partir daí, o aviso descreve a execução remota de código no servidor.

Não descrevemos de propósito como o atacante conduz o último passo. Basta saber que o ponto de entrada não é a sua aplicação, e é por isso que nada dentro da sua aplicação o pode travar.

A segunda falha: um estado que sobrevive à sua memória

A CVE-2026-109619 é um mecanismo diferente com o mesmo resultado. O PHP mantém um estado interno para cada pedido. Após certas falhas, como um erro fatal, esse estado pode permanecer, mesmo que a memória subjacente já tenha sido libertada. O pedido seguinte tratado pelo mesmo processo de trabalho pode então usar esse estado obsoleto antes de ele ser reposto da forma habitual. O atacante precisa de dois pedidos que cheguem ao mesmo processo de trabalho; o CERT-EU classifica o resultado como o da primeira falha: execução remota de código.

O que fazer hoje

1. Descubra que versão do PHP serve realmente o seu site. O comando php -v na linha de comandos mostra a versão da linha de comandos, que pode ser diferente da que o seu servidor web utiliza. Verifique php-fpm -v, o seu painel de alojamento ou uma página que chame phpinfo(). Em alojamento partilhado, pergunte ao seu fornecedor.
2. Atualize para uma versão corrigida: 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. As distribuições costumam incorporar as correções sem alterar o número da versão, por isso procure os números CVE no aviso de segurança do seu fornecedor. Em contentores, reconstrua a partir de uma imagem de base atualizada. A equipa do PHP observa que rpms.remirepo.net não tinha atualizações no dia da publicação e recomenda os pacotes da distribuição ou uma compilação a partir do código-fonte.
3. Reinicie todos os processos de trabalho do PHP. Uma atualização em disco não altera os processos que já estão em execução. Reinicie o PHP-FPM ou o servidor web e volte a verificar a versão em execução.
4. Se hoje não puder atualizar, isole o servidor das redes públicas até a correção estar instalada e verificada. O CERT-EU é claro: só uma atualização corrige totalmente estas falhas.
5. Se utiliza o PHP 8.1 ou anterior, peça ao seu fornecedor a retroportação ou passe para um ramo com suporte. Estas versões não recebem atualizações regulares.

Medidas paliativas que reduzem o risco, mas não o eliminam

O CERT-EU enumera medidas que tornam um ataque mais difícil. Afirma claramente que não tornam uma instalação segura. Utilize-as enquanto prepara a atualização, não em vez dela.

• Contra a CVE-2026-109618: defina memory_limit=-1 de modo que as aplicações não o possam alterar, por exemplo com php_admin_value no grupo de processos do FPM, e verifique que nenhum grupo, diretório ou aplicação volta a definir um limite finito. Defina um post_max_size baixo (8M sem envios de ficheiros, 32M com eles) e mantenha upload_max_filesize abaixo dele. Limite o tamanho do pedido, o número de campos, as partes de formulário em várias partes, o número de cabeçalhos e a profundidade de aninhamento no servidor web ou no proxy. Utilize um limite de memória do contentor ou do cgroup como fronteira de disponibilidade, mas não RLIMIT_AS nem RLIMIT_DATA, que podem provocar a falha de atribuição vulnerável.
• Contra a CVE-2026-109619: defina session.upload_progress.enabled=0 no php.ini, no grupo de processos do FPM ou numa configuração do servidor que se aplique antes da análise do pedido (não com ini_set() nem com .user.ini), e reinicie todos os processos de trabalho. No PHP 8.5, defina também fatal_error_backtraces=0. Remova as definições inválidas ou desatualizadas, por pedido, que escrevem diagnósticos antes da inicialização, e corrija os erros fatais e os tempos limite de execução que um atacante consiga provocar.

O que o SilentShield pode e não pode fazer neste caso

Isto não é um problema de bots, e preferimos dizê-lo a deixar que uma página de produto sugira o contrário. O ataque atinge o motor do PHP antes de o pedido chegar a qualquer elemento nosso, ou a qualquer CAPTCHA, plugin ou regra de firewall dentro da sua aplicação. Uma proteção contra bots num formulário não o trava, e ninguém deve dizer-lhe que sim. A única solução completa é a atualização do PHP.

A API e o painel do SilentShield não estão escritos em PHP. O plugin do WordPress e o SDK de PHP correm dentro do seu próprio PHP, pelo que, para eles, a atualização tem de ser feita no seu servidor. Depois de atualizar, a proteção habitual contra bots e spam em formulários é tão útil como antes; simplesmente nunca foi a resposta a isto.

Fontes

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Anúncio do PHP de 20 de outubro de 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: produtos que incorporam o PHP