PHP2Shell, Explained for Threat Intelligence Teams

The first PHP2Shell exploitation attempt hit an Amazon honeypot on 17 October 2026. The public learned the CVE numbers on 20 October, and the patch shipped on 21 October. Someone was throwing an exploit at the internet four days before the people who were supposed to defend against it knew it existed.

That gap is the real story for threat intelligence teams. Most coverage of PHP2Shell answers "which version do I install?" This article answers the questions a CTI analyst gets asked the morning after: when did exploitation actually start, how much of our estate is exposed, which of the hundreds of GitHub exploits are real, who is likely to use this, and what do we tell leadership. Everything below is current as of 22 October 2026, and some of it will move fast.

What PHP2Shell Is

PHP2Shell is the name for two critical memory-safety vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, that can let an unauthenticated attacker execute code on a web server running PHP, or read memory from the PHP worker process. The PHP security team rates both 9.2 under CVSS v4.0. Because the bugs live in the interpreter rather than in any application, a site can be exposed even if its own code is flawless; Wiz Research says even a simple "Hello World" page on an affected version can be attacked.

PHP2Shell at a glance, as of 22 October 2026:

• CVEs: CVE-2026-109618 (OOM corruption) and CVE-2026-109619 (stale global state), both CVSS v4.0 9.2.
• Affected: every PHP branch from 5.4 onward, on any web-serving setup. Apache mod_php is rated highest risk.
• Fixed in: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. Source-only backports for 7.4, 8.0, 8.1. No fix for 5.4 to 7.3.
• Exploitation: attempts observed from 17 October (before disclosure); broad attempt activity post-patch. Confirmed victim compromise unestablished in public reporting. Not in CISA KEV as of CISA's 21 October alert.
• Discovered by: Wiz, Calif and OpenAI, with frontier AI models used in the research.

The two flaws, in plain terms, per the PHP Foundation's release post and the CERT-EU advisory 2026-018:

• CVE-2026-109618 (OOM corruption). When a request hits PHP's memory limit at the wrong moment, PHP can abort while internal request data is only partly initialized, and cleanup then treats that data as valid. On Apache with mod_php, an unauthenticated request can trigger this before any application code runs.
• CVE-2026-109619 (stale global state). A fatal error can leave internal state pointing at memory that belonged to a previous request. A later request served by the same worker can then use that freed memory. PHP lists memory disclosure as a confirmed impact.

Wiz Research says every PHP release back to 5.4 is affected by at least one of the issues. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed are all in scope, with mod_php rated the highest-risk setup. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; the PHP security team published source-only backports for 7.4, 8.0 and 8.1, and nothing at all for 5.4 through 7.3.

One honest caveat for your assessment. A 9.2 describes impact if exploited, not a guarantee of one-shot code execution everywhere. Reliable RCE is configuration-dependent: PHP demonstrated it against mod_php with default settings, while the PHP-FPM paths are narrower, and watchTowr noted that much of the early public exploit code simply crashes the target instead of executing code. "Affected" and "reliably exploitable in your specific deployment" are not the same column, and your report should keep them apart.

If you need the broader framing for why a vulnerability story belongs on a CTI desk at all, start with our complete guide to cyber threat intelligence. The short version: patching is the vulnerability management team's job. Knowing when, how and by whom it will be exploited is ours.

The PHP2Shell Timeline Is the Intelligence

Before you write a single assessment, build the timeline. Every judgment that follows (hunt windows, confidence levels, whether "no exploitation observed" means anything) depends on it. Here is what the primary sources say, in UTC.

Figure 1: The same timeline as a sequence. The red marker at the top is the first observed exploit attempt, four days before anyone outside the embargo had a CVE to track. The red line is the patch and public disclosure; almost everything that mattered happened above it. Diagram: CTI Academy, from PHP Foundation, Amazon and Cloudflare reporting.

Three entries in that table should change how you work.

17 October. The Amazon Threat Intelligence report describes an attempt from a commercial anonymization network against its MadPot sensors while the bugs were still under embargo. Amazon says it is unclear how the actor got the exploit information. That is an intelligence gap, and you should write it down as one rather than paper over it.

07:41 on 21 October. The PHP Foundation says Chainguard "unilaterally broke the embargo" more than six hours before the coordinated release by publishing built images containing the fix. Once a fix exists in binary form, anyone can diff it, and patch diffing is a known exploit-development shortcut. Do not overstate the link: scanning was already climbing from the 20 October leak and the circulating PoC video, so the early binary was one more avenue, not the sole cause. But it is a clean example of how a single early release erodes an embargo for everyone.

