PHP2Shell: CVE-2026-109618 and CVE-2026-109619 exploited four days before PHP's fix, Amazon says

Attackers were probing the PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619, four days before PHP published its fixes, Amazon Threat Intelligence reported on 22 October 2026. Both bugs are in the PHP runtime itself, both carry a CVSS v4.0 score of 9.2, and both can allow unauthenticated remote code execution. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you run PHP, patch now, and look through logs back to 17 October rather than only from the disclosure date.

Key points

• CVE-2026-109618 and CVE-2026-109619 ("PHP2Shell") are critical PHP runtime flaws, both rated CVSS v4.0 9.2 by the PHP security team; they can allow unauthenticated remote code execution (php.net advisory).
• Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026, a day earlier than planned after the CVE numbers began circulating.
• Amazon's MadPot honeypots recorded an exploitation attempt on 17 October, four days before the fix, from an anonymised IP address; Amazon says it is unclear how the actor learned of the bug.
• Amazon saw the earliest proof-of-concept exploits around 02:00 UTC on 21 October, about 12 hours before the 14:00 UTC release, and says the flaws are now being exploited broadly.
• Updating is the only complete fix; the PHP project's configuration measures reduce exposure but do not make a server safe.

What to do

Who is affected: all PHP installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project considers mod_php the highest risk, with a demonstrated exploit where an unauthenticated request triggers the attack before any application code runs. Because the flaw is in the runtime, updating a CMS or plugin does not fix it. Cloudflare says all web servers running PHP 5.4 or later are affected.

Fix: upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distributions and LTS vendors received the patches in advance, so check your vendor's packages. PHP 8.1 and older no longer get project updates, though the security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source. If you rely on the volunteer-run rpms.remirepo.net repository, PHP says it will have no updates on the day and recommends distribution packages or building from source. On managed hosting, ask your provider to apply the update.

If you cannot patch immediately (reduces exposure only):

• For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override (for example php_admin_value in the FPM pool), and set a low post_max_size (8M without uploads, 32M with them), keeping upload_max_filesize below it. Do not use RLIMIT_AS or RLIMIT_DATA, which can themselves cause the vulnerable allocation failure.
• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, an FPM pool or server configuration (not ini_set() or .user.ini) and restart every worker. On PHP 8.5 also set fatal_error_backtraces=0.
• Amazon suggests blocking multi-part file uploads where you cannot patch, after checking the effect on your application, and looking for POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS.

Check whether you were hit: review web-server logs, look for unexpected process execution or file changes on web servers, and start from at least 17 October. Amazon lists six IP addresses seen in its telemetry but warns they are shared anonymisation infrastructure, so investigate matches rather than simply blocking.

What happened

The PHP security team gave advance notice of a release at 14:00 UTC on Wednesday 21 October. According to the PHP Foundation's account as reported by The Register, around 15:00 UTC on 20 October two CVE IDs began circulating on forums and social media with wrong details about timing and severity. The maintainers moved the release forward a day, from Thursday to Wednesday, saying distributors were still packaging the fix. Later that evening, security firm Calif mistakenly published a video of a proof-of-concept, with limited extra information, the foundation said. On 21 October at 07:41 UTC, the foundation says, Chainguard published container images containing the fix more than six hours before the release.

Chainguard's CEO Dan Lorenc told The Register the company "didn't leak"; he does not dispute the timeline and says Chainguard independently found the same bugs with an AI model after a researcher said something was coming. The two accounts differ on whether publishing was a breach of the embargo, and we cannot settle that here.

Amazon's disclosure adds a timeline the vendors did not have. MadPot recorded an exploit attempt on 17 October from an anonymised IP, four days before disclosure. Early on 21 October, from about 02:00 to 08:00 UTC, further attempts arrived from other anonymised infrastructure with varied payloads, which Amazon takes to mean multiple actors. After the 14:00 release, further proofs of concept appeared within hours and were used against its sensors almost immediately. Amazon says it is not clear whether any of these attempts would have succeeded against real systems.

Cloudflare says its protections were in place from 03:02 UTC on 21 October, about nine hours ahead of disclosure, and that it saw attack traffic during the leak and attackers mutating payloads to evade its rules. The Register reports, citing Cloudflare CEO Matthew Prince, thousands of attempts in the 10 hours before disclosure, tens of thousands within 45 minutes of it, and millions since. Security firm Hadrian told The Register that most attacks it saw abuse PHP's session upload-progress path.

Background

The PHP project's advance notice, published before the release, described two critical flaws, both rated CVSS v4.0 9.2, reserving the right to release early if details became public or exploitation appeared. Our earlier piece covered that warning: PHP to patch two critical remote code execution flaws. The Register reports that Calif, OpenAI and Wiz found the bugs between August and September and all three say they used AI models. Cloudflare lists Calif.io, Wiz, OpenAI and Quarkslab as the disclosing parties.

How it works

Both bugs are memory-safety problems on error paths. According to the PHP advisory, CVE-2026-109618 occurs when out-of-memory handling interrupts PHP while internal request data is only partly initialised; cleanup then treats the invalid data as valid. CVE-2026-109619 occurs when request-owned internal state survives after its memory is freed, and a later request handled by the same worker uses that stale state before normal initialisation resets it. Cloudflare describes the second case as a fatal error leaving dangling references that a later request on the same process may follow, exposing data.

That explains the workarounds: they close particular ways of triggering the failure (huge request bodies, the session upload-progress feature, fatal-error backtraces) without removing the underlying defect, which is why the PHP project says only an update is complete.

What it means

