Em 21 de outubro de 2026, o PHP divulgou duas vulnerabilidades críticas no runtime da linguagem. Identificadas como CVE-2026-109618 e CVE-2026-109619, as falhas receberam CVSS 9.2 e podem permitir execução remota de código sem autenticação em servidores vulneráveis. Como o problema está no próprio PHP, a correção definitiva exige a atualização do runtime.
O time de segurança da Azion criou um hotfix contra o PHP2Shell (CVE-2026-109618 e CVE-2026-109619). Ele está disponível no Azion Marketplace como uma function que pode ser aplicada ao Firewall de qualquer aplicação.
O hotfix avalia cada requisição antes de ela chegar à origem e bloqueia os vetores de ataque confirmados pelo comunicado oficial do PHP. Não exige acesso ao servidor nem reinício de workers.
As duas falhas têm CVSS 9.2 e permitem execução remota de código sem autenticação, antes de qualquer linha da aplicação ser executada. O hotfix fecha esses caminhos antes da origem e dá às equipes tempo para aplicar a correção definitiva: atualizar o PHP.
O que o hotfix cobre
| Vetor de ataque | Status | Como é mitigado |
|---|---|---|
| CVE-2026-109619 pelo caminho de sessão (upload progress), confirmado pelo PHP | Mitigado no Firewall | Bloqueio total do campo PHP_SESSION_UPLOAD_PROGRESS, inclusive variações e disfarces |
| CVE-2026-109618, exaustão de memória na montagem da requisição | Mitigado no Firewall | Limites oficiais do PHP para tamanho do body, campos, partes do multipart, headers e profundidade de arrays |
Envios chunked sem Content-Length usados para contornar limites | Mitigado no Firewall | Medição do tamanho real do body |
| Técnica de upload progress + LFI → RCE (Exploit-DB 50156) | Mitigado no Firewall | Mesmo bloqueio do campo de upload progress |
| Requisições malformadas ou ilegíveis | Bloqueio preventivo | Multipart sem boundary ou body ilegível é bloqueado |
O hotfix é a primeira linha de defesa. A correção definitiva continua sendo atualizar o PHP para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. A atualização também fecha variantes da CVE-2026-109619 originadas dentro do servidor, como erros fatais e timeouts.
O que sabemos sobre as vulnerabilidades
O PHP2Shell reúne duas vulnerabilidades críticas no runtime do PHP, ambas avaliadas com CVSS v4.0 9.2. Requisições HTTP especialmente preparadas podem explorar falhas no gerenciamento de memória para causar indisponibilidade, expor dados processados pelo servidor ou executar código remotamente sem autenticação.
Antes da divulgação coordenada, os identificadores das CVEs começaram a circular publicamente e um vídeo de proof of concept foi publicado por engano. Cloudflare e Fastly também identificaram ferramentas e tráfego tentando explorar as falhas nas horas anteriores à publicação dos advisories. Esses registros demonstram atividade maliciosa, mas não significam que todas as tentativas tenham resultado em exploração bem-sucedida.
As duas vulnerabilidades aparecem quando uma requisição é interrompida em um ponto no qual o estado interno do PHP ainda não foi inicializado ou encerrado de forma segura:
| CVE | Nome | O que acontece |
|---|---|---|
| CVE-2026-109618 | RCE via corrupção por falta de memória (OOM) | O tratamento de falta de memória interrompe o PHP enquanto os dados internos da requisição ainda estão com a inicialização incompleta. Na limpeza, o PHP trata esses dados inválidos como válidos, o que abre caminho para a execução de código. |
| CVE-2026-109619 | RCE via estado global obsoleto | Um estado interno da requisição sobrevive depois que a memória dele foi liberada. Uma requisição seguinte, no mesmo worker, pode usar esse estado antes da reinicialização normal. |
Todas as instalações que atendem requisições web devem ser atualizadas, incluindo ambientes com PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. A possibilidade e a forma de exploração variam conforme o servidor, a configuração e o fluxo da aplicação. O risco é considerado maior no mod_php, para o qual foi demonstrado um caminho de RCE sem autenticação.
Como as falhas estão no runtime, atualizar somente o código da aplicação, o framework ou os plugins não resolve o problema. A única correção completa é instalar uma versão corrigida do PHP. Controles no Firewall ajudam a reduzir a exposição a vetores conhecidos, mas funcionam como uma camada adicional de proteção.
Como o hotfix funciona
O PHP2Shell explora o momento em que o PHP monta a requisição, antes de qualquer linha da aplicação ser executada. Por isso, o time de segurança da Azion desenhou o hotfix para impedir que a requisição maliciosa chegue ao PHP.
Ele é executado no Firewall, avalia cada requisição e toma exatamente uma decisão: liberar ou bloquear. O algoritmo segue seis princípios.
Uma decisão por requisição
Cada requisição recebe uma única resposta. Depois que o hotfix decide, nenhuma outra decisão é aplicada.
Se a análise terminar sem resposta por qualquer motivo, uma rede de segurança aplica a decisão padrão do modo configurado.
Custo proporcional ao risco
A inspeção vai da etapa mais leve à mais completa, e a maior parte do tráfego é decidida sem abrir o body:
- Contagem de headers, parâmetros da query string e cookies, e medição da profundidade de arrays nos nomes, como
a[b][c]. Vale para todas as requisições. - Liberação de requisições sem body, como GET, HEAD e OPTIONS.
- Bloqueio pelo tamanho declarado no
Content-Length, quando ele passa do limite. - Liberação de JSON, XML e similares com tamanho válido, que o PHP não transforma em variáveis.
- Leitura do body apenas em multipart, urlencoded e envios sem tamanho declarado.
Medir o que chega, não o que é declarado
Um atacante pode omitir o Content-Length e enviar o body em partes (chunked) para contornar limites. Nesses casos, o hotfix lê uma cópia do body e mede o tamanho real, byte a byte. O conteúdo original segue intacto para a origem.
Detectar o campo, não a grafia
O caminho confirmado da CVE-2026-109619 passa pelo campo PHP_SESSION_UPLOAD_PROGRESS. O hotfix procura esse nome em qualquer declaração de campo do multipart: com aspas duplas, aspas simples ou sem aspas, com espaços extras e em qualquer combinação de maiúsculas e minúsculas.
A busca percorre o body inteiro, e não só as partes que um parser consideraria válidas. Assim, diferenças entre parsers não abrem brecha.
Na dúvida, bloquear
Multipart sem boundary válido, body que não pode ser lido ou erro inesperado na análise resultam em bloqueio. A política é fail-closed: uma requisição que o hotfix não consegue avaliar não chega a um PHP vulnerável.
Limites oficiais do PHP
Os limites padrão seguem as recomendações do comunicado oficial do PHP e podem ser ajustados por aplicação:
| Regra | Limite padrão | Base |
|---|---|---|
| Body de upload (multipart) | 32 MB | post_max_size = 32M com uploads |
| Body dos demais tipos, inclusive JSON e XML | 8 MB | post_max_size = 8M sem uploads |
| Campos na query, cookies e formulário | 1.000 | Padrão do PHP para max_input_vars |
| Profundidade de arrays em nomes de campos | 32 | Abaixo do padrão do PHP para max_input_nesting_level (64) |
| Partes no multipart | 500 | Limite recomendado pelo PHP |
| Headers na requisição | 100 | Limite recomendado pelo PHP |
Campo PHP_SESSION_UPLOAD_PROGRESS | Bloqueio total | Caminho de sessão confirmado da CVE-2026-109619 |
Cada detecção registra o motivo, a CVE relacionada, o valor medido contra o limite (por exemplo, 501 partes contra 500), o IP, o host e o path. O conteúdo enviado pelo usuário não é gravado.
Como aplicar o hotfix
O hotfix está disponível no Azion Marketplace e pode ser aplicado ao Firewall de cada aplicação em poucos minutos. A recomendação é começar em modo de observação, para medir o comportamento com o tráfego real antes de bloquear:
- Instale o hotfix PHP2Shell a partir do Azion Marketplace.
- Aplique o hotfix ao Firewall da aplicação, com uma regra que cubra todos os caminhos do domínio (por exemplo, URI começa com
/), e não apenas a página inicial. - Ative o modo de observação e acompanhe as detecções no Real-Time Events por algumas horas.
- Se houver detecções em tráfego legítimo, ajuste os limites da configuração.
- Ative o modo de proteção para bloquear as requisições maliciosas.
| Modo | Comportamento |
|---|---|
| Observação | Registra cada detecção e libera a requisição |
| Proteção (padrão) | Registra cada detecção e bloqueia a requisição |
Cada detecção chega ao Real-Time Events com a tag PHP2SHELL, o motivo e a CVE relacionada:
| Motivo | Significado | CVE |
|---|---|---|
UPLOAD_PROGRESS_FIELD | Campo PHP_SESSION_UPLOAD_PROGRESS no multipart | CVE-2026-109619 |
BODY_TOO_LARGE_DECLARED | Content-Length acima do limite | CVE-2026-109618 |
BODY_TOO_LARGE_ACTUAL | Body real acima do limite, por exemplo em envios chunked | CVE-2026-109618 |
TOO_MANY_HEADERS, TOO_MANY_QUERY_VARS, TOO_MANY_COOKIES, TOO_MANY_BODY_VARS | Quantidade acima do limite | CVE-2026-109618 |
TOO_MANY_PARTS | Partes do multipart acima do limite | CVE-2026-109618 |
NESTING_TOO_DEEP | Profundidade de array acima do limite | CVE-2026-109618 |
MULTIPART_NO_BOUNDARY, BODY_READ_ERROR | Requisição malformada ou ilegível | Preventivo |
Alguns cenários legítimos podem exigir ajuste fino:
- APIs que recebem JSON ou XML acima de 8 MB: aumente o limite de body dos demais tipos.
- Uploads acima de 32 MB, como vídeos e backups: aumente o limite de body de upload.
- Painéis administrativos com formulários de mais de 1.000 campos: aumente o limite de campos.
Atualize o PHP e mantenha o hotfix ativo
A estratégia mais segura é a defesa em profundidade: atualizar o PHP para uma versão corrigida e manter o hotfix aplicado antes, durante e depois da atualização.
| Camada | Ação |
|---|---|
| 1. Correção | Atualizar o PHP para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou aplicar o pacote corrigido da distribuição. O PHP 8.1 e anteriores não recebem atualização oficial, mas há correções mínimas em código-fonte para 7.4, 8.0 e 8.1. Se o PHP for gerenciado por um provedor de hospedagem, solicite a atualização. |
| 2. Firewall (Azion) | Manter o hotfix aplicado ao Firewall de todas as aplicações que usam PHP. |
| 3. Configuração do PHP (CVE-2026-109619) | Definir session.upload_progress.enabled=0 no php.ini ou no pool FPM e reiniciar todos os workers, sem usar ini_set() ou .user.ini. No PHP 8.5, definir também fatal_error_backtraces=0. |
| 4. Configuração do PHP (CVE-2026-109618) | Usar post_max_size baixo (8M sem uploads, 32M com uploads) e limitar a memória por container ou cgroup. |
| 5. Detecção no host | Alertar quando php-fpm, php-cgi, httpd ou apache2 iniciarem shells, interpretadores ou ferramentas como curl, wget e nc. |
O time de segurança da Azion segue evoluindo seus mecanismos de defesa para responder a novas ameaças, incluindo ataques de dia zero.
Instale o hotfix no Azion Marketplace ou fale com um especialista da Azion para proteger suas aplicações PHP.
Perguntas frequentes
Atualizar o código da aplicação ou os plugins resolve o PHP2Shell? Não. As falhas estão no runtime do PHP, então só a atualização do PHP corrige o problema. O hotfix bloqueia os vetores confirmados até lá.
O hotfix substitui a atualização do PHP? Não. Ele é a primeira linha de defesa. A atualização também fecha variantes da CVE-2026-109619 originadas dentro do servidor, como erros fatais e timeouts.
O hotfix aumenta a latência? O impacto é mínimo. A inspeção vai da etapa mais leve à mais completa, e requisições sem body ou com JSON e XML de tamanho válido são liberadas sem leitura do body.
O hotfix altera o conteúdo enviado à origem? Não. Ele lê uma cópia do body, e o conteúdo original segue intacto. Os registros não gravam o conteúdo enviado pelo usuário.
Referências
- Comunicado de segurança do PHP, 21 de outubro de 2026
- CVE-2026-109618: GHSA-w8hw-w9fx-j79w (PHP Security Advisories)
- CVE-2026-109619: GHSA-6wmf-4rv5-p3rp (PHP Security Advisories)
- Sansec: PHP2Shell
- Exploit-DB 50156: PHP_SESSION_UPLOAD_PROGRESS Session Data Injection