The leaked score. The CVE IDs circulated with a CVSS of 10.0 and a wrong release time. The 10.0 figure spread fast and PHP never issued it; the real score is 9.2. If your first flash report said 10.0, issue a correction. Small factual errors in a fast-moving event are how a CTI team loses credibility it needs for the next one.

Exploitation Started Before Disclosure: Move Your Hunt Window

The single most useful line in all the PHP2Shell reporting comes from Amazon: start investigations from the earliest known exploitation, not from the disclosure date, which for PHP2Shell means at least 17 October.

Most incident response playbooks key the lookback window to the advisory date. That habit made sense when exploitation reliably trailed public proof-of-concept code. It does not hold here, and Amazon is blunt about why: "An embargo protects defenders only until someone else finds the same bug."

Figure 2: Amazon's own words. An exploit attempt reached its honeypot network on 17 October, while the flaw was under embargo, from an anonymization network. This is the single line that should reset your hunt window. Source: AWS Security Blog, Amazon Threat Intelligence.

What does this mean in practice? If your web, WAF or EDR logs only go back seven days and you start the hunt on 22 October, you are already at the edge of the window. Pull and preserve logs for internet-facing PHP hosts now, before rotation eats the evidence.

The reporting on volume tells you how fast the window filled up. Cloudflare's CEO, quoted by SecurityWeek, said the network saw thousands of attempts in the ten hours before the announcement, tens of thousands in the 45 minutes after it, hundreds of thousands within two hours, and millions by the following morning. That is a mass-scanning curve, and mass scanning means you do not need to be an interesting target to be hit.

Now the caveat a good analyst always attaches. Attempts are not compromises. watchTowr's head of threat intelligence described the early exploits being "sprayed indiscriminately" as code that either does not work, tests for timing differences, or crashes the target. CISA's alert said it had not observed exploitation as of publication, and Recorded Future's Insikt Group assessed that available reporting does not establish the extent of successful exploitation. Both statements can be true at the same time as Amazon's "broadly exploited in the wild." Report the difference between attempted, successful against a honeypot, and confirmed victim compromise explicitly. Your readers will collapse those three if you let them.

Exposure Intelligence: Why Every PHP2Shell Count Disagrees

Leadership will ask "how many servers are affected?" You will find at least six different answers, and they are each measuring a different thing.

• W3Techs puts PHP on 69.3% of websites whose server-side language is known. That is the "70% of the internet" headline, and it measures websites, not hosts.
• Censys saw about 2.58 million internet-facing PHP hosts on 21 October, around 1.58 million reporting a version, of which about 1.57 million were unpatched (via SecurityWeek). By 22 October it tracked nearly 3 million.
• VulnCheck counted more than 2.6 million internet-facing hosts running PHP, nearly all vulnerable.
• VirusTotal sees about 5.1 million IP addresses running PHP, but only 1.1 million disclose a version. Of those, about 758,000 run an end-of-life branch and about 272,000 a supported one.
• Modat reports 4,384,302 PHP services on 1,886,612 unique hosts, with about 79% of version-readable services on an unsupported branch (via Recorded Future).

The numbers scatter because they count different things (sites, IPs, hosts, services), with different scan coverage, on different hours of a fast-moving day. Give leadership the shape, not a fake-precise number: low single-digit millions of exposed hosts, with a large share on end-of-life PHP that gets no official binary release, only source backports for 7.4 to 8.1 and nothing below that.

Two details matter more than the totals.

First, version strings lie in both directions. In VirusTotal's dataset only about one in five PHP hosts disclosed a version in an HTTP header, so banner-based counts undercount. And Linux distributions received the fix in advance, so a distribution package can carry the patch under an old-looking version number; Debian's advice, relayed by The Hacker News, is to check the package changelog for the CVE IDs rather than trusting the version string. An external scanner that flags "PHP 8.2.20" may be wrong about your patched Debian box, and one that sees nothing may be missing an unpatched one.

Second, running the latest release was no protection. Recorded Future notes that VirusTotal counted about 85,000 IPs on the 24 September releases, the newest available before the fix. "We keep PHP current" is not a mitigating factor for this one.

This is where attack surface management and CTI meet. Your exposure picture has to cover forgotten subdomains, marketing microsites, acquired-company servers and the agency-hosted WordPress site nobody owns. The attacker's scanner will find those before your CMDB does.

