PHP2Shell: Inside the Critical PHP Vulnerability That's Putting Millions of Websites at Risk

Somewhere between October 17 and October 21, 2026, a four-day window opened where an unknown number of PHP-powered websites were sitting exposed to an attack that needed no password, no stolen credentials, and no social engineering — just a specially crafted file upload sent to a server running software most of the internet depends on without thinking about it twice.

By the time PHP's maintainers shipped an emergency patch on October 21, security researchers were already calling it one of the most serious PHP vulnerabilities in years. It has a name now — PHP2Shell — and two CVE numbers that are worth remembering if you run anything on PHP: CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS score of 9.2 out of a possible 10. One security firm, watchTowr, rated it a full 10.0.

If that sounds abstract, here's the concrete version: PHP quietly runs a majority of the web's server-side code. WordPress runs on it. So does Drupal, Magento, and a long list of custom applications built by teams who never think about the language underneath their framework until something like this happens. A critical, unauthenticated remote-code-execution bug in PHP itself isn't a niche developer problem — it's closer to a plumbing failure in a city's water system. It doesn't matter how nice your house is if the pipe feeding it is compromised.

This piece walks through what actually broke, why it took two separate bugs working together to create something this dangerous, who's exposed, what's already been observed in the wild, and — most importantly — exactly what to do about it, whether you're the person who manages the server or just the person whose website happens to run on one.

What Is PHP2Shell, in Plain Terms

Strip away the CVE numbers and the technical detail for a second, and PHP2Shell comes down to this: a server running PHP can be tricked into leaving behind corrupted internal memory, and that corrupted memory can then be abused by a second, carefully timed request to make the server execute code the attacker chose — not the code the website's developer wrote.

No login is required. No existing account, no stolen session, no phishing email. Just two requests, sent in the right order, against the same worker process.

That's the part that makes this different from the steady background noise of PHP security advisories that come out every few months. Most of those affect a specific function, a specific configuration, or require the attacker to already have some foothold. PHP2Shell doesn't. It targets the language runtime itself, from the outside, with nothing but HTTP requests.

A quick summary of the essentials:

• What it is: Two chained vulnerabilities in PHP's core runtime — CVE-2026-109618 (a memory-corruption bug) and CVE-2026-109619 (a stale-state, use-after-free bug) — that together allow unauthenticated remote code execution.
• Severity: CVSS v4.0 score of 9.2 from PHP's own advisory; watchTowr independently scored it 10.0.
• Affected versions: Every PHP release from 5.4 through 8.5.11.
• Fixed in: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, released October 21, 2026.
• Exploitation status: Reported exploitation attempts as early as October 17 — before the public disclosure — with watchTowr reporting active in-the-wild exploitation since the patch date.
• CISA KEV status: As of October 22, neither CVE had been added to CISA's Known Exploited Vulnerabilities catalog yet, so organizations relying on that list as a trigger for urgent patching hadn't been prompted by it at the time of writing.

How the Timeline Actually Unfolded

Understanding the timeline here matters almost as much as understanding the bug itself, because it tells you something uncomfortable: by the time most website owners heard about PHP2Shell, it had already been under attack for days.

Different sources give slightly different starting points. Wikipedia's entry on the vulnerability lists a discovery date in August 2026, well before the public disclosure, which suggests the people who found it — whether researchers or attackers — had a significant head start on everyone else. Other sources don't commit to a discovery date at all, and accounts of exactly how the disclosure was staged differ enough that it's worth treating the early history as murky rather than settled.

What's clearer is the window right around the patch itself. Amazon's threat intelligence team reported observing an exploitation attempt on October 17 — a full four days before PHP's official advisory and patched releases existed. That's the detail that should give anyone pause: this wasn't a case of researchers responsibly disclosing a bug and then attackers scrambling to reverse-engineer a patch afterward. Whoever was behind that October 17 activity already knew how to exploit this before the rest of the world had a name for it.

The CVE identifiers themselves started circulating publicly on October 20. PHP shipped the fix the next day, October 21, across four release branches simultaneously — a sign of how seriously the maintainers treated this, since coordinating a same-day release across 8.5.x, 8.4.x, 8.3.x, and 8.2.x isn't something that happens for routine bugs. watchTowr's own monitoring reported active in-the-wild exploitation starting that same day, the 21st, and continuing afterward.