For site owners, especially those on shared or older stacks, the practical lesson is that "disclosure day" is not the start of the risk. Amazon's advice: for critical flaws in internet-facing systems, measure patch timelines in hours, begin investigations from the earliest known exploitation, and invest in detections that do not depend on a CVE-specific signature. It argues that AI-assisted analysis makes it cheaper to turn a patch or advisory into a working exploit, so more actors can move within hours. That is Amazon's view, not a measured industry statistic.

For the open-source disclosure process, the episode renews the argument over embargoes. Distributors need advance patches so users can update immediately, but each extra party that holds a fix or a built image increases leak risk.

Hosting providers and WAF vendors are the quickest defence for many sites, but Cloudflare itself says WAF rules are defence in depth and customers should patch.

What we don't know yet

• How the 17 October actor learned of the flaws; Amazon says this is unclear.
• Whether any of the observed attempts compromised real servers.
• Whether other exploit paths beyond session upload-progress and fatal-error backtraces will appear; Hadrian expects more.
• Who leaked the CVE numbers on 20 October.

What to watch next

Distribution and hosting-provider updates for older PHP lines; new exploit variants and any added WAF rules (Cloudflare tracks these in its changelog); and any CISA or vendor reporting of confirmed compromises.

Update, 24 October 2026

The PHP Foundation said on Friday 23 October that it has reserved a third identifier, CVE-2026-115560, for a further remote code execution flaw related to PHP2Shell, according to The Register. Unlike the first two, it will not get an emergency release: the Foundation says it needs "a very unlikely combination of configuration and specific PHP application code" and will be fixed in the next regular PHP release. For now the PHP Security Team has published only an informational advisory.

Mitigation: set session.upload_progress.enabled=0 until that release. The attack path needs an application that sets session.serialize_handler to php_binary or php_serialize and then switches it to php at runtime with ini_set() before calling session_start(), with the upload progress feature enabled.

On exploitation, PHP Foundation executive director Elizabeth Barron said the Foundation has no evidence of successful exploitation of the two earlier flaws before disclosure, nor of any exploitation on patched versions. The Register reports that researchers it contacted have seen attempts but no confirmed successful attacks; Mandiant's CTO Charles Carmakal said on LinkedIn that some circulating proof-of-concept exploits are broken, while others can achieve code execution against default mod_php deployments but not PHP-FPM.

Source: The Register

Update, 27 October 2026

CISA added both PHP2Shell flaws to its Known Exploited Vulnerabilities (KEV) catalogue on 26 October 2026: CVE-2026-109618 ("PHP Memory Corruption Vulnerability") and CVE-2026-109619 ("PHP Stale Internal Request-State Vulnerability"). The catalogue entries describe both as allowing unauthenticated remote code execution, give a due date of 29 October 2026 for federal agencies to apply mitigations in line with CISA's BOD 26-04, and mark both as requiring forensic triage. CISA lists known ransomware campaign use as "Unknown" for both.

A KEV listing means CISA considers the bugs exploited in attacks. It does not tell us how many systems were compromised; the PHP Foundation had said on 23 October that it had no evidence of successful exploitation before disclosure or against patched versions. The fix is unchanged: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. We read the entries in CISA's KEV data feed; CISA's own alert page did not open for us, and BleepingComputer's report of the listing was also blocked, so we have not checked its wording.

Source: CISA Known Exploited Vulnerabilities catalogue

Update, 27 October 2026

CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on Monday 26 October 2026, with a deadline of 29 October for US federal civilian agencies. The deadline does not bind other organisations, though CISA urges them to prioritise the fixes. According to The Register, both flaws are rated CVSS 9.2 and can run code without authentication. It reports that AWS saw exploit attempts as early as 17 October, four days before public disclosure; that Perplexity researcher Adel Karimi recorded 35 successful shell executions on 24 October across three honeypots running PHP 8.4.26 under Apache mod_php, matching CVE-2026-109618 only and using a favourable single-worker setup; and that Delft University's Threat Intelligence Lab tracked more than 50,000 exploitation requests from over 600 IP addresses in 70 countries. CISA has not said which organisations were compromised. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Source: The Register

Update, 27 October 2026

CISA added both PHP2Shell flaws, CVE-2026-109618 (PHP memory corruption) and CVE-2026-109619 (PHP stale internal request-state), to its Known Exploited Vulnerabilities catalog on 26 October 2026, and said it had updated its PHP alert, "Critical Vulnerabilities in PHP Require Immediate Patching". The agency encourages all organisations, not only federal agencies, to prioritise KEV fixes. The Register reports that federal civilian agencies have until 29 October to act (the CISA alert page we read does not state a deadline) and that both bugs are rated 9.2 on CVSS.

The Register also reports that Perplexity researcher Adel Karimi recorded 35 successful shell executions across three honeypots running PHP 8.4.26 under Apache mod_php on 24 October, consistent with CVE-2026-109618 but with no evidence involving the second bug, on a favourable single-worker configuration that may not reflect production servers. It cites Delft University's Threat Intelligence Lab as tracking more than 50,000 exploitation requests from over 600 IP addresses in 70 countries. Per The Register, some earlier reports were walked back: Sophos revised its assessment to scanning and failed attempts, and Palo Alto Networks withdrew a claimed link to a European government intrusion.

The Register lists the fixed versions as PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA has not said which organisations were compromised.

Source: CISA: Known Exploited Vulnerabilities additions, 26 October 2026

Sources

• PHP.net security advisory and release announcements, 21 October 2026
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure in MadPot (AWS Security Blog)
• Cloudflare: protections against php2shell
• The Register: Hackers pile on PHP2Shell as AWS reveals attacks began before disclosure
• The Register: PHP blames Chainguard for putting huge chunks of the web at risk