Em Resumo
Você é afetado?
Se você executa PHP que atende requisições web (PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP ou LiteSpeed) e a versão é anterior a 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, considere que você é afetado. Isso inclui aplicações construídas sobre PHP, como WordPress, Drupal, Magento e Laravel.
A TR7 é afetada?
Não. Os appliances TR7 não têm nenhum componente PHP que processe requisições HTTP, portanto os produtos TR7 não são afetados por essas vulnerabilidades. Os detalhes estão em A TR7 É Afetada?.
O que fazer agora
- Atualize o PHP nos seus servidores de aplicação web e reinicie todos os workers PHP.
- Se não puder atualizar hoje, aplique nesses servidores as configurações temporárias do PHP indicadas abaixo.
- Até que a atualização esteja concluída, aplique as configurações de proteção essenciais no TR7 WAF-WAAP; colocar suas aplicações PHP em Blocking mode é a primeira delas.
Informações Principais
| ID do boletim | TR7-SA-2026-001 |
|---|---|
| Nome | PHP2Shell |
| CVEs | CVE-2026-109618 (execução remota de código por corrupção em situação de falta de memória), CVE-2026-109619 (execução remota de código por estado global obsoleto) |
| Avisos oficiais | Anúncio do PHP Security Team GHSA-w8hw-w9fx-j79w (CVE-2026-109618) GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) |
| Severidade | CVSS v4.0 9.2, Crítica (PHP Security Team) |
| Autenticação necessária | Não |
| Versões corrigidas | PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 |
| Branches mais antigos | O PHP Security Team publicou backports em código-fonte para o PHP 7.4, 8.0 e 8.1. As distribuições Linux fornecem seus próprios pacotes corrigidos. |
| Exploração | Tentativas de exploração estão sendo relatadas. Até 22 de outubro de 2026, nenhum comprometimento bem-sucedido havia sido confirmado publicamente. |
| CISA KEV | Não listada no catálogo de 21 de outubro de 2026 |
O Que Aconteceu
- 20 de outubro de 2026 Os detalhes das vulnerabilidades se tornaram públicos antes da divulgação coordenada.
- 21 de outubro de 2026 O projeto PHP lançou as versões corrigidas e publicou os avisos GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp.
- 21-22 de outubro de 2026 Foram relatadas tentativas de exploração, e surgiu código público de prova de conceito.
Como o Ataque Funciona
As duas vulnerabilidades estão no próprio PHP, não no código da aplicação. O ataque ocorre enquanto o PHP ainda está lendo a requisição recebida, antes que qualquer linha da sua aplicação seja executada. Atualizar o WordPress, um plugin ou o seu próprio código não corrige o problema.
- CVE-2026-109618 explora o momento em que o PHP fica sem memória. Os atacantes enviam requisições que forçam o PHP a usar muita memória enquanto ele analisa dados de formulário e uploads de arquivos, de modo que o PHP pare em um estado inseguro.
- CVE-2026-109619 deixa dados obsoletos em um worker PHP após uma requisição, e uma segunda requisição ao mesmo worker os utiliza. Um caminho documentado usa o recurso session upload progress do PHP, que vem habilitado por padrão e é acionado por um campo de formulário chamado
PHP_SESSION_UPLOAD_PROGRESS.
Como as requisições que transportam esses ataques são, em sua maioria, requisições multipart/form-data (upload de arquivos), corpos de requisição grandes e requisições repetidas, um firewall de aplicação web pode ver e restringir muitas delas. Ele não consegue ver o que acontece dentro da memória do PHP.
A TR7 É Afetada?
Essas vulnerabilidades estão na própria camada de tratamento de requisições do PHP e afetam servidores de aplicação que executam PHP. Os appliances TR7 não têm nenhum componente PHP que processe requisições HTTP, portanto os produtos TR7 não são afetados por essas vulnerabilidades.
O Que Você Deve Fazer Agora
O trabalho ocorre em dois lugares: seus próprios servidores de aplicação web que executam PHP e o TR7 WAF-WAAP. Cada seção numera suas próprias etapas.
Nos seus servidores
Passo 1: Atualize o PHP nos seus servidores de aplicação web (a única correção completa)
- Atualize o PHP nos servidores que executam sua aplicação web para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou instale o pacote corrigido da sua distribuição Linux. Os pacotes de distribuição frequentemente mantêm o número de versão antigo; verifique os números das CVEs no changelog do pacote.
- Reinicie todos os workers PHP (pools do PHP-FPM, Apache, LiteSpeed, workers de longa duração). Os processos em execução continuam usando o código antigo até serem reiniciados.
- Recompile as imagens de contêiner que incluem seu próprio PHP. Atualizar o host não atualiza o PHP dentro de uma imagem.
- O PHP 8.1 e versões anteriores não recebem mais atualizações do projeto PHP. Planeje a migração para um branch suportado.
Passo 2: Configurações temporárias do PHP nos seus servidores de aplicação web (se você não puder atualizar hoje)
Essas configurações são feitas na configuração do PHP do servidor que executa sua aplicação web (php.ini ou configurações do pool do PHP-FPM). O PHP Security Team lista essas medidas. Elas reduzem a exposição a caminhos de ataque específicos, mas não tornam uma instalação segura.
| Configuração | Finalidade |
|---|---|
session.upload_progress.enabled = 0 | Elimina o caminho session upload progress da CVE-2026-109619. Reinicie todos os workers. O PHP Security Team sugere mantê-la desativada após o patch, se você não precisar dela. |
fatal_error_backtraces = 0 (PHP 8.5) | Elimina o caminho do backtrace de erro fatal |
post_max_size = 8M (sem uploads) ou 32M (com uploads), com upload_max_filesize menor | Reduz a memória que um atacante pode forçar o PHP a usar |
memory_limit = -1, definido com php_admin_value | Elimina a falha controlável do limite de memória. Uma única requisição pode então usar toda a memória do servidor; use limites de contêiner ou de cgroup, nunca RLIMIT_AS ou RLIMIT_DATA |
No TR7 WAF-WAAP
Se você puder atualizar o PHP imediatamente, essa é a correção real. Se não puder, até que a atualização esteja concluída você pode proteger suas aplicações PHP contra esses ataques com as configurações de segurança que o TR7 WAF-WAAP já oferece, sem nenhuma atualização da TR7. As três configurações do Passo 1 são a proteção essencial; as medidas adicionais do Passo 2 reduzem ainda mais a superfície de ataque, então escolha as que se adequam à sua aplicação. Aplique as configurações por vService e teste-as primeiro em um vService fora de produção.
Passo 1: Proteção essencial
1.1 Coloque o WAF em Blocking mode
Um WAF que apenas monitora não detém um ataque. Quando o WAF é habilitado pela primeira vez, ele inicia em Learning mode; o Monitor mode apenas registra. Para cada vService PHP, abra a tela WAF Mode e confirme que ele está em Blocking mode.
Atenção: Antes de mudar, revise as exclusões de assinatura aprendidas em cada campo. Se as exclusões de um campo excederem o valor Max. owasp exclusions, a inspeção de assinaturas é desativada para esse campo.
1.2 Adicione duas regras personalizadas
Na tela Signature & Rule Library (WAF → Signature & Rule Library → Add), adicione separadamente as duas regras abaixo. Inicie ambas no estado Monitor e altere-as para Enabled depois de revisar os Event Logs. As regras se aplicam a todos os vServices protegidos pelo WAF.
Regra 1: Campo session upload progress
- Pattern (Regex):
PHP_SESSION_UPLOAD_PROGRESS - Inspection Scopes: Form e Raw
- Score: Very High
Detecta o campo de formulário que aciona o caminho session upload progress da CVE-2026-109619. Para aplicações que usam esse recurso legitimamente, exclua apenas os caminhos de upload que precisam dele.
Regra 2: Campo de formulário PHPSESSID
- Pattern (Regex):
^PHPSESSID$ - Inspection Scopes: Form
- Score: Very High
Detecta requisições que transportam o ID de sessão em um campo de formulário chamado PHPSESSID em vez de um cookie; alguns caminhos de ataque usam essa forma, e ela é rara no tráfego legítimo. Se sua aplicação usar um nome de sessão diferente (session.name), use esse nome.
Para que as regras funcionem: As regras são verificadas pelas inspeções Form e RAW do tipo de página correspondente à requisição. Em um tipo de página sem inspeção Form, os corpos de formulário e de upload de arquivos não são verificados.
- Mantenha o OWASP check ativado na regra Any Paths e nos tipos de página que têm sua própria inspeção Form ou RAW.
- Adicione uma inspeção Form e RAW própria a cada tipo de página glob com os botões Add common rule for Form e Add common rule for Raw; não confie em configurações herdadas.
1.3 Bloqueie corpos grandes e não inspecionáveis
Na tela WAF Rules, faça duas configurações na inspeção RAW:
- Defina Raw Body Size como o maior corpo de que o caminho precisa (em bytes; por exemplo, 8388608 = 8 MB em caminhos sem uploads, 33554432 = 32 MB em caminhos de upload). O intervalo padrão permite corpos de até 256 MB.
- Mude a chave de corpo não analisado de Allow unparsed body para Block unparsed body. Caso contrário, um corpo que não caiba no buffer de inspeção é encaminhado ao Backend Service sem nenhuma inspeção de conteúdo.
Onde? O WAF inspeciona uma requisição apenas com as configurações do tipo de página correspondente ao seu caminho. Faça essas duas configurações na regra Any Paths, em cada tipo de página que mostra Raw na coluna Check Fields e em cada tipo de página glob; em um tipo de página glob que não tenha inspeção RAW, adicione primeiro uma com Add common rule for Raw.
Atenção: Raw Body Size se aplica enquanto Structure Checks estiver ativado, na tela Checks. Teste primeiro uploads grandes legítimos. Corpos enviados sem tamanho declarado não são medidos por esse limite; em caminhos fora dos caminhos de upload, eles podem ser bloqueados com o 2.1.
Passo 2: Medidas adicionais
Essas medidas complementam a proteção essencial; escolha as que se adequam à sua aplicação.
2.1 Bloqueie uploads de arquivos onde você não precisa deles
As requisições de ataque são, em sua maioria, requisições multipart/form-data (upload de arquivos). Se apenas alguns caminhos da sua aplicação aceitam arquivos, bloqueie as requisições multipart para todos os outros caminhos com uma regra do balanceador de carga. A regra consiste em duas condições e uma ação Block. Todas as telas são acessadas pelo Configuration Menu, aberto pelo logotipo da TR7 no canto inferior esquerdo.
A. Crie as condições (Load Balancer → Conditions → Add)
- Condição de requisição multipart: Criteria = HTTP header, método de correspondência Includes, Header Name = Request →
Content-Type, Query =multipart/form-data, Case Insensitive ativado. Informe um Condition Name comomultipart-requeste salve com Add. - Condição de caminhos de upload: Criteria = Path, método de correspondência Regex e, em Query, informe os caminhos que aceitam arquivos (por exemplo,
^/(upload|media/upload)). Informe um Condition Name comoupload-pathse salve com Add.
B. Crie a ação Block (Load Balancer → Actions → Add)
- Informe um Action Name (por exemplo,
block-multipart), Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 403. - Em Conditions, selecione
multipart-requeste!upload-pathsno mesmo grupo de condições (padrão and). Cada condição aparece duas vezes na lista: ela mesma e sua negação (NOT), que começa com!;!upload-pathssignifica "não é um dos caminhos de upload". - Ative o Hit Counter para contar as requisições bloqueadas e salve com Add.
C. Adicione a ação ao vService
- Em Load Balancer → Load Balancer vService List, selecione o vService e clique em Edit, selecione a ação no campo Actions, em Details, e clique em Save.
D. Bloqueie também corpos enviados sem tamanho declarado
- Crie outra condição HTTP header: método de correspondência Is present, Header Name = Request →
Content-Length, Condition Name, por exemplo,has-length. - Crie uma segunda ação Block (On Request, Standard, 403). Em Conditions, selecione a condição predefinida If HTTP method is POST,
!has-lengthe!upload-pathsno mesmo grupo de condições e adicione a ação ao campo Actions do vService. A condição POST é obrigatória; sem ela, requisições GET sem corpo também são bloqueadas.
O limite de tamanho do 1.3 não vê o tamanho real de um corpo enviado sem tamanho declarado. Esta regra cobre, em caminhos fora dos caminhos de upload, tanto uploads HTTP/1.1 transmitidos em fluxo (chunked) quanto corpos HTTP/2 sem tamanho declarado. Requisições POST sem corpo e sem o cabeçalho Content-Length também correspondem a esta regra; teste-a primeiro em um vService fora de produção.
Verificação: Uma requisição multipart (curl -s -o /dev/null -w '%{http_code}\n' -F 'a=b' https://www.example.com/), uma requisição HTTP/1.1 chunked (curl -s -o /dev/null -w '%{http_code}\n' --http1.1 -H 'Transfer-Encoding: chunked' -d 'a=b' https://www.example.com/) e uma requisição HTTP/2 sem tamanho declarado (printf 'a=b' | curl -s -o /dev/null -w '%{http_code}\n' --http2 -X POST -T - https://www.example.com/) para um caminho fora dos caminhos de upload devem receber 403, e as requisições para os seus caminhos de upload devem passar. --http1.1 é obrigatório para o teste HTTP/1.1: o curl usa HTTP/2 sobre https por padrão e não envia Transfer-Encoding por HTTP/2. O contador aparece na aba Action Hits do painel do vService.
Atenção: Uma ação Block sem nenhuma condição selecionada se aplica a todas as requisições ao vService. Liste todos os caminhos de upload de forma completa e teste a regra primeiro em um vService fora de produção.
2.2 Limite as requisições POST por cliente
Esta regra não detém um ataque direcionado: o exploit pode funcionar com apenas algumas requisições. Ela aumenta, porém, o custo de ferramentas automatizadas que testam muitos alvos. A regra conta as requisições POST de cada IP de cliente e bloqueia com 429 as requisições POST de um cliente acima do limiar. O bloqueio é removido automaticamente quando o contador cai abaixo do limiar.
A. Crie a ação de contagem (Load Balancer → Actions → Add)
- Informe um Action Name, Action Type = Advanced Traffic Inspection, Fields to Track = Client IP address, Traffic Tag = por exemplo
post-rate(3-20 caracteres; letras, dígitos,-,_), Tracking Period = 1 minuto. - Em Conditions, selecione a condição predefinida If HTTP method is POST e salve com Add. Assim, apenas as requisições POST são contadas.
B. Crie a condição de limiar (Load Balancer → Conditions → Add)
- Criteria = Tracking Condition, Tracked Table =
post-rate, Tracking Criteria = HTTP requests e o limiar com Tracking Operator (por exemplo,> 100). Salve com Add.
C. Crie a ação Block (Load Balancer → Actions → Add)
- Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 429.
- Em Conditions, selecione a condição de limiar do passo 3 e If HTTP method is POST no mesmo grupo de condições (padrão and). Sem a condição POST, as requisições GET de um cliente acima do limiar também são bloqueadas. Salve com Add.
D. Adicione as ações ao vService
- No formulário Edit do vService, em Details → Actions, selecione a ação de contagem primeiro e a ação Block em segundo lugar, e clique em Save. As ações são executadas na ordem da lista.
Verificação: Na aba Logs & Tracking do vService, selecione a tabela de rastreamento da ação de contagem na lista Logs Type; são exibidos os contadores de POST por cliente. Defina o limiar com base no tráfego normal da sua aplicação: observe na tabela os POSTs por minuto de clientes legítimos (por exemplo, sistemas que usam uma API ou organizações atrás de um IP de saída compartilhado) e defina o limiar acima deles.
2.3 Coloque a proteção L7 DDoS em Active
Se a proteção Bot/DDoS estiver incluída na sua licença, a Source IP Request Protection, em L7 DDoS Protection, limita o número total de requisições que um único endereço de origem pode fazer em um período. Diferentemente do 2.2, ela conta todas as requisições e não precisa de regra adicional.
- No formulário Edit do vService, selecione L7 DDoS & Threat Protection em Details e clique em Save (se não estiver ativada). Quando a proteção é ativada, a L7 DDoS Protection inicia no modo Monitor; nesse modo, as violações de limite são apenas registradas como eventos.
- Em Left Monitor Panel → Bot/DDoS Protected vServices → vService → Bot/DDoS Management, clique no link Edit do cartão L7 DDoS Protection.
- Defina DDoS Protection = Active e salve com o botão Edit.
- No cartão, clique no ícone de lápis do bloco Source IP Request Protection. Defina Time Window (padrão 10 segundos), Request Limit (padrão 1000) e Limit Action (padrão Show Captcha; também é possível selecionar Block) de acordo com o tráfego da sua aplicação e salve com o botão Edit.
Atenção: Acompanhe os eventos no modo Monitor por algum tempo antes de mudar para Active. Repita a mesma observação quando reduzir o Request Limit.
Verifique se você foi alvo
Consulte Detecção e Monitoramento. Tentativas de exploração foram relatadas antes da divulgação pública, portanto revise os logs a partir de 17 de outubro de 2026.
O Que um WAF Pode e Não Pode Fazer
| Um WAF pode | Um WAF não pode |
|---|---|
| Bloquear formatos de requisição conhecidos, como o campo session upload progress | Corrigir o código vulnerável dentro do PHP |
| Limitar o tamanho do corpo, os caminhos de upload e as taxas de requisição | Medir o uso de memória dentro do processo PHP |
| Bloquear uploads em caminhos que não precisam deles | Ver requisições que chegam ao seu servidor sem passar por ele |
| Registrar requisições bloqueadas e com taxa limitada | Desfazer código que já foi executado no servidor |
As regras do WAF ganham tempo para a atualização; a correção duradoura é atualizar o PHP. Para que essas proteções funcionem, todo o tráfego para suas aplicações PHP deve passar pelo TR7 WAF-WAAP.
Detecção e Monitoramento
No TR7
- Na tela Event Logs de cada vService protegido pelo WAF, filtre os registros pelas suas regras personalizadas e observe o campo correspondente e a pontuação.
- Na mesma tela, revise as requisições bloqueadas pelas regras de tamanho de corpo e de corpo não analisado.
- Se você aplicou as medidas adicionais, acompanhe os contadores das regras do balanceador de carga na aba Action Hits do painel do vService e, na tabela de rastreamento da aba Logs & Tracking, os clientes que atingiram o limite de taxa de POST.
Nos seus servidores
- Procure nos logs de erro do PHP erros como
Allowed memory size ... exhausted, falhas de workers e respostas HTTP 500 repetidas; preste atenção àqueles que ocorrem logo após requisiçõesmultipart/form-datagrandes. - Verifique nas respostas se há cookies
PHPSESSIDanormalmente grandes ou malformados. - Verifique nas raízes web se há arquivos novos ou alterados e procure processos inesperados iniciados pelo usuário do servidor web, novos cron jobs e conexões de saída inesperadas.
Perguntas Frequentes
Não. Os appliances TR7 não têm nenhum componente PHP que processe requisições HTTP, portanto os produtos TR7 não são afetados por essas vulnerabilidades. Consulte A TR7 É Afetada?
Nenhum WAF consegue proteger totalmente contra essas vulnerabilidades. O TR7 WAF-WAAP reduz a superfície de ataque e bloqueia os caminhos de ataque conhecidos; atualizar o PHP é a única correção completa.
Use contra o PHP2Shell as duas regras personalizadas descritas em TR7 WAF-WAAP 1.2; elas se aplicam imediatamente a todos os vServices protegidos pelo WAF.
Não. As vulnerabilidades estão no runtime do PHP. Atualize o próprio PHP ou peça ao seu provedor de hospedagem que faça isso.
Podem. Limites de tamanho de corpo, bloqueio de uploads e as regras personalizadas podem afetar uploads e formulários legítimos. Nas regras do WAF, comece em Monitor mode, revise os Event Logs e depois mude para Blocking mode. Teste as regras do balanceador de carga (2.1, 2.2) primeiro em um vService fora de produção.
Histórico de Atualizações
- 23 de outubro de 2026 Publicação inicial.
Referências
- Anúncio do PHP Security Team: php.net/archive/2026.php
- GHSA-w8hw-w9fx-j79w (CVE-2026-109618): github.com/php/php-src
- GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): github.com/php/php-src
- CVE-2026-109618: cve.org
- CVE-2026-109619: cve.org
- CISA Known Exploited Vulnerabilities Catalog: cisa.gov
- Documentação da TR7: docs.tr7.com
Precisa de ajuda para aplicar essas configurações?
A Equipe de Suporte da TR7 pode revisar a configuração do seu WAF e ajudar você a implantar essas proteções. Entre em contato com seu representante TR7 ou com a Equipe de Suporte da TR7 pelo e-mail support@tr7.com.