As of October 22, the day after the patch, CISA's Known Exploited Vulnerabilities catalog — the list many government agencies and larger organizations use as a mandatory-patching trigger — hadn't added either CVE yet. If your organization's patching priorities are driven by that list specifically, this is a case where waiting for it would have meant staying exposed well past the point where active exploitation was already confirmed by multiple independent security research teams.

The practical lesson: for a vulnerability this severe, "wait for it to show up on the official list" is not a safe patching strategy. The gap between "patch available" and "official exploited-vulnerability designation" can run into days, and days are more than enough time for an automated scanning campaign to find and hit every exposed server it can.

CVE-2026-109618: When Running Out of Memory Breaks Everything Around It

The first of the two bugs is, in a strange way, almost mundane in its origin. PHP enforces a memory limit for every request it processes — the memory_limit setting most PHP developers have adjusted at some point when a script started throwing fatal errors. When a request hits that ceiling, PHP has to abort it immediately rather than let the process keep consuming memory indefinitely.

The problem is in how that abort happens. According to the technical write-ups from multiple security research teams, PHP sometimes aborts a request by jumping directly out of whatever operation it was in the middle of — not unlike yanking the power cord instead of shutting a machine down properly. In a handful of specific places in PHP's internals, there's request-scoped data that's only partially constructed at the exact moment that abort happens. The abrupt jump-out leaves that data in a broken, half-finished state.

Here's where it turns dangerous: the cleanup routine that runs afterward doesn't know the data is broken. It treats the half-built structure as if it were valid and finished, and processes it accordingly. Depending on exactly which internal structure is involved, researchers describe the end result as a pointer left pointing at memory that has already been freed — the kind of bug that, in C-based software like PHP's own interpreter, routinely escalates from "memory corruption" to "attacker-controlled code execution" once someone works out how to control what ends up in that freed memory before it gets reused.

What makes CVE-2026-109618 practical to exploit — rather than just theoretically interesting — is how it gets triggered. An attacker doesn't need to find some obscure edge case or send malformed binary data that trips a parser. According to the published analysis, a crafted multipart file-upload request is enough: specifically, a request with an unusual number of headers, or a large number of empty file fields, engineered to deliberately exhaust PHP's per-request memory limit. Crucially, this can reportedly be done while staying entirely within PHP's normal, configured upload limits — meaning a server administrator who's already set sensible upload-size restrictions doesn't automatically get protection from this, because the attack isn't about uploading something huge. It's about uploading something shaped in a way that causes memory pressure regardless of total size.

If you've ever built a contact form, an image uploader, or really any endpoint on a PHP site that accepts file uploads — which describes an enormous share of the web — you had a code path that could, in principle, be aimed at this bug.

CVE-2026-109619: The Bug That Doesn't Even Need a Crash

If CVE-2026-109618 is about a single request breaking in a specific way, CVE-2026-109619 is the one that should concern people more, because it doesn't require anything as dramatic as an out-of-memory crash to happen at all.

To understand it, it helps to know roughly how a PHP server actually processes traffic under the hood. Rather than starting a fresh process for every single request, PHP typically runs through a pool of long-lived worker processes — this is how PHP-FPM, the FastCGI Process Manager most modern PHP deployments use, operates. Each worker handles many requests back-to-back over its lifetime, which is far more efficient than spinning up a new process every time someone loads a page.

But that efficiency comes with a responsibility: a worker has to fully clean up after every request before it starts handling the next one. PHP keeps various pieces of global state tied to the request currently being processed — things related to error handling, session data, object lifecycles, and extension-specific bookkeeping. All of that state needs to be reset, and any memory it points to needs to be properly released, before the next request begins.

CVE-2026-109619 is what happens when that handoff isn't clean. Security researchers describe it as certain operations running before the next request has been properly initialized, at a point where they end up reading stale references left over from the previous request — a textbook use-after-free, except spread across two separate HTTP requests instead of contained within one. And notably, the trigger for this isn't limited to the memory-exhaustion scenario from CVE-2026-109618. Reports indicate it can also be set off by request timeouts and by a client disconnecting mid-request — both of which are things that happen constantly on any production server, intentionally or not, meaning the conditions that enable this bug are far from rare.

