Em outubro de 2026, foram divulgadas duas vulnerabilidades críticas no PHP, a linguagem de programação que está na base de boa parte da web. Estas vulnerabilidades foram identificadas por pesquisadores da Calif, da OpenAI e da Wiz, com o auxílio de modelos de inteligência artificial, e a notícia acendeu um alerta imediato na comunidade de cibersegurança.
Entre 20 e 22 de outubro de 2026, a PHP2Shell passou de rumor à disponibilização de um patch e, em seguida, à publicação de listas de indicadores de comprometimento (IoCs).
Em poucos dias, diferentes fornecedores de soluções de segurança publicaram endereços IP, domínios e hashes associados à exploração dessas vulnerabilidades.
(Acesso livre, não requer assinatura)
Neste artigo, analisaremos o que as fontes públicas revelam sobre o avanço da aplicação de correções na América Latina e no Caribe e apresentaremos recomendações para mitigar os riscos e corrigir essa vulnerabilidade.
PHP2Shell, o que é e quem é atingido por ele
PHP2Shell é o nome pelo qual são conhecidas duas vulnerabilidades no próprio interpretador do PHP: CVE-2026-109618 e CVE-2026-109619. Ambas têm nível de severidade CVSS 4.0 de 9,2 (9,8 no CVSS 3.1) e permitem a execução remota de código, sem necessidade de autenticação, por meio de requisições HTTP.
A severidade, no entanto, é apenas um dos critérios para definir prioridades. Quando a cruzamos com outros dois indicadores, o cenário muda:
Neste artigo, analisaremos o que as fontes públicas revelam sobre o avanço da aplicação de correções na América Latina e no Caribe e apresentaremos recomendações para mitigar os riscos e corrigir essa vulnerabilidade.
PHP2Shell, o que é e quem é atingido por ele
PHP2Shell é o nome pelo qual são conhecidas duas vulnerabilidades no próprio interpretador do PHP: CVE-2026-109618 e CVE-2026-109619. Ambas têm nível de severidade CVSS 4.0 de 9,2 (9,8 no CVSS 3.1) e permitem a execução remota de código, sem necessidade de autenticação, por meio de requisições HTTP.
A severidade, no entanto, é apenas um dos critérios para definir prioridades. Quando a cruzamos com outros dois indicadores, o cenário muda:
Indicador
CVE-2026-109618
CVE-2026-109619
O que mede
CVSS v4.0
9.2
9.2
Gravidade técnica em caso de exploração
EPSS (FIRST, 26/10)
99,981%
99,997%
Probabilidade de exploração nos próximos 30 dias
Catálogo KEV (CISA, 26/10)
Não incluída
Não incluída
Exploração confirmada
O EPSS da CVE-2026-109618 passou de 11,84% para 99,98% em 25 de outubro, segundo o histórico do CVEdetails. Em 26 de outubro, a API pública do FIRST atribuiu pontuações de 99,981% à CVE-2026-109618 e de 99,997% à CVE-2026-109619. Ambas as vulnerabilidades estão no percentil mais alto dentre todas as avaliadas. Por outro lado, em 26 de outubro, nenhuma das duas constava no catálogo KEV da CISA, que inclui apenas vulnerabilidades cuja exploração foi confirmada. Em 21 de outubro, a CISA publicou um alerta recomendando a aplicação urgente de patches, mesmo sem ter observado atividades de exploração, conforme resumido pela Tenable.
Por afetar o próprio PHP e não uma aplicação específica, o alcance é enorme. Qualquer site que utilize uma versão vulnerável do PHP pode estar exposto, seja ele baseado em WordPress, Drupal, Joomla ou em um desenvolvimento próprio. As versões corrigidas são 8.2.35, 8.3.36, 8.4.27 e 8.5.12, publicadas em 21 de outubro. As versões da série 8.1 e anteriores já não recebem atualizações oficiais editadas.
Os detalhes das vulnerabilidades vazaram antes da data prevista, e a equipe do PHP antecipou a disponibilização do patch. Além disso, a Amazon manifestou que sua rede de honeypots registrou uma tentativa de exploração em 17 de outubro, quatro dias antes da disponibilização pública do patch.
É importante não confundir essas vulnerabilidades com a CVE-2026-115560, divulgada em 23 de outubro, as quais algumas listas agrupam sob o mesmo nome. Trata-se de um outro problema, que exige uma configuração pouco comum e para o qual não há relatos de exploração, segundo o The Hacker News.
A região e a aplicação de patches
A Censys mantém um painel público que monitora, hora a hora, quantos serviços PHP expostos na Internet utilizam versões vulneráveis ou corrigidas, com detalhamento de cada país. Baseados nesses dados, analisamos 21 países da região.
Em 26 de outubro, na América Latina e no Caribe, 12,8% dos serviços PHP, com versão identificada, já tinham sido corrigidos. Em nível global, esse percentual era de 25,1%. A região aplica patches à metade da velocidade observada no restante do mundo.
Ambos os percentuais consideram como não corrigidos os servidores que utilizam versões do PHP para as quais já não são disponibilizadas correções, como a 7.4 e as anteriores. Esses servidores são vulneráveis e não há atualização disponível para aplicar. A Censys não divulga, conforme o país, quantos servidores se encontram nessa situação. Portanto, não é possível definir qual parcela dos 87% restantes na região precisa atualizar o PHP e qual precisa migrar para uma versão com suporte.
Outros dados ajudam a compreender o cenário:
Versões sem correção: em nível global, 73% dos serviços vulneráveis utilizam versões do PHP para as quais não há possibilidade de aplicação de patches. A versão 7.4.33, a mais comum na Internet, é uma delas. Para esses servidores, não há atualização a aplicar: é necessário migrar para uma versão com suporte. Por meio de outra abordagem, a Cisco Talos chega a uma conclusão semelhante e estima que cerca da metade dos sistemas PHP não receberá um patch.
Ritmo da aplicação de patches: a grande maioria das correções foi aplicada nos dias 22 e 23 de outubro. Depois disso, a curva de evolução estabilizou-se.
O que as listas de indicadores revelam
O cruzamento dos indicadores permitiu chegar a várias observações:
Cada fonte enxerga uma parte do cenário: os 6 endereços IP publicados pela Amazon estão todos na lista da FortiGuard, assim como 4 dos 6 endereços IP da Cisco Talos. No entanto, as listas da Amazon e da Talos não possuem nenhum endereço IP em comum. Cada fornecedor observa uma parcela distinta do mesmo fenômeno, e algumas relações parecem inserir dados de outras fontes.
Não há um único agente atacante: os 82 endereços IP da FortiGuard estão distribuídos por 56 sistemas autônomos (AS), e o sistema autônomo com maior concentração reúne 5 desses endereços. Há uma combinação de serviços de nuvem, hospedagem de baixo custo e redes de acesso residenciais e móveis, que poderiam corresponder a dispositivos comprometidos.
Domínios gerados no ritmo das notícias: os três domínios .com da lista, todos com “php2shell” no nome, foram registrados em 22 de outubro, entre 14 e 24 horas após a publicação da correção.
Orientações
Atualizar: para o PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou para o pacote corrigido da distribuição Linux utilizada.
Migrar das versões sem suporte: no PHP 8.1 ou em versões anteriores, não há correção oficial disponível; portanto, é necessário migrar para uma versão com suporte. Quem utiliza o PHP 8.2 pode aplicar a correção, mas deve planejar a migração, pois essa versão não receberá mais atualizações de segurança a partir de 31 de dezembro de 2026.
Aplicar medidas de mitigação provisórias: implementar as medidas parciais recomendadas pelo PHP para cada CVE, como limitar o tamanho das requisições POST e desabilitar a diretiva session.upload_progress, reiniciando os processos do PHP. Porém, estas medidas não substituem a atualização.
Verificar indícios de comprometimento: se o servidor esteve exposto e sem a correção aplicada antes de 21 de outubro, recomenda-se procurar indícios de comprometimento, como requisições POST de grande tamanho contendo o campo PHP_SESSION_UPLOAD_PROGRESS e arquivos inesperados no diretório de armazenamento das sessões.
Considerações finais e recomendações
O cruzamento de listas públicas de indicadores fornece um contexto que nenhuma lista oferece isoladamente: cada fornecedor observa partes diferentes do fenômeno, por trás dos endereços IP há dezenas de redes e alguns indicadores surgem poucas horas após a divulgação da notícia. Antes de bloquear ou atribuir responsabilidades, é melhor verificar a origem de cada dado.
Na região, o desafio não significa apenas a aplicação da correção: uma parcela significativa dos servidores executa versões do PHP que já não estão recebendo correções de segurança. Para esses servidores, a única solução é migrar para uma versão com suporte, o que exige um esforço considerável.
Incentivamos os CSIRTs (equipes de resposta a incidentes de segurança computacional), pesquisadores e operadores da região a compararem essas listas com seus próprios registros de acesso a servidores web e registros de rede, priorizarem a migração das versões do PHP sem suporte e compartilharem suas observações.
