Fala com um especialista
PreçosNotíciasFala com um especialista
Voltar à sala de imprensa
Ameaças

PHP2Shell: Two Critical PHP RCE Flaws Get an Emergency Patch Today

PHP ships an out-of-band fix at 14:00 UTC on October 21 for two critical remote code execution flaws rated CVSS 9.2. Supported branches 8.2–8.5 get patches; end-of-life versions don't.

4T4Tify Team4Tify
Oct 21, 2026·4 min de leitura
PHP2Shell: Two Critical PHP RCE Flaws Get an Emergency Patch Today

PHP2Shell: Two Critical PHP RCE Flaws Get an Emergency Patch Today

PHP is pushing an out-of-band security release at 14:00 UTC on October 21, 2026 to fix two critical vulnerabilities that can lead to remote code execution. The PHP project rates them 9.2 on CVSS v4.0 but, as of writing, has not published technical details. Researchers have nicknamed the pair "PHP2Shell" — the name is theirs, not PHP's.

What happened

  • The flaws are tracked as CVE-2026-109618 and CVE-2026-109619.
  • Details first surfaced through a leak on October 20, which claimed a CVSS 10.0 score and impact on every PHP release since version 5, with little evidence behind it. The official score is 9.2, and the "every version since PHP 5" claim has not been confirmed by any official advisory.
  • PHP moved its release forward by a day and said it could ship even earlier if exploitation details became public or active exploitation was observed.
  • No in-the-wild exploitation and no public proof-of-concept had been reported at the time of writing.

Who gets a fix

Only the supported branches — 8.2, 8.3, 8.4 and 8.5 — receive patches. Trackers expect the next point releases (around 8.5.12, 8.4.27, 8.3.36 and 8.2.35), though PHP has not confirmed version numbers. Anything older — 8.1, 8.0, 7.x, 5.x — is end-of-life and gets no vendor patch.

That last group is large: a Shodan-based count put roughly 884,000 internet-facing hosts advertising PHP 8.1 or older in their HTTP banners. Banners are not proof of vulnerability, but they show how much legacy PHP is still exposed.

Why it matters

PHP runs a huge share of the web, often buried inside CMSs, hosting panels (cPanel, Plesk), vendor appliances and Windows software. Critical PHP bugs have historically been weaponized fast — CVE-2024-4577 saw exploit attempts within about 24 hours of disclosure. Once a patch is public, attackers can diff it to find the bug.

What to do now

  1. Inventory every PHP install — including PHP bundled in appliances, control panels and third-party software.
  2. Patch at release time. Prioritize internet-facing systems, and check whether your Linux distribution or hosting provider ships backported fixes.
  3. End-of-life branches: upgrade, or take the system off the internet / put it behind a VPN or a web application firewall until you can.
  4. If you can't patch immediately, isolate internet-facing PHP applications from public networks where possible.
  5. Watch what PHP starts. Alert on php-fpm, php-cgi, httpd or apache2 spawning shells, interpreters or download tools.
  6. Hunt for compromise: if something looks off, isolate the server, preserve web and PHP logs, and look for web shells, new files in the web root, new cron jobs, scheduled tasks and accounts.

Details are still thin — which configurations, SAPIs or components are affected may change once PHP publishes the advisory. Treat this as a "patch first, analyze second" event.

Knowing where outdated PHP is exposed is exactly the problem vulnerability scanning solves: our team identifies internet-facing hosts running vulnerable or end-of-life PHP versions so you know what to patch first — before attackers start scanning for it themselves.

Source: The Hacker News, "PHP2Shell: Two Unpatched Critical PHP RCE Flaws (CVSS 9.2) Trigger Emergency Security Alert" (October 21, 2026). Summarized and rewritten by the 4Tify Team.

PARTILHAR