One specific code path gets singled out repeatedly across the research: PHP's session upload-progress feature. This is a legitimate PHP capability that lets a page show a live upload-progress bar by tracking file-upload status through session data. The way it works, PHP decodes — unserializes — session data before any of the website's actual script code even begins running. According to the published analysis, that decoding step doesn't verify the data genuinely originated from PHP's own session-handling code, meaning data the user influenced through what they uploaded can end up being decoded as if it were trusted, internally generated session data.

Put together, CVE-2026-109619 gives an attacker a two-step attack: one request to "poison" a worker's leftover state, and a second request against that same worker to trigger the bug and reach memory it shouldn't be able to reach — again, all without ever authenticating.

It's worth being transparent about one area of disagreement in the public research here. Some early coverage attributed the session upload-progress path to CVE-2026-109618, but according to the security firm ELLIO's review of the official advisories, that path belongs specifically to CVE-2026-109619 — PHP's own advisory for 109618 reportedly never mentions sessions at all. If you're going deep into the technical weeds on this for your own incident response, it's worth checking PHP's official advisories directly — GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp — rather than relying on any single secondary source, including this one.

Why Chaining Two Bugs Is What Makes This a Nightmare Scenario

Individually, either of these bugs would already be a serious finding worth an emergency patch. Together, they describe something closer to a worst-case scenario for a web-facing language runtime.

CVE-2026-109618 gives an attacker a reliable way to deliberately corrupt a worker's memory, on demand, using nothing more exotic than a file upload. CVE-2026-109619 gives that same attacker a way to exploit stale state across requests more broadly — not just through the memory-exhaustion path, but through ordinary conditions like timeouts and disconnects that happen on every production server without any attacker involvement at all.

Chain them, and you get a process that can go from "handling normal web traffic" to "executing attacker-supplied code" in two requests, with no authentication step anywhere in that sequence, and multiple independent trigger conditions. According to PHP's own advisory, both vulnerabilities are exploitable by an unauthenticated remote attacker, and the advisory for CVE-2026-109619 specifically lists memory disclosure as a confirmed impact on top of code execution — meaning even short of full code execution, an attacker working this bug has a path to reading memory contents they were never meant to see, which on a shared server could include fragments of other tenants' data.

This is also exactly the kind of vulnerability that tends to get weaponized quickly and broadly, rather than used carefully against a single high-value target. Unauthenticated, remotely triggerable, affecting an enormous installed base, with no need for any prior reconnaissance beyond knowing a server runs PHP — that combination is close to ideal for mass, automated scanning campaigns. Attackers don't need to pick a target. They can scan the entire internet for anything running an unpatched PHP version and let the exploit do the work at scale. That pattern — rather than a quiet, targeted attack — is consistent with what watchTowr and other researchers have reported observing since the 21st.

Who's Actually Affected

The honest answer is: almost certainly more websites than anyone would like to admit.

According to the Google Cloud advisory covering this issue, every PHP version from 5.4 through 8.5.11 is affected. If you translate that into real-world terms, it covers essentially the entire active installed base of PHP as it existed before October 21, 2026 — which includes a staggering range of what's actually running on the internet:

• WordPress sites, which make up a huge share of all websites globally, almost all of which run on PHP under the hood regardless of which theme or page builder sits on top.
• Drupal and Magento installations, both PHP-based platforms still widely used for content sites and e-commerce respectively.
• Custom-built applications written in Laravel, Symfony, CodeIgniter, or raw PHP without any framework at all — the kind of software that often gets the least ongoing maintenance attention precisely because it "just works" and nobody wants to touch it.
• Shared hosting environments, where a hosting provider's PHP version update schedule — not the individual site owner's — determines exposure, and where a single vulnerable PHP installation can sit underneath thousands of unrelated customer websites at once.
• Internal business tools and admin panels built in PHP years ago, often the least-visible and least-patched software in an organization because nobody's actively using it as a public-facing product.