The PoC Flood: Separating Signal From Noise

Within a day of disclosure, GitHub was full of "php2shell" repositories. AhnLab's ASEC team looked at the top 100 results: 99 related to these CVEs, nearly all created on 21 October. Of the 1,394 stars across them, 1,158 (83%) went to proof-of-concept repositories, while defensive tools got 148.

That ratio is a lesson in itself. Attention flows to offense. Your job is to flow it back to evidence.

Figure 3: Where the crowd looked. Offensive proof-of-concept repositories collected 83% of the stars across the top 100 "php2shell" projects, while PHP found no functional exploits among the post-leak PoCs it inspected. Loud does not mean working. Diagram: CTI Academy, from AhnLab ASEC and PHP Foundation data.

Here is what the evidence says about public PoCs:

• The PHP Foundation inspected PoCs that appeared after the leak and "did not identify any functional exploits at the time of release/public disclosure."
• Recorded Future examined two widely shared PoC scripts whose own author later invalidated the exploitation theory behind them.
• JFrog Security Research found fake PoCs on GitHub, including one hiding a Base64-encoded string that appears to decrypt and run a malware payload.
• AhnLab flagged that "mitigation" scripts asking for root privileges are themselves a possible attack path disguised as a security tool.

Fake exploits are a targeting technique, not just a nuisance. The people most likely to download and run a fresh PHP2Shell PoC are security researchers, red teamers and SOC analysts trying to validate exposure. That audience has been deliberately targeted before: in January 2021 Google's Threat Analysis Group exposed a North Korean government-backed campaign that used fake research personas and backdoored Visual Studio projects to compromise security researchers. Any high-profile CVE with a PoC rush is an ideal lure.

The practical rule for your team: nobody runs public PHP2Shell code on a corporate machine. If validation is needed, it happens in an isolated lab with no credentials on it, against a target you own, and only after someone reads the code. Better still, validate with vendor-maintained scanner checks and the official advisories.

When you grade these sources for a report, use your normal reliability scheme. A GitHub repo from a two-day-old account with 600 stars is an unreliable source with unconfirmed information, however loudly social media repeats it.

What the Underground Is Doing

The underground reaction to PHP2Shell is one of the stranger data points of the week. According to SOCRadar, underground forums including BreachForums and Dread took their own sites offline as a precaution, with a BreachForums Telegram message saying the forum would stay down until PHP was patched globally. Criminals run on PHP too, and they knew their own infrastructure was exposed to the same bug.

SOCRadar also saw forum threads asking for a working exploit, with one user complaining that the copy they had did not work across versions. That tracks with everything above. Even the underground, with more motivation than most, was struggling to turn PHP2Shell into a reliable weapon in the first 48 hours. The reliable paths to exploitation usually cost time and skill. This is precisely the capability that collapses once someone packages a working exploit, which is why your assessment should treat "no reliable public exploit yet" as a window that closes, not a conclusion.

For analysts who work this layer, watching how a fresh CVE moves through forums and channels is a core skill, and it is one you can practice safely. Our breakdown of Telegram as a cybercrime marketplace covers how listings, reputation and exploit requests actually read from an analyst's screen, and CTI Academy's NullBase environment lets you track that chatter in a simulated underground without touching live criminal infrastructure.

The Historical Pattern: What a PHP RCE Becomes

PHP2Shell is not the first unauthenticated RCE in widely deployed PHP infrastructure, and the recent history is your best guide to what comes next. Point leadership at the pattern, not at the panic.

In June 2024, CVE-2024-4577, an argument-injection flaw in PHP-CGI on Windows, was disclosed. Imperva reported attacker activity leveraging it to deliver the TellYouThePass ransomware "from as early as June 8th," within about 48 hours of disclosure. That CVE sits in CISA's Known Exploited Vulnerabilities catalog, and CISA records it as used in ransomware campaigns. The older CVE-2019-11043, a PHP-FPM RCE, is in KEV with the same ransomware association.

So the mature exploitation playbook for a PHP RCE already exists, and it has three stages a CTI team should expect:

