Recently Added
Summarize with AI
PHP2Shell vulnerability: What it is and how to protect your PHP servers
Key takeaways:
- The PHP2Shell vulnerability is a pair of critical bugs inside PHP itself, so even a correctly built website is at risk.
- Both bugs let an attacker run their own commands on a server with no login, which is called remote code execution.
- They carry a CVSS score of 9.2 out of 10 and affect PHP versions going back to PHP 5.4, released over a decade ago.
- PHP shipped fixes on October 21, 2026, and attacks started in the wild before the patch was even public.
- Updating PHP is the only complete fix, and temporary settings only reduce part of the risk.
- AI played a direct role in finding and building the attack, which is why researchers call it an inflection point for security.
In October 2026, security researchers disclosed the PHP2Shell vulnerability, one of the most serious web security problems in years. It is not a flaw in one plugin or one website. It sits inside PHP, the language that runs most of the web, which means millions of sites were exposed at the same time.
The short version is simple. An attacker can send a few web requests to a server and take full control of it, with no username and no password. From there, they can read the database, steal passwords, change the website, or plant hidden code to come back later.
This guide explains the PHP2Shell vulnerability for everyone, whether you run a small WordPress blog or manage servers for a large company. It covers what the bug is, how it works in plain language, what the latest news says about real attacks, and the exact steps to stay safe.
PHP2Shell at a glance
- CVEs: CVE-2026-109618 and CVE-2026-109619
- Severity: CVSS v4.0 score of 9.2, rated critical
- Impact: unauthenticated remote code execution, plus memory disclosure
- Affected versions: every PHP release back to PHP 5.4
- Affected setups: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed
- Patched on: October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35
- Status: added to the CISA Known Exploited Vulnerabilities catalog on October 26, 2026, with active attacks confirmed
What is the PHP2Shell vulnerability?
PHP2Shell is the nickname for two critical security bugs in the core of PHP, tracked officially as CVE-2026-109618 and CVE-2026-109619. Together, they allow remote code execution, which is the most dangerous outcome a web bug can have.
Remote code execution means someone sitting anywhere in the world can run their own commands on your server. They do not need to touch your machine. They send something over the internet, and your server starts following their orders. Once that happens, they can read your data, steal user passwords, deface your site, and install hidden programs to return later.
The name itself tells the story. A shell is the place where you type commands to control a computer. So PHP2Shell means going from PHP to a shell, that is, from a normal web request all the way to full command control of the server.
Here is what makes this one stand out:
- Where the bug lives: inside PHP itself, not inside a plugin or a theme, so even a perfectly written website is affected
- Login needed: none, which is why security teams call it unauthenticated; the attacker needs no account on the site
- Server setups affected: all the common ones, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed
- Proof it works: the researchers took full control of the latest versions of WordPress, Drupal, and Joomla during testing
Why the PHP2Shell vulnerability is such a big deal
The reason PHP2Shell worries so many people is scale. According to W3Techs, PHP is used by around 74% of all websites whose server-side language is known. The researchers at Wiz, who disclosed the bug, put the figure at roughly 70% of the internet. Either way, this is the software behind a huge share of the web.
PHP is the engine under WordPress, Drupal, Joomla, and MediaWiki, the platform that runs Wikipedia. A flaw in the core of PHP reaches across all of them at once. That is very different from a bug in a single plugin that only a few thousand sites use.
The technical scores back up the concern. Both CVEs carry a CVSS v4.0 score of 9.2, which lands in the critical band. Both allow remote code execution without any login or user interaction. The flaws are classified as CWE-824, access of an uninitialized pointer, a well-known class of memory safety bug.
The age of the problem is striking too. The vulnerable code has been in PHP for more than a decade. The researchers say every PHP version released since PHP 5.4.0 is affected by at least one of the two bugs, although not every single release was tested one by one. In practice, if your server runs PHP and has not been patched since October 21, 2026, you should assume it is exposed.
How the PHP2Shell vulnerability works, in plain English
To see how a language can have a bug this serious, it helps to picture how a PHP server handles a visit. A PHP server keeps a few helpers ready at all times. These are called workers. Think of a restaurant with a few waiters. A customer comes in, a waiter takes the order, serves the food, clears the table, and moves on to the next customer. One worker handles many requests, one after another.
To do its job, a worker uses two kinds of memory. Request memory is scratch space for one request and gets thrown away when the request ends. Long-living memory stays with the worker across many requests, like the waiter’s notebook that stays all day while the order slips get torn off.
The cleanup step at the end of each request matters most here. Cleaning up means two things: the request memory is handed back so it can be reused, and every note in long-living memory that points to that memory is erased, so nobody uses it again by mistake. PHP also has a safety limit called memory_limit. If one request asks for more memory than allowed, PHP stops it at once with an out of memory error. PHP2Shell begins right at that stop.
The weak spot is a bug called use-after-free. Imagine you check out of hotel room 305, but the front desk forgets to deactivate your key card. A new guest moves in. Your old card still opens the door, and if you walk in, you treat their belongings as your own. In software, that key card is a pointer, a note that says where data is kept. When memory is handed back but the pointer is not erased, it becomes a dangling pointer.
Here is the attack, step by step:
- Step 1: The attacker sends a request, often a file upload, shaped to cross the memory_limit at a very precise moment.
- Step 2: PHP hits the limit and stops the request immediately. The request memory is thrown away.
- Step 3: Because the stop was sudden, some cleanup never runs. A pointer in long-living memory still points at the freed memory. That is the dangling pointer, the key card that still works.
- Step 4: The worker does not die. It moves on like the waiter. The attacker sends more requests until one lands on that same worker.
- Step 5: The second request carries data the attacker has shaped. PHP places it in memory, and it lands in the exact spot the dangling pointer still watches.
- Step 6: PHP trusts the old pointer and reads the attacker’s data as its own. The data is crafted so PHP jumps to code the attacker chose.
- Step 7: PHP runs those instructions. The attacker now has a shell on the server.
All of this happens very early, before the website’s own code even starts running. That is the reason a correctly built site is still at risk. The developer did nothing wrong.
The first request leaves the dangling pointer behind. The second request reuses it. Neither one needs a username or a password.
The two bugs behind PHP2Shell
PHP2Shell is not one bug but two, and both follow the same pattern: an out of memory stop skips cleanup, and something reuses freed memory later.
CVE-2026-109618 is the upload progress bug
PHP has a feature called session upload progress that lets a site show a progress bar while a large file uploads. It is on by default and runs while PHP reads the uploaded data before the website’s code starts.
So even a site that never shows a progress bar has this code running. When an upload is stopped by an out of memory error, the feature leaves behind pointers to freed memory, and a later upload on the same worker fills that space with attacker data.
CVE-2026-109619 is the fatal error and OPcache bug
It has two parts. The first is about error backtraces: when a serious error happens, PHP can save the list of steps that led to it, and after an out of memory stop it can forget to erase the pointer to that saved data.
The second is about OPcache, a feature that stores already-prepared PHP code in shared memory so pages load faster. Shared memory is used by all workers together. If PHP runs out of memory while saving code into OPcache, two internal counters fall out of sync, and another worker can later read one kind of data as if it were another. This mix-up is called type confusion, and attackers use it to take over the server.
Here is a side-by-side view:
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| Where the bug lives | Session upload progress | Fatal error backtrace and OPcache |
| Kind of bug | Use-after-free | Use-after-free and type confusion |
| Triggered by | Out of memory during an upload | Out of memory or a fatal error |
| Login needed | No | No |
| Severity (CVSS v4.0) | 9.2 critical | 9.2 critical |
The researchers noted that both bugs have high attack complexity.
Triggering the crash is fairly easy, but turning it into working code execution takes careful timing and memory shaping. That is the step where AI made the biggest difference, which is the next part of the story.
Why AI makes PHP2Shell different
PHP2Shell was found by Wiz Research, a cloud security company, working with Calif and OpenAI. What sets this disclosure apart is how much AI was involved in the work.
The vulnerable code had been sitting in PHP for more than ten years. It stayed hidden, not because nobody looked, but because turning the flaw into a real exploit was extremely hard. It meant chaining several bugs together and adjusting to how each server lays out its memory, with constant testing and debugging. An attack that worked on one setup often broke on the next. That level of effort used to put this kind of exploit out of reach for most people.
AI changed that math. The researchers used frontier models to help find the bugs, build working attacks across different PHP versions, and even help verify the patch. Wiz called this the AI inflection point: a single researcher did in about a week what a world-class team would once have needed months to do. AI did not create the flaw. It removed the difficulty that had kept the flaw safe for a decade.
The same shift cuts both ways. AI helps defenders find and fix deep bugs faster, but it also shortens the gap between a bug becoming public and attackers using it. This is where AI development services that build security in from the start become a real advantage. PHP2Shell is an early, very public example of what that world looks like.
The latest: PHP2Shell is now being exploited in the wild
This is no longer a theoretical risk.
On October 26, 2026, the US Cybersecurity and Infrastructure Security Agency added both CVEs to its Known Exploited Vulnerabilities catalog, confirming active attacks. CISA ordered federal civilian agencies to patch by October 29, 2026.
The timeline shows how fast this moved. Amazon Threat Intelligence traced the earliest exploitation attempt to October 17, four days before the patch was even public. Researchers then confirmed real success, not just crashes. A Perplexity detection lead reported confirmed remote code execution with usable memory disclosure against honeypot systems running PHP 8.4.26.
The scale of exposure is the worrying part. According to Censys data reported by CyberNews, around 32.5 million PHP services were still running vulnerable versions nearly a week after disclosure, with more than 10 million of them in the United States.
Patching has been slow. Tracking cited in the same reporting showed only the Netherlands had passed a 50% patch rate among exposed hosts, and UK patch deployment sat near 25%.
CISA has not yet confirmed ransomware tied to these attacks, but its own advisory flags Apache with mod_php as the highest-risk setup. Working PHP2Shell exploit code is already circulating so these remote code execution attacks are among the most urgent cybersecurity threats on the web right now.
The message from every major security body is the same: patch now, because attackers already have working tools.
How to fix and mitigate the PHP2Shell vulnerability
There is one real fix and a few stopgaps. The one that actually closes the hole is updating PHP. If your team is stretched thin, professional PHP development services can handle the upgrade and hardening for you.
Update PHP immediately
The patched versions, released on October 21, 2026, are:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Mind the old versions. PHP 8.1 and older no longer get official updates. The PHP team shared source-code fixes for 7.4, 8.0, and 8.1, and some hosting providers and operating systems ship their own patched builds, but the real long-term step is moving to a supported version.
If you cannot patch today, apply temporary settings
If you cannot patch today, apply temporary settings. These reduce risk but do not close every path, so treat them as a bridge, not a solution:
- Turn off session upload progress: set session.upload_progress.enabled = 0 in php.ini, then restart the PHP workers; this closes the upload path used by three of the five demonstrated techniques
- Turn off saved error backtraces (PHP 8.5): set fatal_error_backtraces = 0 to close the backtrace path
- Consider disabling OPcache: set opcache.enable = 0 after testing for performance impact, since the OPcache path is shared across all workers
- For PHP-FPM, limit worker reuse: set pm.max_requests = 1 so each worker is replaced after one request, which breaks the same-worker trick, though it slows the server and does not stop the OPcache path
Use a web application firewall
Use a web application firewall. A WAF sits in front of your site and checks every request before it reaches the server. Providers including Cloudflare, Google, and Imperva have added rules that block known PHP2Shell patterns, which buys time while you patch.
Check whether you have already been hit
Check whether you have already been hit. Watch for many failed upload requests followed by out of memory errors, bursts of server errors in a short window, and unusually large or strange PHPSESSID response cookies. If you see these signs, treat the server as possibly compromised and start incident response.
A PHP core developer has been clear that no single setting fully protects a server. Updating PHP is the only complete remediation.
Who is affected by PHP2Shell
The simplest way to think about it: if your site runs on PHP and you have not patched since October 21, 2026, assume you are exposed.
That includes the big content platforms. WordPress, Drupal, and Joomla all run on PHP, and the researchers took full control of the latest versions of each during testing. The bug is in PHP, not in these platforms, so their own code being secure does not help. A WordPress site with no plugins at all is still affected if the PHP underneath it is unpatched.
It also includes older PHP. Versions back to PHP 5.4 are affected by at least one of the two bugs. Many businesses still run PHP 7.4 or earlier on legacy servers, and those are squarely in scope. The catch is that these old versions no longer get official patches, so they carry extra risk.
And it covers every common server setup: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. CISA flags Apache with mod_php as the highest-risk configuration. Even a bare hello-world PHP app on an affected version can be vulnerable because the weak code runs before the app does.
PHP security best practices beyond this one bug
PHP2Shell will be patched and fade from the headlines, but the lessons it teaches apply to every server you run. A few habits keep you ahead of the next critical flaw.
- Stay on a supported PHP version: once a version stops getting official security updates, every new bug in it becomes a permanent risk. Plan upgrades before a version reaches end of life, not after.
- Patch on a schedule, not in a panic: attacks on PHP2Shell began before the fix was public, so the window to react is shrinking. A routine for applying security updates quickly is now a core defense, not a nice-to-have.
- Run a web application firewall: a good WAF is a core part of web application security, giving you a virtual patch that blocks known attack patterns while you deploy the real fix. This matters most in the first hours after a disclosure, when PHP server protection buys you time to update safely.
- Apply least privilege: limit what the PHP process can read and reach, so that if an attacker does get code execution, the damage is contained rather than total.
- Watch your logs: unusual spikes in server errors, memory errors, or odd session cookies are early warning signs. Catching them early can mean the difference between a blocked attempt and a full breach.
Memory safety is genuinely hard in languages like C, which is what PHP is built on. One forgotten pointer became a critical bug that survived a decade of review. That is a reminder that careful error handling and strong monitoring are not optional for anything exposed to the internet.
Final word
The PHP2Shell vulnerability is a wake-up call wrapped in a patch. It shows how a single memory bug in shared software can put most of the web at risk at once and how AI has shortened the time between a flaw being found and being attacked.
The fix is clear and available, so the only real question is how fast you apply it. Update PHP, add a firewall layer, check for signs of compromise, and treat secure error handling as a permanent part of how you build.
FAQs