It's also worth being specific about what being affected does not depend on. It doesn't matter whether you're running the latest version of WordPress, the latest security plugin, or a fully updated theme — none of that touches the underlying PHP runtime, which is where this vulnerability actually lives. A site with a perfect WordPress security score can still be running a vulnerable PHP version underneath it, because most site owners never think to check PHP version numbers directly; they think about plugin updates.

There's also a notable spillover into products you might not immediately associate with "a website." Cisco published a security advisory covering its own products affected by the underlying PHP flaw, which is a reminder that PHP doesn't only run public blogs and online stores — it quietly powers management interfaces, internal tools, and embedded components inside commercial software from vendors you'd expect to be running something more exotic. Cisco's advisory notably used a different CVSS vector tailored to how the vulnerability manifests in its specific products, which lowered the practical severity score to 6.6 in that particular context — a useful reminder that the headline 9.2/10.0 score describes the worst-case exposure, and your actual risk depends on your specific deployment, configuration, and what's reachable from the public internet.

What's Actually Been Observed in the Wild

This isn't a theoretical vulnerability sitting in a lab waiting for someone to eventually weaponize it. Multiple independent security vendors have reported real exploitation activity tied to specific dates.

Amazon's threat intelligence team reported an exploitation attempt on October 17 — four days before the public patch existed, which strongly suggests either independent discovery by a malicious actor or a leak of vulnerability details ahead of the coordinated disclosure. watchTowr, a security research firm that's been tracking this closely, reported observing in-the-wild exploitation of both CVE-2026-109618 and CVE-2026-109619 starting from the patch release date of October 21 onward.

Security teams at CrowdStrike, Qualys, Tenable, Datadog, and Imperva have all published their own analyses and protection guidance in the days immediately following disclosure — the kind of rapid, coordinated response from major security vendors that tends to happen only for vulnerabilities taken extremely seriously across the industry, not for routine findings.

There's a complicating wrinkle worth knowing about if you go looking for exploit code yourself out of curiosity or urgency: code claiming to exploit CVE-2026-109618 and CVE-2026-109619 is already circulating publicly. Tenable's research team has explicitly stated they have not verified that this code actually works against the real vulnerabilities, and flagged that unverified exploit code circulating after a high-profile disclosure is sometimes bundled with malware of its own — meaning downloading and running a random "PHP2Shell exploit" script from a forum or a GitHub repo to "test" your own exposure carries its own very real risk, separate from the vulnerability itself. If you need to verify whether your server is exposed, the safer path is checking your PHP version number against the patched releases directly, not running third-party exploit code against your own infrastructure.

Why a PHP Vulnerability Matters This Much

It's worth stepping back from the technical detail for a moment to explain why a bug in a 30-year-old scripting language deserves this much attention in the first place, especially for readers who don't think about server infrastructure day to day.

PHP has powered the server-side logic of a majority of the web for most of its existence. That's not a niche fact — it's closer to saying that most houses on a given street draw water from the same municipal pipe. When something breaks in a dependency that widely shared, the blast radius isn't measured in individual websites; it's measured in entire categories of the internet at once.

This also illustrates something that's easy to lose sight of in a world of constant plugin updates, framework releases, and security patches at every layer of a typical web stack: the language runtime underneath all of it is itself a piece of software, written by people, with its own bugs. Developers spend enormous energy securing their application code, auditing their dependencies, and hardening their CMS configuration, while the interpreter actually executing all of that code gets treated as a fixed, trustworthy foundation that nobody needs to think about — until a week like this one.

PHP2Shell is a useful, if uncomfortable, reminder that "the foundation" needs the same ongoing attention as everything built on top of it.

What To Do Right Now: A Practical Patching Checklist

If you manage a server, application, or hosting environment that runs PHP, here's the sequence that actually matters, in order of priority.

1. Find out exactly what PHP version you're running. Don't assume. Check the actual, currently running version on your production server — not the version listed in a README, not what you think you set up a year ago. On the command line, php -v will tell you what the CLI binary reports, though it's worth separately confirming what your web server's PHP-FPM pool or module is actually running, since these can diverge from the CLI version in more complex setups.

2. Compare it against the patched releases. The fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. If your version number is lower than the matching patched release in your branch — or if you're on a branch that doesn't appear in that list at all — you're running a vulnerable build.