1. Mass scanning and spray, where commodity actors fire exploits at everything reachable to see what falls over. That is the phase PHP2Shell is in now.
2. Commodity payloads on the winners: web shells, cryptominers, and loaders. VulnCheck told SecurityWeek it already saw at least one Chinese IP unsuccessfully attempt to deploy a web shell via PHP2Shell.
3. Hand-off to ransomware and access brokers. A pre-authentication RCE on an internet-facing server is exactly the merchandise an initial access broker sells into the ransomware-as-a-service supply chain. The TellYouThePass precedent is the template.

The one novel element with PHP2Shell is how it was found. Wiz, Calif and OpenAI all credit frontier AI models with turning a decade-old, hard-to-exploit memory bug into a working exploit, and Amazon argues the same technology shrinks the gap from patch to exploit because a model can help turn a diff into a working attack. The honest CTI read is narrow: do not overclaim an "AI-powered attack wave," because the attacks observed so far are ordinary scanning. The durable shift is to the supply of exploits. Assume the time from disclosure to a weaponized, version-flexible exploit is now shorter than your last playbook assumed.

Turn PHP2Shell Into Intelligence Requirements

An event like this is where the intelligence lifecycle earns its keep. Resist the urge to forward vendor blogs into a channel and call it intelligence. Convert the event into requirements and answer them.

A workable set of priority intelligence requirements for PHP2Shell:

• Exposure. Which of our internet-facing assets run PHP, on which version and SAPI (mod_php first), including shadow IT, acquisitions and vendor-hosted sites? Which are patched versus mitigated versus neither?
• Prior compromise. Is there evidence of exploitation against our estate from 17 October onward, before we knew to look?
• Third-party and supply chain. Which of our vendors and appliances embed PHP? NCSC-NL maintains an operational-information repository that CERT-EU and others point to for products with a PHP dependency.
• Actor tracking. Who is moving from scanning to payload delivery against our sector, and with what?

Then produce three things, not one. A short flash report for leadership that states impact, exposure and the one action (patch now), with confidence levels and the attempt-versus-compromise distinction intact. A technical advisory for the SOC and IR with hunt guidance and detections. And a watch item that stays open, because the KEV status, the exploitation picture and the available exploits will all change after this article is written. Always cite the as-of timestamp; "not in KEV" was true on 21 October and may not be true when your reader opens the report.

Detection and Hunting, From the Defender's Side

These flaws act below the application layer, so your application logs may show very little. The behavioral signals that vendors converge on, from Wiz, Amazon and the aggregators, are worth handing to your SOC:

• Unusual multipart upload requests followed by memory-limit errors or repeated HTTP 500 responses from a PHP host.
• POST requests carrying the PHP_SESSION_UPLOAD_PROGRESS field in form uploads.
• Oversized or malformed PHPSESSID values.
• On a web server account: unexpected child processes spawned by PHP, new files in the web root, modified PHP files, new admin users, new scheduled tasks, and odd outbound connections.

Treat those as correlation signals, not standalone indicators. Session upload progress and multipart uploads are legitimate features that fire on normal traffic, so a single one of these on its own is noise. What matters is the sequence: an unusual upload, then a memory-limit error or a 500, then a new file or process under the web server account. The post-exploitation signs (new web-root files, spawned processes, new accounts) carry far more weight than the request-side ones.

Two practical notes for an intelligence-led hunt. First, build detections that do not depend on a CVE-specific signature, because as Amazon warns, the first exploitation often arrives before those signatures exist. Correlating the behaviors above can surface a variant your CVE-specific rule misses, though you should expect false positives and tune accordingly. Second, open-source detection content shipped fast and from credible hands: AhnLab notes the earliest PHP2Shell GitHub repo, created 18 October, carried Corelight Zeek and Suricata rules, and NCSC-NL's repository is a vetted starting point. Pull from maintained, named sources, not from the PoC pile.

If a hunt fires, treat any pre-patch internet-facing PHP host as suspect until cleared. Isolate it, preserve the web server and PHP logs, and look for the web shells and backdoors before you wipe and rebuild. The NCSC's guidance is explicit on this point: assume an attacker may have left a backdoor, and hunt for it rather than assuming the patch closed the door behind them.

Where Judgment Comes From

You can read every advisory linked above and still freeze the first time a PHP2Shell flash report is due in twenty minutes and the sources disagree. Theory teaches you the intelligence lifecycle and the reliability scales. Knowing which number to give leadership when six scans disagree, how to phrase "exploited in the wild" without overstating it, and when to escalate a watch item to an incident, that judgment only comes from doing it under pressure, repeatedly.

