PHP2Shell: a maior ameaça à web em décadas
Na manhã de 21 de outubro de 2026, a comunidade de segurança cibernética recebeu o que pode ser a vulnerabilidade mais significativa do PHP desde o Log4Shell. Duas falhas de execução remota de código (CVE-2026-109618 e CVE-2026-109619), apelidadas de "PHP2Shell" por pesquisadores independentes, receberam pontuação CVSS de 9.2 de 10 — e, segundo algumas avaliações, um score máximo de 10.0 — e podem afetar todas as versões de PHP desde a 5.4, o que representa aproximadamente 69,3% dos sites cujo idioma do servidor é conhecido, conforme dados do W3Techs. O patch oficial estava agendado para 14:00 UTC do mesmo dia.
O que aconteceu
Na noite de 20 de outubro, identificadores CVE e informações preliminares sobre as duas falhas circularam no Hacker News e em redes sociais. A PHP Foundation, no mesmo dia, publicou um aviso de que liberaria patches em 21 de outubro às 14:00 UTC, com a ressalva de que a atualização poderia ser antecipada caso detalhes técnicos se tornassem públicos ou evidências de exploração em ambiente real fossem confirmadas.
As duas falhas, rastreadas como CVE-2026-109618 e CVE-2026-109619, permitem execução remota de código sem autenticação. A CERT-EU publicou o aviso 2026-018, nomeando ambas as CVEs e classificando-as como de exploração sem credenciais. A informação foi inicialmente mantida sob embargo para 22 de outubro, mas a exposição prematura antecipou o cronograma.
Por que o nome PHP2Shell?
A nomenclatura "PHP2Shell" cunhou-se por meio de relatórios independentes de pesquisadores de segurança, incluindo trabalho do pesquisador LCFR e da Calif.io, com demonstração de cadeia de exploração divulgada por Kirill Firsov. O nome deriva da capacidade de o exploit obter um shell no servidor vulnerável, permitindo ao atacante executar comandos arbitrários — o mesmo tipo de acesso que tipicamente resulta da invasão mais bem-sucedida de um servidor web.
Relatórios públicos sugerem que o CVE-2026-109618 envolve um bug de uso após liberação (use-after-free) no mecanismo de desserialização de variáveis do PHP. O código vulnerável reside no handler `session.upload_progress`, componente habilitado por padrão em todas as instalações do PHP, o que significa que não é necessário que a aplicação vítima ative qualquer configuração especial para estar exposta.
A análise técnica do pesquisador Qi Deng, publicada no repositório público `ikow/php2shell-poc`, detalha três cadeias de exploração distintas:
- Cadeia A: Injeção de sessão via formulário multipart + LFI → RCE. Aproveita que o `MULTIPART_EVENT_FORMDATA` aceita PHPSESSID do corpo POST, ignorando `use_only_cookies`, e armazena o nome de arquivo bruto na sessão sem validação. - Cadeia B: Use-after-free no `var_destroy` → RCE. Um payload de `unserialize()` com 2.000+ entradas transborda o limite `VAR_ENTRIES_MAX`, movendo objetos para a lista de dtor e disparando `__destruct` sem o `BG(serialize_lock)`. - Cadeia C: Incompatibilidade de handler → `__destruct` → RCE. Servidores com diretórios configurados com diferentes `session.serialize_handler` entre requisições podem sofrer mismatch do handler.
Todas as três cadeias verificadas em PHP 8.2.34 e 8.5.x em testes ASAN.
Qual versão exatamente está afetada?
A lista oficial de versões corrigidas seria divulgada junto com o patch, mas o pesquisador Kevin Beaumont já reportou as versões esperadas:
- PHP 8.5.x → 8.5.12 - PHP 8.4.x → 8.4.27 - PHP 8.3.x → 8.3.36 - PHP 8.2.x → 8.2.35
O que não será corrigido: todas as versões de PHP 5.x até 8.1.x estão em fim de vida e não receberão patches. Isso representa um problema particular, pois muitas infraestruturas legadas — especialmente sistemas governamentais, hospitais e provedores de hospedagem compartilhada — ainda rodam PHP 7.4 ou 5.6.
A PHP core developer Gina Peter Banyard deixou claro: "a única mitigação é patching/upgrading do PHP". O release manager Joe Ferguson confirmou que configurações de `ini` não resolvem o problema: "ini settings won't save you".
O impacto potencial
Com mais de 1,3 milhão de hosts expostos à internet estimando o pesquisador Silas Cutler, o escopo é comparável ao Apache Log4j de 2021. Plataformas como WordPress, Drupal, Joomla, Laravel e Magento rodam sobre PHP e estariam diretamente na mira. O problema é ainda agravado pelo fato de que, segundo o PHP Foundation, não existe configuração de mitigação parcial — a única solução confiável é atualizar.
A Cloudflare, que opera como CDN para milhões de sites PHP, já implantou regras de WAF provisórias. O CTO Dane Knecht confirmou que a empresa está "vendo ataques iniciais emergindo" e atualizando mitigações à medida que novos vetores aparecem.
O que esperar nas próximas horas
Segundo a Sansec, a exploração em massa deve começar em até 15 minutos após a liberação do patch — um fenômeno já observado em vulnerabilidades como o Log4Shell e o SpoolerForever. A CISA tem um histórico de inclusão de vulnerabilidades de PHP em seu Known Exploited Vulnerabilities catalog: duas falhas anteriores no PHP foram incluídas após serem utilizadas em campanhas de ransomware.
A pergunta que fica: em um ecossistema onde quase 70% dos sites rodam PHP e onde metade das versões afetadas não receberão correção, quantos servidores vão parar de responder nas próximas 48 horas?
---
PHP2Shell: The biggest web threat in decades
On the morning of October 21, 2026, the cybersecurity community faced what may be the most significant PHP vulnerability since Log4Shell. Two remote code execution flaws (CVE-2026-109618 and CVE-2026-109619), dubbed "PHP2Shell" by independent researchers, received a CVSS score of 9.2 out of 10 — and, according to some assessments, a perfect 10.0 — and can affect all versions of PHP from 5.4 onward, which represents approximately 69.3% of websites whose server-side language is known, according to W3Techs data. The official patch was scheduled for 14:00 UTC that same day.
What happened
On the night of October 20, CVE identifiers and preliminary information about the two flaws circulated on Hacker News and social media. The PHP Foundation, on the same day, published a notice that it would release patches on October 21 at 14:00 UTC, with the caveat that the update could be released earlier if technical details became public or if evidence of exploitation in the wild was confirmed.
The two flaws, tracked as CVE-2026-109618 and CVE-2026-109619, allow remote code execution without authentication. CERT-EU issued advisory 2026-018, naming both CVEs and classifying them as exploitable without credentials. The information was initially held under embargo until October 22, but the premature exposure accelerated the schedule.
Why the name PHP2Shell?
The "PHP2Shell" name was coined through independent reports from security researchers, including work by researcher LCFR and Calif.io, with an exploit chain demonstration shared by Kirill Firsov. The name derives from the ability of the exploit to obtain a shell on the vulnerable server, allowing the attacker to execute arbitrary commands — the same type of access that typically results from the most successful web server compromise.
Public reports suggest that CVE-2026-109618 involves a use-after-free bug in PHP's variable deserialization mechanism. The vulnerable code resides in the `session.upload_progress` handler, a component enabled by default on all PHP installations, which means that the victim application does not need to enable any special configuration to be exposed.
Researcher Qi Deng's technical analysis, published on the public repository `ikow/php2shell-poc`, details three distinct exploit chains:
- Chain A: Session injection via multipart form + LFI → RCE. It exploits the fact that `MULTIPART_EVENT_FORMDATA` accepts PHPSESSID from the POST body, ignoring `use_only_cookies`, and stores the raw filename in the session without validation. - Chain B: Use-after-free in `var_destroy` → RCE. A `unserialize()` payload with 2,000+ entries overflows the `VAR_ENTRIES_MAX` limit, moving objects to the dtor list and triggering `__destruct` without `BG(serialize_lock)`. - Chain C: Handler mismatch → `__destruct` → RCE. Servers with directories configured with different `session.serialize_handler` between requests can suffer handler mismatch.
All three chains verified on PHP 8.2.34 and 8.5.x in ASAN tests.
Which versions are affected?
The official list of patched versions would be released with the patch itself, but researcher Kevin Beaumont has already reported the expected versions:
- PHP 8.5.x → 8.5.12 - PHP 8.4.x → 8.4.27 - PHP 8.3.x → 8.3.36 - PHP 8.2.x → 8.2.35
What will not be patched: all PHP versions from 5.x to 8.1.x are end-of-life and will not receive fixes. This is a particular problem because many legacy infrastructures — especially government systems, hospitals, and shared hosting providers — still run PHP 7.4 or 5.6.
PHP core developer Gina Peter Banyard made it clear: "the only mitigation is patching / upgrading PHP." Release manager Joe Ferguson confirmed that `ini` settings do not solve the problem: "ini settings won't save you".
The potential impact
With more than 1.3 million internet-exposed hosts estimated by researcher Silas Cutler, the scope is comparable to Apache Log4j in 2021. Platforms such as WordPress, Drupal, Joomla, Laravel, and Magento run on PHP and would be directly in the crosshairs. The problem is further compounded by the fact that, according to the PHP Foundation, there is no partial mitigation configuration — the only reliable solution is to upgrade.
Cloudflare, which operates as a CDN for millions of PHP sites, has already deployed provisional WAF rules. CTO Dane Knecht confirmed the company is "seeing early attacks emerging" and updating mitigations as new vectors appear.
What to expect in the coming hours
According to Sansec, mass exploitation is expected to start within 15 minutes of the patch release — a pattern already observed in vulnerabilities such as Log4Shell and SpoolerForever. CISA has a history of including PHP vulnerabilities in its Known Exploited Vulnerabilities catalog: two previous PHP flaws were included after being used in ransomware campaigns.
The question: in an ecosystem where nearly 70% of websites run PHP and where half of the affected versions will not receive a fix, how many servers will go down in the next 48 hours?
---
PHP2Shell: la mayor amenaza a la web en décadas
En la mañana del 21 de octubre de 2026, la comunidad de seguridad cibernética enfrentó lo que puede ser la vulnerabilidad más significativa del PHP desde el Log4Shell. Dos fallos de ejecución remota de código (CVE-2026-109618 y CVE-2026-109619), apodados "PHP2Shell" por investigadores independientes, recibieron una puntuación CVSS de 9.2 de 10 — y, según algunas evaluaciones, un puntaje máximo de 10.0 — y pueden afectar todas las versiones de PHP desde la 5.4, lo que representa aproximadamente el 69,3% de los sitios web cuyo idioma del servidor es conocido, según datos del W3Techs. El parche oficial estaba programado para las 14:00 UTC del mismo día.
Qué sucedió
En la noche del 20 de octubre, identificadores CVE e información preliminar sobre los dos fallos circularon en Hacker News y en redes sociales. La PHP Foundation, ese mismo día, publicó un aviso de que liberaría parches el 21 de octubre a las 14:00 UTC, con la advertencia de que la actualización podría anticiparse si los detalles técnicos se hicieran públicos o se confirmaran evidencias de explotación en ambiente real.
Los dos fallos, rastreados como CVE-2026-109618 y CVE-2026-109619, permiten ejecución remota de código sin autenticación. La CERT-EU publicó el aviso 2026-018, nombrando ambas CVEs y clasificándolas como de explotación sin credenciales. La información fue inicialmente mantenida bajo embargo para el 22 de octubre, pero la exposición prematura aceleró el cronograma.
¿Por qué el nombre PHP2Shell?
La denominación "PHP2Shell" se cunó por medio de informes independientes de investigadores de seguridad, incluyendo trabajo del investigador LCFR y de la Calif.io, con demostración de cadena de explotación divulgada por Kirill Firsov. El nombre deriva de la capacidad de el exploit de obtener un shell en el servidor vulnerable, permitiendo al atacante ejecutar comandos arbitrarios — el mismo tipo de acceso que típicamente resulta de la invasión más exitosa de un servidor web.
Informes públicos sugieren que el CVE-2026-109618 involucra un bug de uso después de liberación (use-after-free) en el mecanismo de deserialización de variables del PHP. El código vulnerable reside en el handler `session.upload_progress`, componente habilitado por defecto en todas las instalaciones de PHP, lo que significa que no es necesario que la aplicación víctima active ninguna configuración especial para estar expuesta.
El análisis técnico del investigador Qi Deng, publicado en el repositorio público `ikow/php2shell-poc`, detalla tres cadenas de explotación distintas:
- Cadena A: Inyección de sesión vía formulario multipart + LFI → RCE. Aprovecha que el `MULTIPART_EVENT_FORMDATA` acepta PHPSESSID del POST, ignorando `use_only_cookies`, y almacena el nombre de archivo bruto en la sesión sin validación. - Cadena B: Use-after-free en `var_destroy` → RCE. Un payload de `unserialize()` con 2.000+ entradas desborda el límite `VAR_ENTRIES_MAX`, moviendo objetos a la lista de dtor y disparando `__destruct` sin el `BG(serialize_lock)`. - Cadena C: Incompatibilidad de handler → `__destruct` → RCE. Servidores con directorios configurados con diferentes `session.serialize_handler` entre peticiones pueden sufrir mismatch del handler.
Las tres cadenas verificadas en PHP 8.2.34 y 8.5.x en pruebas ASAN.
¿Qué versión exactamente está afectada?
La lista oficial de versiones corregidas sería divulgada junto con el parche, pero el investigador Kevin Beaumont ya reportó las versiones esperadas:
- PHP 8.5.x → 8.5.12 - PHP 8.4.x → 8.4.27 - PHP 8.3.x → 8.3.36 - PHP 8.2.x → 8.2.35
Lo que no será corregido: todas las versiones de PHP 5.x hasta 8.1.x están en fin de vida y no recibirán parches. Esto representa un problema particular, pues muchas infraestructuras legadas — especialmente sistemas gubernamentales, hospitales y proveedores de alojamiento compartido — aún corren PHP 7.4 o 5.6.
La PHP core developer Gina Peter Banyard dejó claro: "la única mitigación es patching/upgrading del PHP". El release manager Joe Ferguson confirmó que configuraciones de `ini` no resuelven el problema: "ini settings won't save you".
El impacto potencial
Con más de 1,3 millones de hosts expuestos a internet estimando el investigador Silas Cutler, el alcance es comparable al Apache Log4j de 2021. Plataformas como WordPress, Drupal, Joomla, Laravel y Magento corren sobre PHP y estarían directamente en la mira. El problema se agrava aún más por el hecho de que, según la PHP Foundation, no existe configuración de mitigación parcial — la única solución confiable es actualizar.
La Cloudflare, que opera como CDN para millones de sitios PHP, ya implantó reglas de WAF provisionales. El CTO Dane Knecht confirmó que la empresa está "viendo ataques iniciales emergiendo" y actualizando mitigaciones a medida que nuevos vectores aparecen.
Qué esperar en las próximas horas
Según la Sansec, la explotación en masa debe comenzar en hasta 15 minutos después de la liberación del parche — un fenómeno ya observado en vulnerabilidades como el Log4Shell y el SpoolerForever. La CISA tiene un historial de inclusión de vulnerabilidades de PHP en su Known Exploited Vulnerabilities catalog: dos fallos previos del PHP fueron incluidos tras ser utilizados en campañas de ransomware.
La pregunta: en un ecosistema donde casi el 70% de los sitios corren PHP y donde la mitad de las versiones afectadas no recibirán corrección, ¿cuántos servidores van a dejar de responder en las próximas 48 horas?
Fontes: The Verge, WIRED, Tenable
✓ Fontes independentes cruzadas e verificadas antes da publicação