3. Update through your actual installation method. If you installed PHP through your operating system's package manager — which is the case for most Linux server deployments — update through that package manager rather than trying to manually rebuild PHP from source. Your distribution's maintainers typically backport security fixes into their own package versioning scheme, so check your distro's security advisories alongside PHP's own, since the version number reported by your package manager won't always match PHP's upstream numbering exactly.

4. Restart your PHP processes after updating. This is the step that's easy to forget and completely undermines an otherwise successful update. Installing a patched package doesn't help if your PHP-FPM workers or web server processes are still running the old code in memory. Restart PHP-FPM (or your equivalent service) and your web server afterward, and verify the live version again to confirm the update actually took effect in the running process, not just in the installed package.

5. Don't stop at WordPress or CMS updates. Worth repeating because it's the single most common point of confusion here: updating WordPress core, your theme, or your plugins does nothing for this specific vulnerability. This is a PHP-level fix. Treat your CMS updates and your PHP runtime update as two completely separate tasks, because they are.

6. If you're on an end-of-life PHP version, treat this as the forcing function to finally upgrade. Versions that have already reached end-of-life — PHP 7.4 through 8.1 fall into this category here — don't get an official patched release for this vulnerability. According to the Tenable write-up, the PHP security team has published only minimal source backports for some of these older branches, which is a stopgap at best, not a real fix. If this describes your situation, the honest, uncomfortable truth is that you've likely been accumulating unpatched risk for a while, and this is as good a moment as any to prioritize a full version upgrade rather than hoping the next critical bug skips you too.

If You Genuinely Can't Patch Immediately

Sometimes a full PHP upgrade isn't something you can do in the next hour — maybe it requires compatibility testing against a legacy application, maybe it needs a change-management process, maybe you're waiting on a hosting provider. PHP's own advisory is direct about this: there's no complete mitigation short of patching. But a handful of partial steps, compiled from the available security research, can meaningfully reduce your exposure while you work toward a real fix:

• Disable session upload-progress tracking (session.upload_progress.enabled = 0), since this feature is implicated in the CVE-2026-109619 attack chain specifically.
• Set pm.max_requests = 1 on PHP-FPM worker pools. This forces each worker process to be recycled after a single request, which directly breaks the "poison one request, trigger it on the next request handled by the same worker" requirement that CVE-2026-109619 depends on. It comes with a real performance cost — recycling a worker after every request is expensive — so weigh this as an emergency, temporary measure rather than a permanent configuration choice.
• Enforce memory limits through container or cgroup controls rather than relying on PHP's memory_limit setting alone, and specifically avoid using RLIMIT_AS or RLIMIT_DATA as your enforcement mechanism, since researchers have specifically called these out as inadequate substitutes here.
• Be cautious about setting memory_limit = -1 (unlimited) as a workaround for memory-exhaustion errors you might be seeing — doing so actually removes the resource-exhaustion protection PHP would otherwise have in place, which research suggests can make the broader situation worse rather than better in this specific context.

None of these close the vulnerability. They narrow the window and raise the difficulty for an attacker, which matters, but the only real fix is getting onto a patched PHP version as soon as your situation allows it.

If You're a Website Owner on Shared Hosting

Not everyone reading this manages their own server, and that's worth addressing directly, because the advice above assumes a level of infrastructure control that a lot of website owners simply don't have.

If your site runs on shared hosting, managed WordPress hosting, or any platform where your hosting provider — not you — controls the PHP version, your most useful action is a direct question to that provider: has the PHP runtime on my hosting plan been updated to address CVE-2026-109618 and CVE-2026-109619? Some major hosts moved quickly once the advisory became public and have published their own status updates confirming protection for their customers. Others move more slowly, particularly on older or legacy hosting tiers that may be running end-of-life PHP versions nobody's prioritized upgrading.

A few things worth checking or asking about specifically:

• What PHP version is actually running on your hosting plan, not just what the control panel's default setting shows.
• Whether your host has published any public statement or advisory about this specific vulnerability.
• Whether your hosting plan allows you to manually select a newer PHP version yourself through a control panel, which many shared hosts do offer even when they haven't proactively upgraded everyone by default.

If your host can't give you a clear, specific answer within a day or two of asking, that's a meaningful signal about how seriously that provider treats core infrastructure security in general — not just for this particular bug.

