---
title: "PHP2Shell: execução remota de código no PHP"
description: "Alerta crítico PHP2Shell: duas vulnerabilidades de execução remota de código no PHP. Versões corrigidas, detecção, mitigação temporária e resposta a incidentes."
lang: pt-BR
type: alert
canonical: "https://soc.gigacandanga.net.br/alertas/php2shell-cve-2026-109618-109619.html"
source_html: "/alertas/php2shell-cve-2026-109618-109619.html"
alert_id: "AR-2026-001"
published: "2026-10-23"
updated: "2026-10-23"
severity: critical
cvss: 9.2
cves:
- "CVE-2026-109618"
- "CVE-2026-109619"
status: "exploited-in-wild"
source_sha256: "345c0180405535904d718e70280022676c5dadbc4f330d305ee86d3c758074dd"
generator: "site-md/1"
---
Versão HTML: [https://soc.gigacandanga.net.br/alertas/php2shell-cve-2026-109618-109619.html](https://soc.gigacandanga.net.br/alertas/php2shell-cve-2026-109618-109619.html)
Alerta de segurança · AR-2026-001
*Crítica · AR-2026-001 · 23 de outubro de 2026*
# PHP2Shell: execução remota de código no PHP
Duas vulnerabilidades críticas no núcleo do PHP, CVE-2026-109618 e CVE-2026-109619, permitem execução remota de código sem autenticação. A correção exige atualização do runtime; medidas de configuração reduzem caminhos conhecidos, mas não eliminam a falha.
> **Ação imediata**
>
> **Atualize o PHP para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12** — ou versão posterior da mesma linha — e reinicie todos os workers. Priorize serviços expostos à internet e ambientes com `mod_php`.
>
> - Inventarie o PHP efetivamente usado pelo serviço web, incluindo contêineres e aplicações que embarcam o runtime.
> - Não confie apenas no `php -v` do CLI: confirme o SAPI do processo web.
> - Se não for possível atualizar, retire o serviço da internet ou restrinja o acesso até concluir a correção.
## Resumo
Em 21 de outubro de 2026, o projeto PHP publicou correções para duas vulnerabilidades críticas no interpretador, divulgadas em conjunto como **PHP2Shell**. Ambas receberam **CVSS v4.0 9.2**, com vetor de rede, sem privilégios e sem interação do usuário. Na CVE-2026-109618, o caminho confirmado em `mod_php` é explorado no processamento da requisição, antes da execução do código da aplicação; por isso, autenticação e validações implementadas no script não bloqueiam esse caminho.
O problema não está restrito a um framework, CMS ou função específica: qualquer instalação PHP que atenda requisições HTTP está no escopo, incluindo PHP-FPM, Apache com `mod_php`, `php-cgi`, FrankenPHP e LiteSpeed. O risco é maior em `mod_php`, onde a exploração foi demonstrada de forma independente da aplicação.
A correção está disponível para as linhas suportadas. A atualização é a única correção completa; as mitigações de configuração documentadas reduzem a exposição a caminhos conhecidos, mas não tornam a instalação segura.
### Por que este alerta é prioritário
- PHP está presente em sites, APIs, painéis administrativos, CMS e appliances, muitas vezes como componente embarcado e fora do inventário tradicional.
- Há relatos públicos de tentativas de exploração e atividade em ambiente real, incluindo uma tentativa observada em 17 de outubro de 2026, antes da divulgação.
- Versões fora de suporte também são afetadas: 7.4, 8.0 e 8.1 dependem de backport ou pacote do fornecedor; 7.3 e anteriores não têm correção do projeto PHP.
- A exploração pode não derrubar o worker nem retornar erro: uma resposta HTTP 200 não é evidência de que a requisição foi inofensiva.
## Gravidade e exposição
| CVE | Falha | Impacto | Validação técnica |
| --- | --- | --- | --- |
| `CVE-2026-109618` | Corrupção de memória no tratamento de falha de alocação (OOM). | Execução de código com os privilégios do worker web; impacto alto em confidencialidade, integridade e disponibilidade. | RCE confirmado contra `mod_php`. O advisory do PHP considera o PHP-FPM suscetível por análise de código, sem exploit completo demonstrado nesse SAPI. |
| `CVE-2026-109619` | Estado global obsoleto após liberação de memória ( *use-after-free*). | Execução de código e vazamento de memória; o impacto depende do estado e das extensões alcançáveis no worker. | RCE confirmado em `mod_php`; caminho validado em PHP-FPM com uma operação adequada da aplicação após o startup. |
A pontuação é alta, mas a exploração exige condições específicas: o atacante precisa provocar a falha no momento correto e, no caso da CVE-2026-109618, lidar com aleatorização de memória e múltiplas tentativas. Isso reduz a automação trivial, mas não impede a exploração — e ambientes com muitos workers ou tráfego intenso podem aumentar a superfície disponível.
**Status de exploração:** a Amazon Threat Intelligence relatou uma tentativa contra sua rede de sensores em 17 de outubro de 2026; a watchTowr relatou exploração em ambiente real em 21 de outubro. A CISA, no alerta de 21 de outubro, afirmou não ter observado exploração até a publicação. Até 22 de outubro, nenhum dos dois CVEs constava no catálogo *Known Exploited Vulnerabilities* (KEV) da CISA. Consulte o KEV para o status atual.
## Detalhes técnicos
### CVE-2026-109618 — corrupção durante OOM
O PHP usa um salto de controle ( `longjmp()`) para abandonar o processamento quando uma alocação de memória falha. Em determinados pontos da inicialização da requisição, a memória ainda está parcialmente inicializada. Se a alocação falhar nesse intervalo, o encerramento da requisição pode tratar estruturas inválidas como válidas e desviar o fluxo para um *callback* controlado pelo atacante.
Os caminhos conhecidos incluem números excessivos de cabeçalhos em partes multipart, campos aninhados, controles de arquivo vazios e requisições multipart sem `Content-Length` utilizável. Falhas de alocação provocadas pela própria aplicação também podem servir de gatilho. O ponto relevante é que o estouro ocorre durante o parsing da entrada, antes de qualquer código do site ser executado.
### CVE-2026-109619 — estado global obsoleto
O worker PHP mantém estado global — de erro, sessão, objetos e extensões — que aponta para memória pertencente a uma requisição. Normalmente esse estado é reiniciado antes da liberação da memória. Um erro fatal, um tempo de execução excedido ou um diagnóstico tardio pode interromper essa limpeza, deixando o worker com ponteiros para memória já liberada. A requisição seguinte, atendida pelo mesmo worker, pode consumir esse estado antes da inicialização normal.
Dois caminhos foram confirmados: o estado de *backtrace* de erros fatais no PHP 8.5, e o ciclo de *session upload progress*, que é habilitado por padrão e pode ser alcançado antes de a aplicação chamar `session_start()`. A exploração exige que produtor e consumidor sejam processados pelo mesmo worker; pools maiores reduzem a taxa de sucesso por tentativa, mas não eliminam a falha.
Fraquezas relacionadas nas advisories: CWE-416 ( *use after free*), CWE-755, CWE-824, CWE-1325 e CWE-1419. Este alerta não reproduz código de exploração; o objetivo é orientar inventário, correção e detecção.
## Versões afetadas e correção
| Linha do PHP | Versões afetadas | Primeira versão corrigida |
| --- | --- | --- |
| PHP 8.5 | anteriores a 8.5.12 | 8.5.12 |
| PHP 8.4 | anteriores a 8.4.27 | 8.4.27 |
| PHP 8.3 | anteriores a 8.3.36 | 8.3.36 |
| PHP 8.2 | anteriores a 8.2.35 | 8.2.35 |
| PHP 7.4, 8.0 e 8.1 | todas as versões dessas linhas | Sem release oficial; usar backport mínimo do PHP ou pacote corrigido do fornecedor/distribuição. |
| PHP 7.3 e anteriores | trilha de código identificada desde o PHP 5.4.0 | Sem correção do projeto PHP; migrar para uma linha suportada. |
Distribuições Linux e fornecedores de suporte de longo prazo receberam as correções antes da divulgação. Em pacotes de distribuição, o número da versão pode não mudar mesmo com o backport aplicado: valide pelo changelog e pelo advisory do fornecedor, não apenas por `php -v`.
### Como verificar o runtime correto
O binário do CLI pode ser diferente do runtime que atende o serviço web. Confirme o SAPI, a configuração carregada e o binário do FPM/Apache:
```bash
php -v
php -i | grep -E 'Server API|Loaded Configuration File|memory_limit|post_max_size'
php -i | grep -E 'session.upload_progress.enabled|fatal_error_backtraces'
php-fpm -v
apache2ctl -M | grep -i php
```
Em contêineres, verifique a imagem que está em execução, não apenas o host:
```bash
docker exec php -v
docker exec php -i | grep 'Server API'
```
- Reconstrua e redeploye imagens afetadas; atualizar o PHP do host não corrige uma imagem antiga em execução.
- Reinicie ou substitua todos os workers após a atualização, inclusive processos mantidos por *graceful reload*.
- Confirme a versão em cada pool, nó de balanceamento e instância autoscaling.
## Detecção
A investigação deve começar antes da data de divulgação: a Amazon relatou uma tentativa em 17 de outubro de 2026. Correlacione proxy/WAF, logs do PHP, logs do servidor web e telemetria de processos; nenhum sinal isolado é conclusivo.
### Requisições suspeitas
- Corpos `application/x-www-form-urlencoded` ou multipart com nomes de campos excessivamente longos, na casa de megabytes.
- Multipart com quantidade anormal de cabeçalhos por parte, campos aninhados, arquivos vazios ou muitos arquivos.
- Requisições sem `Content-Length` utilizável ou com tamanho declarado incompatível com o corpo observado.
- Bytes nulos ou dados binários inesperados em valores de formulário; sequências de muitos campos com o mesmo prefixo.
- Padrões repetidos contra o mesmo endpoint ou o mesmo worker, com respostas 200, 500 ou conexões encerradas.
### Logs do PHP e do servidor web
Erros de memória durante a inicialização da requisição, antes de qualquer script, são um sinal importante — especialmente quando correlacionados a POSTs grandes:
```bash
PHP Fatal error: Allowed memory size of ... bytes exhausted
(tried to allocate ... bytes) in Unknown on line 0
AH00052: child pid ... exit signal Segmentation fault (11)
```
Também merecem investigação avisos e erros fatais repetidos antes do script, mensagens de *Maximum execution time exceeded*, falhas em callbacks de upload/importação e encerramentos inesperados de workers. Esconder erros com `display_errors=0` ou `error_reporting` não impede o acesso ao estado obsoleto; para detecção, é necessário registrar os eventos.
### Processos, arquivos e rede
- Worker web gerando `sh`, `bash`, `curl`, `wget`, `nc`, interpretadores ou comandos de download.
- Novos arquivos PHP em diretórios de upload, alterações em arquivos existentes, `.user.ini`, `auto_prepend_file` ou configurações de PHP inesperadas.
- Tarefas agendadas, serviços, chaves SSH e usuários criados fora do padrão operacional.
- Conexões de saída para destinos desconhecidos, resolução DNS anômala, beacons e transferências de dados incompatíveis com o horário e o serviço.
- Em PHP 8.5, sinais do caminho de *fatal error backtraces*; em qualquer versão, atividade de *session upload progress* sem uso legítimo pela aplicação.
## Recomendações
1. **Inventarie todos os runtimes PHP.** Inclua servidores web, APIs, painéis, CMS, appliances, funções serverless, imagens de contêiner e componentes embarcados. Priorize o que está exposto à internet e o que usa `mod_php`.
2. **Atualize para a versão corrigida da linha em uso.** Aplique o pacote do fornecedor ou distribuição, ou compile a release oficial. Para 7.4, 8.0 e 8.1, use o backport mínimo do PHP ou o pacote corrigido do fornecedor; para 7.3 e anteriores, migre para uma linha suportada.
3. **Reconstrua imagens e reinicie os workers.** Atualize a imagem base, gere nova imagem, faça o deploy e confirme que nenhum worker antigo continua atendendo. Em FPM, valide o binário e a configuração de cada pool.
4. **Valide a correção.** Confirme a versão no SAPI web, não apenas no CLI; verifique cada nó, contêiner e ambiente. Registre a evidência no inventário de vulnerabilidades.
5. **Se não puder atualizar imediatamente, reduza a exposição.** Retire o serviço da internet ou restrinja por proxy/WAF; aplique as mitigações temporárias abaixo; trate o ativo como potencialmente comprometido.
6. **Reduza a superfície de entrada.** Limite tamanho de corpo, quantidade de campos, cabeçalhos por parte multipart, profundidade de aninhamento e número de uploads. Se a aplicação não usa multipart, bloqueie esse tipo de requisição no frontend.
7. **Monitore e cace ameaças.** Revise logs desde 17 de outubro de 2026, com atenção a POSTs grandes, erros de memória, segfaults, shells filhos de workers, arquivos novos e conexões de saída.
8. **Preserve evidências antes de limpar.** Em suspeita de comprometimento, isole o ativo, colete logs e processos e avalie a memória com a equipe de resposta antes de reiniciar ou reconstruir.
9. **Rotacione credenciais e segredos** após um comprometimento confirmado: senhas, chaves SSH, tokens de API, segredos de aplicação, certificados e credenciais de banco. Reconstrua a partir de uma imagem confiável.
10. **Comunique e registre.** Acione o SOC da GigaCandanga e os canais oficiais aplicáveis (CISC, CTIR Gov, CERT.br). Avalie obrigações de notificação de incidente e de proteção de dados pessoais.
## Mitigação temporária
> **Nenhuma configuração substitui a atualização**
>
> As medidas abaixo bloqueiam caminhos conhecidos e reduzem a exposição, mas não corrigem a falha. Aplique-as apenas como paliativo, com prazo definido para a atualização, e reinicie todos os workers depois de alterar a configuração.
| CVE | Medida | Limite da medida |
| --- | --- | --- |
| `109618` | Definir `memory_limit=-1` em configuração administrativa ( `php_admin_value`, pool FPM ou Apache), impedindo que a aplicação restabeleça um limite finito. | Remove o limite controlável, mas uma falha de alocação subjacente ainda pode alcançar o caminho vulnerável. Não é correção. |
| `109618` | Reduzir `post_max_size` (8 MB sem uploads; 32 MB com uploads), manter `upload_max_filesize` menor e impor limites de corpo, campos, partes e cabeçalhos no proxy/WAF. | Reduz a capacidade de provocar OOM, mas não cobre todas as formas de alocação. Os limites devem valer também sem `Content-Length`. |
| `109619` | Definir `session.upload_progress.enabled=0` em `php.ini`, pool FPM ou configuração do servidor; reiniciar todos os workers. | Bloqueia o caminho confirmado de upload progress, não outras famílias de estado global. |
| `109619` | No PHP 8.5, definir `fatal_error_backtraces=0` e reiniciar os workers. | Bloqueia apenas o caminho confirmado de backtrace de erro fatal. |
| Ambos | WAF/proxy com regras para formulários e multipart anômalos; isolamento de rede; retirada temporária do serviço da internet. | *Stopgap*: regras não inspecionam o que o parser descarta ou trunca, e não substituem a correção. |
**Evite:** usar `RLIMIT_AS` ou `RLIMIT_DATA` como limite de memória (eles podem provocar a falha de alocação que dispara a CVE-2026-109618); depender de `ini_set()` ou `.user.ini` para configurações que precisam valer antes do parsing; e esconder diagnósticos com `display_errors=0` — isso não impede o acesso ao estado obsoleto.
## Resposta a incidentes
Se houver suspeita de exploração, trate o servidor como comprometido até prova em contrário. A resposta deve preservar evidências e remover a causa raiz, não apenas os arquivos visíveis.
1. **Contenha:** isole o ativo da internet e de outros segmentos, preserve logs e, se a equipe de resposta orientar, colete memória e processos antes de reiniciar.
2. **Investigue:** revise logs de proxy/WAF, PHP, Apache/FPM, sistema e EDR; processos filhos de workers; arquivos PHP novos ou alterados; uploads; persistência (cron, serviços, chaves, usuários); conexões de saída e acessos a banco e storage.
3. **Eradique:** reconstrua o serviço a partir de imagem ou pacote confiável, com PHP corrigido; não confie apenas na remoção de um web shell.
4. **Recupere:** rotacione credenciais e segredos, valide a configuração, monitore o retorno e confirme a versão corrigida em todos os workers.
5. **Notifique:** acione o SOC da GigaCandanga e os canais oficiais (CISC, CTIR Gov, CERT.br). Avalie notificação de titulares e demais obrigações legais, inclusive LGPD, se houver dados pessoais afetados.
## Referências
Links externos abrem em nova aba. Consulte sempre a fonte oficial para o status mais recente.
- [PHP · Security advisory: Critical remote code execution vulnerabilities, update now](https://www.php.net/archive/2026.php#2026-10-21-5) PHP.net · 21 out. 2026
- [GHSA-w8hw-w9fx-j79w · RCE via OOM corruption (CVE-2026-109618)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) PHP Security Advisories · 21 out. 2026
- [GHSA-6wmf-4rv5-p3rp · RCE via stale global state (CVE-2026-109619)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) PHP Security Advisories · 21 out. 2026
- [CISA · Critical Vulnerabilities in PHP Require Immediate Patching](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) CISA · 21 out. 2026
- [CERT-EU · Security Advisory 2026-018: Critical Vulnerabilities in PHP](https://cert.europa.eu/publications/security-advisories/2026-018) CERT-EU · 21 out. 2026
- [CISC · CVE-2026-109618 e CVE-2026-109619 (CVSS 9.2): vulnerabilidades críticas de execução remota de código no PHP](https://www.gov.br/cisc/pt-br/alertas-de-ciberseguranca/cve-2026-109618-e-cve-2026-109619-cvss-9-2) CISC Gov.br · 21 out. 2026
- [Amazon Threat Intelligence identifica exploração de PHP2Shell antes da divulgação pública](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) AWS Security Blog · 21 out. 2026
- [PHP2Shell: critical vulnerabilities in PHP — detection, analysis and remediation](https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/) Datadog Security Labs · 21 out. 2026
- [Threat Brief: Critical Vulnerabilities in PHP CVE-2026-109618 and CVE-2026-109619](https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/) Unit 42 · 21 out. 2026
- [php2shell: perguntas frequentes sobre as vulnerabilidades críticas de RCE no PHP](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote) Tenable · 21 out. 2026, atualizado em 22 out. 2026
- [PHP2Shell FAQ: CVE-2026-109618 e CVE-2026-109619](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/) watchTowr · atualizado em 22 out. 2026
- [PHP2Shell · technical writeup](https://calif.io/php2shell/) Calif.io · 21 out. 2026
Outras fontes de consulta para resposta e investigação estão em [Links úteis](/site-md/links-uteis.md).
## Revisão
**Revisão 1.0** — 23 de outubro de 2026 — Publicação inicial. Fontes consultadas até 23 de outubro de 2026. O status de exploração e a inclusão no catálogo KEV podem mudar; confirme nas fontes oficiais.
Este alerta consolida informações públicas e tem caráter informativo. Não substitui os advisories dos fornecedores nem a avaliação da equipe responsável por cada ambiente. Teste as ações em ambiente controlado antes de aplicá-las em produção.