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.

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