PHP2Shell Was Exploited Before the Fix Shipped. How Long Would Yours Take?
Shane Warden
October 23, 2026
Share post:
Every open source component you run has a wait built into it: the time between a fix shipping upstream and that fix running in your environment. PHP2Shell shows what it costs.
Key takeaway: A fixed release only protects an environment once it is deployed and confirmed running. Agree on the approved source and owners before an urgent update arrives.
Amazon Threat Intelligence caught someone trying the PHP2Shell exploit on October 17, 2026. The PHP project shipped fixed releases on October 21 at 14:00 UTC.[2] By release day, working exploits were already circulating, and AWS saw new ones hit its sensors within hours of the release.
These bugs were specific to PHP, but the lesson applies to every language and package in your stack. I’d start with one measurement: how long it takes your team to get a critical fixed release from its approved source into production, with a named owner at each handoff.
What happened with PHP2Shell
PHP2Shell is the nickname for two critical remote code execution vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619. The PHP Foundation disclosed both on October 21, 2026, and rates them CVSS 9.2.[1]
Both bugs sit in memory management and error handling, which are critical paths for PHP requests. On Apache with mod_php, CVE-2026-109618 can be triggered by an unauthenticated request before any application code runs. The Foundation also confirmed remote code execution on PHP-FPM through application code paths.
Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
If you run PHP, do this now
Upgrade. AWS says no configuration change fully covers both CVEs.[2] While you schedule the upgrade:
Consider blocking multipart file uploads as a stopgap, after testing what it breaks.
Search your logs back to October 17, the first known attempt. Starting from the disclosure date misses 4 days.
Look for POST requests in form uploads that contain PHP_SESSION_UPLOAD_PROGRESS.
Check web servers for unexpected processes or file changes.
Follow the PHP project’s and your distributor’s guidance for your specific setup.
How the disclosure came apart
The PHP Foundation published a candid account of what went wrong.[1] A core developer first spotted signs of the bug in 2024, while working through findings from an external audit. The security team couldn’t agree on a fix, and the process stalled for months. The Foundation calls that “a structural failure.”
Reports from Calif, OpenAI, and Wiz made the impact of the same root cause clear in 2026. On October 20, the CVE IDs leaked with the wrong score and release time, and a researcher accidentally posted a video of the exploit working. The Foundation moved the release up a day.
On the morning of October 21, a vendor that had the fix early shipped fixed images more than 6 hours before the coordinated release. Those images put the fix in public before the coordinated release. Anyone holding the old and new builds could compare them and work backward to the bug, so the public analysis window opened before the coordinated release. That is an inference about the exposure created by the early images; it does not explain how the October 17 actor obtained exploit information.
The maintainers found the bug, fixed it under pressure, and then explained exactly what went wrong in public. Every team that runs open source can learn from that account.
PHP2Shell disclosure timeline
October 17, 2026: AWS observes an exploit attempt. Investigation must include activity before disclosure. [2]
October 20, 2026: CVE details leak and a video is posted by mistake. PHP advances the coordinated release. [1]
October 21, 07:41 UTC: A vendor publishes fixed images early, making the fix available for binary analysis. [1]
October 21, 14:00 UTC: PHP publishes fixed releases. [2]
AI shrank the gap between fix and exploit
A fixed build tells attackers where to look. Reverse engineering one of these releases used to take skilled people real time. AWS puts the change plainly: “AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit.”[2] Its threat intelligence team expects more attackers to move within hours or minutes of disclosure. With PHP2Shell, attackers outran disclosure: AWS still doesn’t know how the October 17 attacker got early access.
Defenders use the same tools. The PHP security team uses AI to validate reports and group duplicates, and says a person makes every call and works on every fix.[1] The difference is the amount of work on each side. An attacker needs one working exploit. A defender has to get the fix into every environment that runs the code.
The clock started before the fix did
AWS advises starting any PHP2Shell investigation on October 17, the first known exploit attempt.[2] A change process that starts its clock at disclosure misses activity that came earlier. For PHP2Shell, AWS observed an attempt at least 4 days before the coordinated release. Every day the fixed release then waits to reach production adds to that head start, and the handoffs inside your organization are something you can measure.
Five handoffs between an upstream fix and production
None of this is specific to PHP. The same handoffs apply to a Python library, a Java framework, or a container base image. An upstream fixed release makes protection possible. Before it protects anything, someone in your organization has to:
Pick the fixed build and confirm where it came from.
Verify it with provenance, an SBOM, and build records.
Test it against your applications.
Deploy it to every environment that runs the component.
Confirm it’s running, and investigate what happened before it was.
Each step usually belongs to a different team. The steps without a named owner are where the days go. Time each handoff once, and you’ll know how long a fix actually takes to reach your production environment.
Where your open source comes from
Developers are building and shipping software faster. The open source components they use need to come from a governed source that keeps pace with that work. Make the approved source the default in the tools developers already use, so governance is part of the workflow.
Ask these questions about the source your teams use:
What controls determine which components and versions are available before developers or AI coding assistants pull them into a build?
What evidence connects each artifact to its source, including provenance, build records, and a software bill of materials?
How are security fixes validated and coordinated with maintainers, including during an embargo?
Once a fix is available upstream, what contractual remediation commitment applies, and how does the fixed release reach developers through their existing tools?
How ActiveState delivers open source software
For the open source ecosystems in our Curated Catalog, ActiveState takes the first two handoffs, picking and verifying the fixed build, off your team’s plate and keeps them there. We build components from source in SLSA Level 3 infrastructure, scan every one for vulnerabilities and malware, and deliver them through a private Curated Catalog that plugs into the package managers and pipelines your teams already use. Each component arrives with provenance and an automatic SBOM.
When a community fix is released for a component you consume from us, we build the fixed release from source and deliver it under contractual remediation SLAs, measured in business days, that start when a fix is available upstream. Your engineers pick the fixed build from a source that’s already approved, with the evidence to verify it attached. Testing, deployment, and confirmation stay with your teams, alongside scanning and incident response.
Look at your last critical update
I’d ask the engineers who shipped your last critical update what happened between getting the fixed build and putting it into production. Review where it came from, the checks it went through, and any time it spent waiting for a test environment or approval.
Use that review to agree on the governed source your teams will use and the route for urgent updates. Developers should be able to get a verified build through their usual tools, with testing and release decisions agreed in advance.
PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, two critical remote code execution vulnerabilities in PHP’s memory management and error handling. The PHP Foundation disclosed them on October 21, 2026.
Was PHP2Shell exploited before the fix was released?
Yes. AWS recorded an exploit attempt on October 17, 2026, 4 days before public disclosure. It reports broad exploitation attempts since the fixed releases shipped.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, released October 21, 2026.
Is there a workaround for PHP2Shell?
No configuration change fully covers both CVEs. Upgrading is the complete fix. Blocking multipart file uploads can reduce exposure for a short time, after testing.
Does this apply beyond PHP?
Yes. The five handoffs between an upstream fix and production apply to any open source component, in any language. PHP2Shell is a recent, well-documented example of what happens when attackers move before that work is done.
Does an upstream fix mean my organization is protected?
An upstream fix can be a source code change that still needs building or a fixed release you can install. Remediation requires verifying the build, deploying it to affected environments, confirming it is running, and investigating earlier activity.
When does the clock start on a critical vulnerability?
At the earliest known exploitation, which can come before disclosure. For PHP2Shell, AWS recorded an exploit attempt on October 17, 2026, 4 days before the fix was public, and recommends starting investigations from that date.
How is AI changing time to exploit?
AWS reports that AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit, so attackers can move within hours or minutes of disclosure.
What should I ask about the source of our open source software?
Ask what governs which components and versions are available, what evidence connects each artifact to its source, how security fixes are coordinated, and what remediation commitment applies once a fix is available upstream. The approved source should work through the tools developers already use.
