CISA lists PHP2Shell as exploited and gives agencies until 29 October

• Affected: PHP 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36, 8.2 before 8.2.35, and every end-of-life branch. Apache mod_php carries the highest risk.
• Fixed in: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October 2026, or your vendor's backported package.
• Exploited? Yes. In CISA KEV since 26 October 2026 (checked 27 October 2026). Public proof of code execution so far comes from honeypots and a challenge server.
• Do this now: patch and restart every PHP worker. Then search your error logs for memory errors "in Unknown on line 0" and look for shells started by web workers.

What happened

CISA now says attackers are exploiting PHP2Shell, the pair of PHP flaws that allow unauthenticated remote code execution. Federal civilian agencies have until 29 October 2026 to fix them.

CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog on 26 October 2026. The entries appeared in catalog version 2026.10.26, released at 22:24 UTC.

CISA names them "PHP Memory Corruption Vulnerability" and "PHP Stale Internal Request-State Vulnerability". Both entries mark ransomware use as unknown. Both are flagged for forensic triage.

CISA also revised its 21 October PHP alert the same day. The revision only notes the KEV addition. CISA does not say who is exploiting the flaws, which systems were hit, or how it learned of the activity.

The listing came five days after the fix:

• 17 October: Amazon's MadPot honeypots log a first exploit attempt (our report).
• 21 October: PHP ships the fixed releases (our explainer).
• 24 October: a public honeypot report documents the first validated shells.
• 25 October: Unit 42 retracts its link between PHP2Shell and a government intrusion (our correction).
• 26 October: CISA adds both CVEs to KEV.

Who is affected

Any server that runs an unpatched PHP build and accepts web requests is in scope. The bugs sit in PHP's own request parsing, so the application on top does not matter.

How PHP runs changes the risk. PHP says Apache mod_php is the most exposed setup, where a working exploit fires before any application code runs.

For CVE-2026-109618, PHP says PHP-FPM is susceptible from source analysis, without a complete exploit shown. For CVE-2026-109619, PHP validated the session upload progress path on mod_php and FPM. The FPM case needs a suitable application operation.

Products that bundle PHP need their own fixes. NVD lists Siemens RUGGEDCOM APE1808 under CVE-2026-109618. Windows users should also take PHP's 26 October rebuilds for a separate Brotli flaw (our story).

The 29 October deadline binds only US federal civilian agencies under BOD 26-04. Three days leaves little room. Everyone else should read the listing as a priority signal.

What is confirmed

CISA's listing. Both CVEs are in KEV, added 26 October, due 29 October. KEV means CISA holds evidence of exploitation in the wild. CISA has published no detail about that evidence.

Shells on honeypots. On 24 October, the independent phpot honeypot project published packet and process evidence of 35 shells. Apache workers started them on three disposable honeypots between 15:35 and 18:57 UTC.

Those honeypots ran PHP 8.4.26 under single-worker Apache mod_php with a 128 MiB memory limit. The author chose a setup that favors attackers. The traffic came from two addresses on hosting networks.

The chain had four stages: memory pressure, a memory leak through an oversized session cookie, more pressure, then execution. The leaked cookie reached about 800 KiB. The report says the chain closely matches a public exploit family.

A won challenge. A public "Steal My Bitcoin" challenge was solved on 25 October at 15:47 UTC, after 19.28 hours. The organizer confirms the win on the challenge site and on Hacker News.

The organizer says server logs show the first and only successful run of the challenge's flag program. The winner's write-up describes an out-of-memory and session upload progress chain against PHP 8.4.26.

That target was not a typical production stack. It ran PHP's built-in development server with four workers behind nginx, on Alpine Linux. It was also deliberately left unpatched.

Mass attempts. The Delft Threat Intelligence Lab counted 65,638 exploitation requests from 635 addresses in 72 countries by 27 October, 08:24 UTC. Of those addresses, 171 sent code or a downloader.

The busiest hour so far was 14:00 UTC on 26 October, with 8,179 requests. Two of the samples Delft analyzed are Mirai-family DDoS bots. CERT-FR said on 26 October it sees attempts aimed at specific PHP deployments.

Scores. PHP rates both flaws 9.2 under CVSS 4.0. NVD scores CVE-2026-109618 at 9.8 and CVE-2026-109619 at 8.1 under CVSS 3.1.

What is not confirmed

No primary source has publicly confirmed a compromised production server as of 27 October, 08:30 UTC. Unit 42 withdrew the only named case on 25 October. CISA does not say whether its own evidence involves production systems.

The public evidence does not cleanly separate the two CVEs. The honeypot and challenge chains mix out-of-memory pressure with session upload progress. CISA listed both and did not say which one was used.

Private exploits are claims, not evidence of attacks. Trail of Bits CEO Dan Guido said on 24 October that his firm's private exploit works on stock production settings, with several workers, on mod_php and PHP-FPM. It is unpublished and unverified.

CrowdStrike says it reproduced code execution on Apache mod_php in its own lab. That shows what is possible. It is not a report of victims.

Public exploit code remains tied to specific builds. Memory offsets are calibrated for one distribution build and fail on others. ThreatWire has not run any exploit and does not link one here.

Ransomware use is unknown, per CISA. Nobody has publicly attributed the attempts to a named group.

What to do

1. Patch. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's fixed package. PHP says this is the only complete fix.
2. Restart and verify. Restart every Apache, PHP-FPM and CGI worker, and rebuild container images. Check the running version inside each pool, not just the installed package.
3. Agencies: triage first, fast. CISA's forensic triage steps ask for volatile evidence before patching, within 2 to 24 hours of listing. A worker restart wipes memory, so capture quickly, then patch.
4. If you cannot patch today, set session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0. Keep post_max_size low, cap request size at the proxy, then restart workers. A WAF helps only as a bridge.
5. Search your logs for these signs:
   • PHP errors "Allowed memory size … exhausted … in Unknown on line 0", which means no script was running yet.
   • Multipart POSTs, often chunked, with hundreds of parts, deeply nested field names or a PHP_SESSION_UPLOAD_PROGRESS field.
   • PHPSESSID cookies in responses far longer than the usual 32 or so characters.
   • Worker segmentation faults and unexplained restarts.
   • sh, wget, curl or the PHP CLI started by Apache, php-fpm or php-cgi processes.
6. If you find a hit, isolate the server and keep the logs. Check web roots, temp directories, session files and cron jobs. Rotate secrets the server could read, because the flaws can leak memory.
7. Check appliances that embed PHP, and follow each vendor's advisory.

The session upload progress setting also blocks CVE-2026-115560, which the 21 October releases do not fix.

Our take

KEV changes the paperwork more than the risk. The risk was plain on 21 October, when PHP shipped fixes and attackers were already probing.

The listing still matters. It gives agencies a hard date and asks every defender a sharper question: were we hit between 17 October and the day we patched?

The public successes so far came from targets built to be easy: a single-worker mod_php honeypot and a deliberately unpatched challenge server. Busy production servers with many workers are harder for public tools. Capable private exploits reportedly handle them.

So treat any server left unpatched since 21 October as possibly compromised until your logs say otherwise. PHP's exposure also runs through the libraries it bundles, as the separate Brotli2Shell flaw showed.

Updates

• 27 October 2026, 08:50 UTC: first published, with KEV data checked on 27 October.