# CVE-2026-109619: RCE através de estado global obsoleto

> CVE-2026-109619 explicada: porque o estado interno entre pedidos se torna perigoso, que versões do PHP estão corrigidas e como se proteger.

Fonte: https://phpsos.de/pt/php2shell/cve-2026-109619/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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](https://phpsos.de/pt/php2shell/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](https://phpsos.de/pt/php2shell/mod-php-risiko/).

## 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:

```bash
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:

```bash
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](https://phpsos.de/pt/php2shell/php-fpm-neustart/).

> **Dica:**
> 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?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/).

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](https://phpsos.de/pt/leistungen/php-patch-service/), 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.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)