PHP2Shell CISA KEV Exploited Explained: Two Critical PHP Flaws, 29 October Deadline and What to Patch

on

PHP2Shell CISA KEV exploited explained — PHP logo

Image: PHP logo (public domain, Colin Viebrock / Wikimedia Commons) — the official logo of the PHP language hit by the PHP2Shell flaws.

TL;DR — PHP2Shell CISA KEV exploited explained: On 26 October 2026, America's CISA added the two critical PHP2Shell flaws — CVE-2026-109618 and CVE-2026-109619 — to its Known Exploited Vulnerabilities (KEV) catalog, confirming they are being exploited in the wild. US federal agencies must patch by 29 October; everyone else should treat that date as the deadline too. Patch to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart every PHP worker, and check whether the server was touched before you patched.

📌 KEY HIGHLIGHTS

  • CISA added both PHP2Shell flaws to the KEV catalog on 26 October 2026 — its formal confirmation that exploitation is happening, not just possible.
  • Both flaws score 9.2 out of 10 (CVSS 4.0) and allow unauthenticated remote code execution — an attacker needs no login to run code on the server.
  • Federal deadline: 29 October 2026 under Binding Operational Directive 26-04. CISA says systems that cannot be patched, or still run unsupported PHP, should be taken offline until they can be.
  • Apache servers using mod_php carry the highest risk, according to the PHP Group — but PHP-FPM, CGI, FrankenPHP and LiteSpeed are all in scope.
  • Patching does not prove the server was never breached: confirmed compromises were already reported on 24 October, before the KEV listing.

What happened?

PHP2Shell is the nickname researchers gave to two memory-safety flaws in the PHP language itself, disclosed on 21 October 2026 with emergency fixes. Until 26 October, the public picture was "exploitation attempts observed" — scanning, honeypot hits and proof-of-concept code, but no official confirmation of real-world exploitation at scale.

That changed on 26 October, when the US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-109618 (PHP Memory Corruption Vulnerability) and CVE-2026-109619 (PHP Stale Internal Request-State Vulnerability) to its Known Exploited Vulnerabilities catalog. CISA's own wording is blunt: "These types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose significant risks to the federal enterprise."

KEV listing matters because of how CISA builds the catalog: it only lists flaws it has independently confirmed are being exploited. It is not a prediction — it is a confirmation. Under Binding Operational Directive 26-04, US federal civilian agencies must remediate KEV flaws on publicly exposed assets that grant total control after exploitation, and must check whether attackers compromised the system before the patch went on. The catalog entry carries a due date of 29 October 2026.

Two honest limits on what the listing proves. First, KEV inclusion confirms exploitation exists; it does not establish how many organisations have been compromised or whether ransomware groups are using the flaws — those figures are not in CISA's announcement. Second, the 29 October deadline binds US federal agencies directly; CISA "encourages all organizations" to follow the same urgency, but private companies and website owners are not legally bound by BOD 26-04. Treat the date as the practical deadline anyway: attackers do not wait for paperwork.

PHP2Shell CISA KEV exploited explained: the two flaws

Both flaws live in PHP's engine — the code that runs before your website's own code ever starts. That is why they are so dangerous: a login page, two-factor authentication or a fully updated WordPress install cannot block them, because the attack fires while PHP is still reading the request.

CVEWhat goes wrongFixed in
CVE-2026-109618Memory corruption: when PHP runs out of memory mid-request, request data can be left only partly set up, and cleanup then treats that invalid data as valid — opening the door to remote code execution.8.2.35, 8.3.36, 8.4.27, 8.5.12
CVE-2026-109619Stale internal request state: data from one request survives after its memory is freed, and a later request handled by the same worker can reuse it — again ending in remote code execution.8.2.35, 8.3.36, 8.4.27, 8.5.12

The timeline shows why the KEV listing landed when it did. Amazon's threat researchers spotted a first exploitation attempt on 17 October — four days before the fixes shipped. Public exploit code circulated from 21 October. Security researchers at Palo Alto Networks and Trail of Bits reported confirmed compromises and follow-up attacker activity on 24 October. Cloudflare has reported attack volume rising from thousands to millions of attempts since disclosure. One reported thread worth treating carefully: security firm CYFIRMA has tied low-volume scanning to a suspected North Korea-linked operator — that attribution is a single firm's report, not a CISA finding, and this post does not present it as confirmed.

Do not confuse PHP2Shell with its neighbours. CVE-2026-115560, a separate PHP session-upload-progress flaw disclosed two days later, is a different bug (we covered it separately). CVE-2026-111497, a Brotli decoder flaw affecting Palo Alto's PAN-OS, is also separate — it is not in the KEV catalog and Palo Alto reports no exploitation in the wild. This post is only about the two KEV-listed PHP flaws.

What to do right now

