A 21 de outubro de 2026 o projeto PHP publicou correções para duas vulnerabilidades críticas, CVE-2026-109618 e CVE-2026-109619, conhecidas como php2shell. Um atacante sem utilizador nem palavra-passe pode, com pedidos HTTP manipulados, ler memória do servidor e executar código com as permissões do processo web. Se o seu site é um WordPress, PrestaShop, Drupal, Joomla, Magento ou uma aplicação Laravel, corre sobre PHP e está afetado.
As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Se o seu servidor tem uma anterior, atualizar é a tarefa de hoje.
O que aconteceu, sem jargão
São duas falhas na forma como o PHP gere a memória ao atender um pedido web.
- CVE-2026-109618 (memória esgotada a meio do pedido). Se o PHP fica sem memória enquanto prepara os dados de um pedido, a limpeza seguinte trata dados inválidos como válidos. Um atacante provoca-o com pedidos multipart (os dos formulários com ficheiros) preparados para esgotar a memória, mesmo que o tamanho pareça dentro dos limites. Aviso: GHSA-w8hw-w9fx-j79w.
- CVE-2026-109619 (estado que sobrevive entre pedidos). Um erro fatal, como ficar sem memória ou ultrapassar o tempo máximo, interrompe a limpeza. Parte do estado interno fica libertado mas acessível, e o pedido seguinte atendido pelo mesmo processo usa-o. A Huntress descreve-o como use-after-free no heap sem autenticação, com fuga de memória e execução remota de código. Aviso: GHSA-6wmf-4rv5-p3rp.
Ambas têm uma pontuação CVSS v4.0 de 9.2 em 10 (crítica). O post divulgado antes da publicação falava em 10.0; o valor oficial é 9.2.
A fuga de memória tem uma consequência prática: o que o processo PHP tiver carregado (palavras-passe da base de dados, tokens, chaves de API, certificados) pode acabar nas mãos de quem explorar a falha. A Wiz demonstrou execução remota sem autenticação contra WordPress, Drupal e Joomla, além dessa via de fuga.
Quem é afetado
Segundo o php.net, todas as instalações de PHP que servem pedidos web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é maior com mod_php: a Rapid7 explica que aí a falha é explorável antes de o código da aplicação chegar a correr, por isso nenhum plugin de segurança do WordPress a trava.
Por versões:
| Ramo do PHP | Versão corrigida | Estado |
|---|---|---|
| 8.5 | 8.5.12 | Com suporte |
| 8.4 | 8.4.27 | Com suporte |
| 8.3 | 8.3.36 | Com suporte |
| 8.2 | 8.2.35 | Fim de vida a 31-dez-2026 |
| 8.1, 8.0, 7.4 | Sem versão oficial | Apenas backports em código-fonte |
O PHP é usado por 69,7% dos sites cuja linguagem de servidor é conhecida, segundo a W3Techs citada pela Infosecurity Magazine. Se o seu site foi feito com um template de WordPress e ninguém lhe tocou desde a entrega, o mais provável é que continue numa versão de PHP sem correção.
Como saber que versão de PHP tem
Há três formas, da mais fácil à mais fiável:
- Painel do alojamento. No cPanel, no Plesk ou no painel do seu fornecedor costuma haver uma secção “Versão de PHP” ou “PHP Selector”. No WordPress também aparece em Ferramentas → Saúde do site → Informação → Servidor.
php -vpor SSH. Atenção: mostra a versão da linha de comandos, que pode não coincidir com a que serve o site. Num servidor com várias versões instaladas é comum serem diferentes.phpinfo(). Um ficheiroinfo.phpcom<?php phpinfo();na raiz do site mostra a versão e o SAPI que realmente serve os pedidos (a linha “Server API” diz se é FPM, Apache 2.0 Handler, que é mod_php, CGI ou LiteSpeed). Apague-o assim que o tiver visto: esse ficheiro mostra a qualquer pessoa a configuração do servidor.
Se usa os pacotes da sua distribuição Linux (Debian, Ubuntu, RHEL e derivadas), o número de versão pode não coincidir com a tabela mesmo com a correção aplicada: as distribuições LTS receberam as correções antes e integram-nas na sua própria numeração. Consulte o aviso de segurança da sua distribuição para o pacote de PHP.
Alojamento partilhado ou VPS. Num alojamento partilhado o fornecedor controla o binário do PHP e o php.ini global: escolhe o ramo no painel, mas quem aplica a correção é ele. Pergunte-lhe por escrito se já atualizou para as versões corrigidas. Num VPS ou servidor dedicado, faz isso você, ou quem lhe faz a manutenção.
O que fazer agora
1. Atualizar
Passe para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou instale o pacote corrigido da sua distribuição. Depois reinicie todos os processos de PHP (o serviço php-fpm, o Apache se usa mod_php, o LiteSpeed). Enquanto os processos antigos estiverem vivos, o código vulnerável continua a correr.
Se está no 8.2, a correção cobre-o agora, mas esse ramo deixa de receber correções a 31 de dezembro de 2026. Planeie já a passagem para 8.3 ou superior.
2. Se está no PHP 8.1 ou anterior
O projeto PHP já não publica versões para 8.1, 8.0 nem 7.4. Publicou backports mínimos em código-fonte, em ramos no seu GitHub, para quem compila o PHP. Se não é o seu caso, há duas opções: um fornecedor ou distribuição que continue a dar suporte a essa versão, ou migrar a aplicação para 8.3 ou superior. A migração pode partir plugins ou código antigo, por isso testa-se numa cópia antes de mexer em produção.
3. Mitigações temporárias enquanto atualiza
São as publicadas pelo projeto PHP. Reduzem a exposição, não substituem a atualização:
session.upload_progress.enabled = 0nophp.iniou na configuração do pool do PHP-FPM, e reiniciar todos os workers. Não serve defini-lo comini_set()nem num.user.ini.- No PHP 8.5, além disso:
fatal_error_backtraces = 0. - Contra o esgotamento de memória: limitar no servidor web ou no proxy o tamanho do pedido e o número de campos, partes e cabeçalhos. Se o site não recebe envio de ficheiros,
post_max_size = 8M; se recebe,32M.
Num alojamento partilhado provavelmente não tem acesso ao php.ini nem ao pool: nesse caso a mitigação também cabe ao fornecedor.
Se não pode atualizar ou suspeita de um ataque
O NCSC britânico recomenda que, se não puder atualizar, procure indícios de comprometimento e backdoors, e que, se também não puder aplicar as mitigações, considere desligar o sistema. Um site em baixo durante um dia custa menos do que um site que distribui malware ou expõe os dados dos seus clientes.
O que verificar num site PHP:
- Ficheiros
.phpnovos ou modificados em pastas onde não deviam estar, comowp-content/uploadsou diretórios de cache. - Utilizadores administradores que ninguém criou.
- Tarefas agendadas (cron) ou processos que não reconhece.
- Erros fatais por falta de memória ou tempo esgotado nos logs do PHP a partir de 20 de outubro, sobretudo em pedidos POST multipart.
Se encontrar algo, ou se o seu servidor esteve exposto sem correção, rode os segredos que o processo PHP tinha em memória: palavra-passe da base de dados, chaves de APIs (gateway de pagamento, email, CRM), tokens e, se o certificado TLS for servido pelo mesmo processo, também a sua chave. Por causa da fuga de memória, atualizar não desfaz o que já tiver sido exposto. Se o site já mostra sinais de que alguém entrou, em site hackeado explicamos o que fazer na primeira hora.
Cronologia
- 20 de outubro: um post no Hacker News publica os identificadores das CVE antes do fim do embargo.
- 21 de outubro, 14:00 UTC: o projeto PHP antecipa a publicação das correções.
- 21 de outubro: o NCSC (Reino Unido) e o CERT-EU emitem alertas. A Rapid7 avisa que espera exploração e que várias equipas a estão a reproduzir.
- 21 de outubro, 16:30 hora do leste dos EUA: a Huntress informa que não observou exploração entre os seus clientes.
Não haver exploração observada a 21 de outubro não dá margem: os identificadores são públicos e há equipas a reproduzir a falha.
Os outros avisos dessa semana (Node.js, NGINX, GitLab, Railway, LiteLLM e os certificados da GoDaddy e da eMudhra) estão no resumo de vulnerabilidades de outubro de 2026.
Se preferir que tratemos nós
Na Soamee mantemos aplicações PHP e servidores de clientes, e podemos tratar desta atualização por si. O processo é o descrito neste artigo, aplicado ao seu caso:
- Inventário: que sites e servidores tem, que versão de PHP e que SAPI usa cada um, e quem controla cada servidor (você ou o alojamento).
- Mitigação imediata onde a atualização não puder ser feita no mesmo dia.
- Atualização para a versão corrigida, ou plano de migração se está no 8.1 ou anterior, testada antes numa cópia.
- Verificação de que o site atende pedidos com a nova versão e de que não ficam processos antigos vivos.
- Revisão de indícios de comprometimento e rotação de segredos se for preciso.
Nenhuma atualização garante que um servidor não foi comprometido antes da correção; por isso o ponto 5 está na lista. Se quiser que o revejamos, contacte-nos ou peça uma consultoria gratuita. Se procura quem faça a manutenção de forma contínua, veja os nossos serviços de cloud e DevOps ou de desenvolvimento web.