That is the gap CTI Academy is built to close. Our Hunter track takes you from the fundamentals through live tradecraft, and our labs let you work a breaking-CVE scenario, draft the assessment and track actors through a simulated underground, without touching real criminal infrastructure or a production server. You build the reps before the real thing lands on your desk. If you want to turn reading about events like PHP2Shell into the skill of reporting on them, start with the Hunter track.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the nickname for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. Both are rated CVSS v4.0 9.2 and can allow an unauthenticated attacker to run code on a web server, or read sensitive memory from the PHP process. The name comes from Wiz Research, which found the flaws with Calif and OpenAI.

Is PHP2Shell being exploited in the wild?

Yes, exploitation attempts are widespread, but confirmed successful compromises are not well established as of 22 October 2026. Amazon observed a first attempt on 17 October, four days before disclosure, and says it is now broadly exploited. watchTowr and Cloudflare also saw attempts. At the same time, watchTowr, CISA and Recorded Future caution that most circulating exploit code does not reliably achieve code execution. Treat attempts and compromises as different things in your reporting.

Which PHP versions are affected by CVE-2026-109618 and CVE-2026-109619?

Every PHP version from 5.4 onward is affected by at least one of the two flaws. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP security team published source-only backports for end-of-life 7.4, 8.0 and 8.1, and released nothing for 5.4 through 7.3. All web-serving setups are at risk, with Apache mod_php rated highest.

How do I know if my PHP is actually patched?

Do not trust the version string alone. Linux distributions received the fix in advance and often backport it without changing the version number, so a box may be patched under an old-looking version, or unpatched despite looking current. Check the package changelog for the CVE IDs, confirm the runtime that actually serves web requests was updated, and restart Apache, PHP-FPM and any long-running workers afterward.

Are the GitHub PHP2Shell exploits safe to run?

No. Many public "php2shell" repositories are fake, non-functional, or malicious. JFrog found PoCs carrying hidden malware, and AhnLab flagged "mitigation" scripts that request root as a possible attack path. Security researchers are a known target for backdoored tooling. Never run public PoC code on a corporate machine; validate only in an isolated lab against a target you own, after reading the code, or use vendor-maintained scanner checks.

Is PHP2Shell in the CISA KEV catalog?

As of 21 October 2026, neither CVE-2026-109618 nor CVE-2026-109619 was in CISA's Known Exploited Vulnerabilities catalog, and CISA said it had not observed exploitation at the time of its alert. KEV status changes frequently, so check the live catalog before relying on this. Note that two older PHP RCEs, CVE-2024-4577 and CVE-2019-11043, are already in KEV and recorded as used in ransomware.

Why does PHP2Shell matter to a threat intelligence team and not just to IT?

Patching PHP2Shell is a vulnerability management task. A CTI team's job is to answer when and how it will be exploited, how exposed the organization is across its full attack surface, who is likely to use it, and what to tell leadership with the right confidence levels. PHP2Shell is a case study in exploitation preceding disclosure, in exposure data that disagrees, and in a PoC flood that needs source grading.

What is the single most important action to take right now?

Update to a fixed PHP release, prioritizing internet-facing hosts and Apache mod_php first; updating is the only complete fix. In parallel, because exploitation predates disclosure, pull and preserve logs for internet-facing PHP hosts and hunt back to at least 17 October before the evidence rotates out.

Sources

• PHP Foundation: Today's PHP security release and how we're strengthening PHP security
• PHP: News Archive (October 2026)
• Wiz Research: PHP2Shell, AI uncovers critical RCE vulnerabilities
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure in MadPot
• Cloudflare: Deploying protections against php2shell
• CERT-EU Security Advisory 2026-018
• UK NCSC: Critical security issue affecting PHP
• CISA: Critical vulnerabilities in PHP require immediate patching
• Recorded Future: PHP2Shell exploitation
• JFrog Security Research: PHP2Shell, all you need to know
• AhnLab ASEC: Analysis of the GitHub php2shell repositories
• SecurityWeek: PHP2Shell exploitation started days before patches
• SOCRadar: PHP2Shell CVE-2026-109618 and CVE-2026-109619
• Tenable: php2shell FAQ
• The Hacker News: PHP issues emergency patches for two critical PHP2Shell RCE flaws
• NCSC-NL: php2shell operational information repository
• W3Techs: Usage statistics of PHP
• Google TAG: New campaign targeting security researchers (2021)
• Imperva: CVE-2024-4577 weaponized to distribute TellYouThePass ransomware