Em resumo: a CVE-2026-109619 é a segunda vulnerabilidade por trás do PHP2Shell. O estado interno pertencente a um pedido pode persistir após a libertação da memória; um pedido posterior no mesmo worker pode usá-lo antes de ser reposto. A consequência é a execução de código sem autenticação. Solução: atualização para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e reinício de todos os workers.
O que é a CVE-2026-109619?
A CVE-2026-109619 (identificador GitHub GHSA-6wmf-4rv5-p3rp) tem CVSS v4.0 de 9,2. Em conjunto com a CVE-2026-109618, constitui o PHP2Shell. Ambas as vulnerabilidades estão no próprio PHP e não numa aplicação.
O efeito é o mesmo que o da vulnerabilidade irmã: um atacante pode executar código no servidor remotamente, sem palavra-passe e sem conta de utilizador. A causa, porém, é outra.
Porque é que o estado obsoleto num worker é perigoso
Um servidor web PHP não inicia um processo novo para cada pedido. No PHP-FPM, no Apache com mod_php, no LiteSpeed ou no FrankenPHP, um worker trata muitos pedidos em sequência. Entre dois pedidos, o PHP repõe o seu estado interno, para que nada do pedido A chegue ao pedido B.
Na CVE-2026-109619, esta reposição não funciona por completo. Segundo o php.net, o estado interno pertencente ao pedido pode persistir após a libertação da memória. Um pedido posterior no mesmo worker pode usar esse estado obsoleto antes de ser reposto. Dito de forma simplificada: algo continua a ser usado que na verdade já não é válido.
Do ponto de vista da operação, isto é notável. A reutilização dos workers é intencional, porque torna os servidores web rápidos: um worker não tem de arrancar de novo para cada pedido, carregar extensões e reservar memória. A vulnerabilidade atinge, portanto, uma característica que praticamente toda a instalação PHP produtiva tem. O php.net não indica nenhuma configuração que evite totalmente o problema; por isso, o caminho passa pela atualização.
Os pormenores da exploração não os publicamos. Para os operadores, conta o seguinte: todo o modo de operação em que os workers servem vários pedidos tem de ser acompanhado, e são precisamente esses os modos habituais.
As duas vulnerabilidades do PHP2Shell em comparação
| Característica | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Identificador GitHub | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Avaliação | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Gatilho | Falta de memória durante a inicialização dos dados do pedido | O estado interno persiste após a libertação |
| Efeito | Execução de código sem autenticação | Execução de código sem autenticação |
| Corrigida em | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
Estão afetados o PHP-FPM, o Apache com mod_php, o php-cgi, o FrankenPHP e o LiteSpeed. O risco mais elevado é visto pela equipa do PHP no mod_php; porquê, explicamo-lo em Porque é que o mod_php tem o risco mais elevado.
Fechar a CVE-2026-109619: atualização e depois reiniciar todos os workers
Nesta vulnerabilidade em particular, o reinício é decisivo. Enquanto workers antigos correrem na memória, o servidor continua a trabalhar com o código com erro, mesmo que os ficheiros novos já estejam há muito no disco.
Verifique a versão e o estado do pacote. Os nomes dos pacotes variam conforme a distribuição e a interface do fornecedor de alojamento:
php -v
php-fpm8.3 -v # o binário FPM pode ter uma versão diferente da CLI
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # família RHEL
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
Depois, reiniciar todos os serviços afetados:
sudo systemctl restart php8.3-fpm # conforme a versão do PHP instalada
sudo systemctl restart apache2 # com mod_php; no RHEL o serviço chama-se httpd
Se a sua distribuição ou o seu fornecedor de alojamento aplicar um backport, o número de versão apresentado pode continuar igual. Nesse caso, contam o changelog do pacote e a confirmação escrita do fornecedor. Uma verificação passo a passo encontra-a em Reiniciar o PHP-FPM e todos os workers.
Anote a data e a hora do reinício. Para a avaliação posterior sobre se um ataque ocorreu antes ou depois do patch, este momento é o ponto de referência mais importante.
O que ainda há a fazer depois do patch
Um patch não prova que antes nada aconteceu. Segundo notícias dos meios de comunicação, foi observada uma primeira tentativa de ataque a 17 de outubro, quatro dias antes dos patches. Guarde os registos do servidor desde 20 de outubro, como recomenda a imprensa especializada, e verifique se o servidor apresenta anomalias. Indicações a esse respeito dá-as a página Já estou comprometido?.
Pense, a propósito, no alcance: numa execução de código bem-sucedida, o atacante tem os direitos do processo PHP. Pode ler o que a aplicação pode ler, por exemplo ficheiros de configuração com acessos a bases de dados ou chaves de API. Se um incidente se confirmar, estas credenciais devem ser renovadas após a limpeza.
Como ajuda concretamente a PHP SOS?
Com o serviço de patches PHP, executamos a correção de forma rastreável:
- Registar: que versões e modos de operação do PHP correm em que servidor, e que fonte de pacotes os fornece?
- Aplicar o patch: atualização a partir da fonte correta ou medidas provisórias segundo o php.net, onde a atualização ainda está bloqueada.
- Controlar o reinício: verificamos, processo a processo, que só corre já a versão corrigida.
- Documentar: versões, estados de pacote e momentos de reinício, para que possa comprovar o estado.
Perguntas frequentes
O que distingue a CVE-2026-109619 da CVE-2026-109618?
A CVE-2026-109618 surge quando um estado de falta de memória interrompe o pedido a meio da inicialização. A CVE-2026-109619 diz respeito a estado que fica no worker depois do fim de um pedido. Ambas levam à execução de código sem autenticação e estão corrigidas nas mesmas versões do PHP.
Ajuda reiniciar os workers do PHP-FPM com mais frequência?
Como substituto da atualização, não é adequado. O php.net não indica reinícios mais frequentes de workers como medida provisória. Tem, no entanto, de reiniciar os workers depois da atualização, para que a versão corrigida esteja de facto em execução.
Estou protegido contra a CVE-2026-109619 com uma atualização do CMS?
Não. A vulnerabilidade está no PHP e não no WordPress, no Shopware, no TYPO3 ou noutro sistema. Só uma atualização do PHP ou um backport confirmado pelo fornecedor a corrige.
Existem vestígios conhecidos de um ataque através da CVE-2026-109619?
Até agora não foram publicados indicadores de compromisso (IOCs) confirmados. A deteção assenta na análise de comportamento, por exemplo ficheiros PHP novos, ligações de saída invulgares ou cronjobs desconhecidos.