How to Tell If You've Already Been Hit

This is the hardest question to answer honestly, because the public security research hasn't converged on a single confirmed set of indicators of compromise the way it sometimes does for other major vulnerabilities. That said, there are general warning signs worth checking for if you were running an unpatched, internet-facing PHP server during the exploitation window — particularly if your server accepted public file uploads and was reachable before October 21.

• Unfamiliar files in your upload directories, especially anything with a .php extension sitting somewhere it shouldn't be able to execute, or files with unusual names, timestamps that don't match your normal deployment activity, or content that looks nothing like a user-uploaded image or document.
• Unexpected child processes spawned by your PHP-FPM workers. PHP workers processing normal web requests generally shouldn't be spawning shell processes, outbound network connections to unfamiliar hosts, or long-running background tasks.
• New admin accounts, API keys, or scheduled tasks you didn't create, particularly on CMS platforms where account creation is a common next step after an attacker gains code execution.
• Unusual outbound traffic from your server to IP addresses or domains you don't recognize, which can indicate a compromised server being used to exfiltrate data or connect to a command-and-control infrastructure.
• Log gaps or log tampering. A more sophisticated attacker who achieves code execution will sometimes try to cover their tracks by modifying or deleting log entries, so unexplained gaps in your access or error logs around the exploitation window are themselves worth treating as suspicious.

If you find genuine evidence of compromise — rather than patching in place and hoping for the best — the safer path is restoring from a known-clean backup taken before the exploitation window, then applying the patch before bringing the restored environment back online. Code execution on a server means an attacker had the opportunity to plant persistence mechanisms well beyond whatever initially triggered your suspicion, and a clean rebuild is the only way to be confident you've actually removed everything they left behind.

The Broader Lesson Here

Every major vulnerability like this one leaves behind more than just a patch number — it leaves a pattern worth remembering for next time.

The first lesson is about speed. The gap between "a vulnerability is disclosed" and "active exploitation at scale" has been shrinking for years across the security industry generally, and PHP2Shell is another data point confirming that trend: exploitation reportedly began before the patch was even public. Waiting for a formal designation on an official exploited-vulnerabilities list, or deferring a patch until your next scheduled maintenance window, is a strategy that assumes attackers move slower than they actually do.

The second lesson is about what actually gets attention versus what doesn't. Application-layer security — plugin updates, dependency scanning, web application firewalls — tends to get consistent ongoing attention because it's visible and directly tied to the software teams actively build and ship. The runtime underneath all of it, PHP in this case, tends to get installed once and then quietly forgotten about for years at a time, precisely because it works invisibly in the background. That asymmetry in attention is exactly what makes runtime-level vulnerabilities like this one so dangerous when they do surface — the patching muscle for "update my PHP version" is far less exercised, organizationally, than the one for "update my plugins."

The third lesson is more personal than technical: if you're responsible for any PHP-based system, however small, this is worth treating as a prompt to build an actual habit of checking your runtime version on a schedule — not just reacting when a vulnerability makes headlines. The next critical bug in a core language runtime won't announce itself with a catchy nickname and a wave of press coverage every time, and your defense shouldn't depend on it doing so.

Wrapping Up

PHP2Shell is a reminder of something that's easy to forget in a world of constantly updated frameworks and plugins: the ground floor of your website — the language actually executing your code — is software too, built by people, and occasionally breaks in ways that matter enormously. Two bugs that individually might have been routine findings combined into something that let an unauthenticated attacker reach code execution on a huge share of the internet's PHP-powered infrastructure, and real exploitation started before most site owners had even heard the name.

If you've read this far and you still don't know what PHP version your server is actually running, that's the one action item worth doing before you close this tab. Check it, compare it against 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and update if you need to. Everything else in this piece — the memory-corruption mechanics, the use-after-free chain, the mitigation options — matters far less than that one, concrete check.

If you want to keep an eye on your broader infrastructure beyond this specific patch, TechPurAI's DNS Lookup tool is a quick, free way to check what's publicly exposed about a domain's configuration, and the Hash Generator tool can help verify file integrity when you're downloading or distributing software updates from anywhere other than an official, trusted source.