If you run any website on PHP — your own server, a VPS, shared hosting or a client's site — work through this list before 29 October:

  1. Find every PHP installation. Include the forgotten ones: old microsites, staging servers, Docker images, hosting-panel PHP and vendor appliances. CISA and national cyber centres both stress that hidden PHP is the usual miss.
  2. Check the version the web server actually serves, not the command line. A server can report a patched CLI version while old workers still run the vulnerable build in memory. Restart or replace every PHP worker after updating, then re-check.
  3. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 — or your provider's backported fix. Linux distributions and hosts such as cPanel and CloudLinux backport fixes into older version numbers, so a lower number is not automatically unpatched — ask the host to confirm the CVE IDs are covered.
  4. PHP 8.1 and older: there is no official release. The PHP project published bare source patches for self-builders, but ordinary hosting will not receive an update. Get a backport, or move to a supported branch — and if you cannot patch, CISA's advice is explicit: take the PHP system offline until you can.
  5. Treat a firewall or WAF rule as a stopgap, not a fix. Managed rules from vendors such as Cloudflare and Imunify360 block known exploit requests, but they do not fix the underlying flaw. One more caution from researchers at Datadog: turning off session.upload_progress.enabled does not fully protect against these two flaws.
  6. Check whether the server was touched before you patched. Look for POST requests containing PHP_SESSION_UPLOAD_PROGRESS with large multipart bodies, "allowed memory size exhausted" errors during request startup, and PHP workers spawning shells or downloading tools. Patching a compromised server leaves the attacker inside — if you find signs, isolate the box, preserve logs and get specialist help before rebuilding.

PHP2Shell CISA KEV exploited explained — data center servers running PHP websites

Illustrative image: a data center (Wikimedia Commons / Fleshas, CC BY-SA 3.0). The flaws affect any server running PHP for web requests — shared hosting, VPS and enterprise servers alike.

Why it matters for India readers

India's exposure to PHP2Shell is not theoretical. Our 25 October post reported 303 government websites vulnerable to PHP2Shell in India, found in a CERT-In-linked scan of 60,000 sites — a reminder that Indian public-sector and small-business sites run heavily on PHP and WordPress, often on shared hosting where the PHP version is the host's decision, not the site owner's.

For Indian site owners, the practical chain is short: ask your hosting provider, in writing, whether CVE-2026-109618 and CVE-2026-109619 are patched on your server, and which exact build covers them. If the host cannot confirm, or your site still runs PHP 8.1 or older, that is the moment to move hosts or upgrade — before 29 October, not after an incident. CERT-In has not issued a fresh advisory specifically on this KEV listing as of this post's writing; this post does not claim otherwise.

There is also a developer lesson here for India's large WordPress and Laravel community: updating WordPress, themes or plugins does not fix PHP2Shell. The flaw is in the language runtime underneath the application. Until the server's PHP itself is patched, the site stays exposed no matter how current the application is.

Should you care? ✅ Yes — patch before 29 October

Verdict: If you run or manage any PHP website, this is a patch-now week, not a patch-someday month. The flaws are confirmed exploited, the fix has existed since 21 October, and the cost of patching is one maintenance window. The cost of waiting is a server takeover by an attacker who needs no password — and a compromise that patching alone will not undo. If you only browse the web and run no server, there is nothing for you to do; this warning is for the people who keep the sites you visit running.

FAQs

What is PHP2Shell? PHP2Shell is the nickname researchers gave to two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. They let an unauthenticated attacker run code on a web server through crafted HTTP requests that abuse how PHP handles memory after out-of-memory or fatal errors.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619? The fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, shipped on 21 October 2026. PHP 8.1 and older receive no official release, so use your host's backported package or move to a supported branch. After updating, restart every PHP worker and confirm the served version.

Does updating WordPress fix PHP2Shell? No. The flaws are in PHP itself, not in WordPress, a theme or a plugin. WordPress has said no WordPress core update is required for these flaws. Only updating the PHP version on the server protects the site.

How do I check if my server is affected? Check the PHP version your web server actually serves — for WordPress, Tools → Site Health → Info → Server shows it — and confirm the CVE IDs are covered, either by version number or by your host's backport confirmation. Assume the site is affected until that check comes back clean, and look in logs for suspicious upload-progress requests and memory-exhaustion errors.

What if I cannot patch by 29 October? CISA's updated alert is direct: organisations that cannot update immediately, or that still run unsupported versions, should take PHP-based systems offline until they can be patched or updated. A WAF rule can reduce exposure in the meantime, but it is not a substitute for the patch.

What does a CISA KEV listing actually mean? It means CISA has independently confirmed the vulnerability is being exploited in the wild. It does not mean every unpatched server is already compromised, and it does not by itself prove how widespread the exploitation is — but it moves the flaw from "could be attacked" to "is being attacked," which is why federal agencies get a hard deadline.

Takeaway: CISA's 26 October KEV listing turned PHP2Shell from a serious patch into a confirmed, actively exploited threat with a 29 October deadline. Patch PHP, restart the workers, and check for earlier compromise — in that order.

Follow World Tech on TechByCountry for tomorrow's update.

📸 Get tech in the last 24 hours on Instagram — follow @_techinlast24hrs for daily posts (9 AM–9 PM) and reels at 12:30 PM & 8:30 PM.

Sources

Related on TechByCountry: PHP2Shell Vulnerability Patch Guide for WordPress Website Owners · 303 Government Websites Vulnerable to PHP2Shell in India Explained · CISA KEV Collabora Arista Vulnerabilities Explained

Comments

Post a Comment