Category: Security · Vulnerability Management · Incident Response
Level: Foundational
Two critical bugs in the PHP engine itself went public this week. CVE-2026-109618 and CVE-2026-109619 — nicknamed "PHP2Shell" — are both unauthenticated remote code execution, both scored 9.2 on CVSS v4.0, and neither one lives in application code. They live in the engine every PHP app runs on top of.
The details leaked on October 20, ahead of the coordinated disclosure date. PHP moved the official release up two days and shipped patches on October 21: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Anything older than 8.2 has no official fix.
Most RCEs trace back to a decision made in a specific codebase: a deserialization flaw, a path traversal, a bad regex in an auth check. PHP2Shell doesn't. It lives in session.upload_progress, a feature of the engine itself, present since PHP 5.4. An application with properly validated input and no vulnerable dependencies could still be exploitable, because the bug sits below all of that — in the runtime interpreting the request, before application logic even runs on some configurations. Reporting this week called out Magento, Shopware and WooCommerce stores as exposed regardless of their own code quality.
CVE-2026-109618 is an out-of-memory corruption bug. When an OOM condition interrupts a vulnerable operation mid-flight, PHP can leave session data pointing at memory that's already been freed — which can leak addresses, enough to defeat ASLR as a step toward full RCE.
CVE-2026-109619 is a different bug: stale global state, combining a fatal-error-backtrace use-after-free with OPcache type confusion. A later request on the same worker can reuse memory that should have been freed. The fatal-error-backtrace path applies specifically to PHP 8.5.
The most widely circulated interim fix was setting session.upload_progress.enabled=0 and restarting all workers. That addresses 109619. It does not fully address 109618 — the advisory for 109618 doesn't even mention sessions as the trigger path.
Two bugs, one nickname, one disclosure date, two different stopgaps — and a lot of first-pass guidance flattened that into "turn off upload_progress and you're covered." Teams that stopped there were still carrying half the exposure.
PHP's own security team said, at release, that no functional exploit was known yet. That didn't hold. watchTowr's honeypot network picked up scanning within hours — 33 source addresses, 743 requests carrying the session upload progress field by 23:00 UTC the same day. Some of that traffic was tentatively linked to Potassium, a Mirai-derived botnet, though without confirmed payload execution.
A CVSS 9.2 pre-auth RCE doesn't need a public working exploit for mass scanning to start. The moment a CVE ID and a rough description exist, automated probing is already cheap enough to run at internet scale.
session.upload_progress has existed since 2012. Nobody thinks about it, nobody disables it by default, and almost nobody audits a feature that's been quietly sitting in the engine for fourteen years. That's exactly where this kind of bug survives — not in new code getting daily scrutiny, but in old code nobody's looked at since it shipped.
Related: watchTowr — PHP2Shell RCE Exploited
Categoria: Segurança · Gestão de Vulnerabilidades · Resposta a Incidentes
Nível: Fundamental
Dois bugs críticos no próprio motor do PHP vieram a público essa semana. CVE-2026-109618 e CVE-2026-109619 — apelidadas de "PHP2Shell" — são execução remota de código não autenticada, nota 9.2 no CVSS v4.0, e nenhuma das duas vive no código da aplicação. Vivem no motor sobre o qual toda aplicação PHP roda.
Os detalhes vazaram em 20 de outubro, antes da data coordenada de divulgação. O PHP antecipou o lançamento oficial em dois dias e liberou os patches em 21 de outubro: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Qualquer versão anterior à 8.2 ficou sem correção oficial.
A maioria dos RCEs remete a uma decisão tomada num código específico: uma falha de deserialização, um path traversal, uma regex ruim numa checagem de autenticação. O PHP2Shell não. Ele vive no session.upload_progress, um recurso do próprio motor, presente desde o PHP 5.4. Uma aplicação com input bem validado e nenhuma dependência vulnerável ainda assim podia ser explorável, porque o bug está abaixo de tudo isso — no runtime que interpreta a requisição, antes mesmo da lógica da aplicação rodar, em algumas configurações. As análises dessa semana apontaram lojas Magento, Shopware e WooCommerce como expostas independente da qualidade do próprio código.
CVE-2026-109618 é um bug de corrupção por falta de memória. Quando uma condição de OOM interrompe uma operação vulnerável no meio do caminho, o PHP pode deixar dados de sessão apontando pra memória já liberada — o que pode vazar endereços, o suficiente pra driblar o ASLR como passo rumo a um RCE completo.
CVE-2026-109619 é outro bug: estado global obsoleto, combinando um use-after-free no backtrace de erro fatal com confusão de tipo no OPcache. Uma requisição posterior no mesmo worker pode reutilizar memória que deveria ter sido liberada. O caminho de backtrace de erro fatal se aplica especificamente ao PHP 8.5.
A correção provisória mais divulgada foi setar session.upload_progress.enabled=0 e reiniciar todos os workers. Isso resolve a 109619. Não resolve totalmente a 109618 — o advisory da 109618 nem menciona sessões como caminho de disparo.
Duas falhas, um apelido, uma data de divulgação, dois paliativos diferentes — e boa parte da orientação de primeira hora achatou isso em "desliga o upload_progress e tá resolvido". Times que pararam aí continuavam carregando metade da exposição.
A própria equipe de segurança do PHP disse, no lançamento, que nenhum exploit funcional era conhecido ainda. Não durou. A rede de honeypots da watchTowr pegou varredura em questão de horas — 33 endereços de origem, 743 requisições carregando o campo de progresso de upload de sessão até as 23h UTC do mesmo dia. Parte desse tráfego foi tentativamente ligado ao Potassium, um botnet derivado do Mirai, embora sem execução de payload confirmada.
Um RCE pré-autenticação com CVSS 9.2 não precisa de exploit público funcionando pra que a varredura em massa comece. No momento em que existe um ID de CVE e uma descrição mínima, sondagem automatizada já é barata o suficiente pra rodar em escala de internet.
O session.upload_progress existe desde 2012. Ninguém pensa nele, ninguém desliga por padrão, e quase ninguém audita um recurso que ficou quieto no motor por quatorze anos. É exatamente aí que esse tipo de bug sobrevive — não em código novo sob escrutínio diário, mas em código antigo que ninguém olha desde que foi lançado.
Relacionado: watchTowr — PHP2Shell RCE Exploited