Hidden for 14 Years, Found by AI in One Week: The PHP2Shell Story

Imagine seven out of every ten websites on the internet running on the same engine, and that engine has a hidden crack. An attacker can use it to take over a server with a crafted request, no login needed. That is PHP2Shell. The weakness traces back to PHP 5.4, released in March 2012, and it went unnoticed for 14 years. Then AI changed the equation. Researchers used frontier AI models to turn the flaw into working exploits in about a week. Then the CVE IDs (CVE-2026-109618 & CVE-2026-109619) leaked two days early, attack traffic appeared before the fix was ready, and governments across Europe pulled websites offline. It was described as among the most severe flaws ever found in PHP, and arguably in software history.

This blog explains what PHP2Shell is, how the exploit works, and what to do before attackers reach your servers: patch now.

The Birth of PHP2Shell – 14 Years Ago and Now

The story begins in March 2012, when PHP 5.4 was released. Hidden inside was the oldest vulnerable code path tied to PHP2Shell, and it sat unnoticed for 14 years. The danger is simple to state: a hacker could run code on your server without ever logging in.

The warning signs came before the world heard about it, but proper action was not taken in time. On October 17, an Amazon honeypot caught an attack. Cloudflare reported multiple attacks too. PHP2Shell also did not arrive alone. The same period saw a few security incidents like GitLab’s 10/10 severity flaws, India’s eMudhra certificate key breach, AI-powered hacking across 1,200+ websites, and malware hidden inside an AI software package.

About PHP2Shell

It is not a flaw in one website or one plugin. It sits in the programming language itself, and it affects PHP versions from 5.4 all the way to 8.5. The severity score is 9.2 out of 10 on CVSS v4.0, and the attack type is remote code execution. The most chilling detail: no login is needed.

On October 21, 2026, the flaws were given their names. Together, they form the group called PHP2Shell.

The RCE CVE’s List

CVE-2026-109618 (Memory Corruption): an upload-progress unserializer use-after-free that leads to remote process-memory disclosure.

CVE-2026-109619 (Stale State): a fatal-error backtrace use-after-free that leads to OPcache type confusion.

Every version going back to PHP 5.4 is affected. 

The RCE Exploits: AI Found It In One Week

For more than a decade, the flaw hid in plain sight. Turning it into a real attack meant chaining several bugs together and adapting to each server’s memory layout. That work sat at the edge of what human researchers could practically do.

Then AI entered the story.

Wiz Research, working alongside Calif, put frontier AI models to work, including Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol. The models helped find the bugs, build the exploits and adapt them to different setups. Discovery came on August 19. By August 20, unauthenticated remote code execution was confirmed on Drupal, and by August 21 on WordPress. Joomla was demonstrated too.

The PHP2Shell News Surfaced Sooner Than Expected – But Why?

The plan was a quiet, coordinated release. Then the CVE IDs leaked two days early. The PHP team raced to ship the fix a day ahead of schedule. CISA, the NSA, the UK NCSC and CERT-EU all sounded the same alarm: patch now, and if you can’t, take PHP systems offline or off the public internet until you can.

What Happened Next: Many Countries Pulled the Plug

• Germany, France, Czech Republic: took government websites offline
• Netherlands: government portals, hospital sites, political party sites and the Port of Rotterdam went dark
• Finland: shut down public-facing government web services
• Belgium: temporarily took down Foreign Ministry sites
• Denmark: shut down several services
• United States: the NSA urged organizations to update PHP immediately or take affected systems offline
• United Kingdom: the NCSC advised immediate patching and warned organizations to check for weaknesses
• Japan: authorities urged PHP users to apply updates immediately
• Australia: organizations were told to identify PHP systems, prepare patches and watch for suspicious activity
• Wikimedia (Wikipedia): took several systems offline

PHP Patching Versions and How To Fix?

The PHP team has released fixes for both critical flaws in PHP core. These are the bugs that let an attacker run code on your server without logging in. If you run PHP, check that you are on one of these versions or newer:

PHP Branch	Vulnerable Versions	Patched Version
8.5	Before 8.5.12	8.5.12
8.4	Before 8.4.27	8.4.27
8.3	Before 8.3.36	8.3.36
8.2	Before 8.2.35	8.2.35

What to do right now?

• Update PHP to the fixed version for your branch.
• Restart everything that runs PHP, including php-fpm, Apache and any other PHP service. A server keeps running the old, vulnerable code until it restarts.
• Running PHP 8.1 or older? The PHP project is not releasing fixes for these versions, so upgrade to a supported branch. Some vendors offer their own backported fixes, so ask yours.
• Never run random proof-of-concept (PoC) code from the internet. Fake exploit code is already circulating, so test only in an isolated lab, if at all.
• On shared hosting? Ask your hosting provider to patch.

How the RCE Exploit Works

Think of a PHP worker as a hotel front desk that serves guests all day. Every guest (web request) is given a room (a block of memory) to keep their things in, such as form fields, uploaded files and variables. When the guest leaves, the room is cleaned and handed to the next guest.

PHP2Shell attacks that turnover. If something goes wrong halfway through a stay, the room is not reset properly. The next guest arrives, finds the leftovers, and PHP treats them as trustworthy. Security researchers call this a use-after-free flaw.

Where the danger is greatest

Servers running mod_php face the highest risk. The official PHP advisory notes that a single unauthenticated request can set off the attack there before the website’s own code has even started. In other words, the site’s code never gets a chance to defend itself.

CVE-2026-109618: breaking things at the right moment

Here, the attacker pushes PHP until it is nearly out of memory. Timing it carefully, they make a memory request fail while PHP is assembling an internal data structure. PHP sees the problem and cancels the job, so the structure is left unfinished.

The catch is that PHP’s tidy-up routine does not know the job was cancelled. It carries on as if the structure were complete, and so PHP ends up handling half-built memory as though it were a finished, valid object. This confusion is the foundation of the whole attack.

Getting the timing right is hard, because PHP has guardrails that stop one request from eating all the memory:

• post_max_size caps how large a submitted request can be.
• max_file_uploads caps how many files one request can carry.

The attackers found a loophole in the space between these two caps, and that is what lets them reach the out-of-memory moment on demand.

CVE-2026-109619: a pointer that outlives its data

PHP holds some information for as long as a worker is alive, and part of it is made of pointers, which are simply addresses that say where data is stored.

In this attack, the request is made to crash at a very specific instant: after PHP has released the request’s temporary memory, but before it has wiped the address pointing at it. The worker is now carrying a note that points to an empty room.

That empty room does not stay empty. When the attacker’s next request reaches the same worker, the memory behind that address can be refilled, this time with content the attacker chose. PHP still believes it is looking at trusted internal objects, which hands the attacker a stale pointer they can steer.

Let’s understand this with an example –

Suppose the dangling pointer holds the address ABCD123@.

• The attacker’s first request runs, and ABCD123@ holds normal, valid PHP data.
• The request finishes. PHP releases that memory, but the pointer is never cleared. This leftover pointer is the starting point.
• The attacker sends a second request designed to make PHP create lots of values about the same size as the old data. By shaping the request so its contents match that size, the attacker improves the odds that their data ends up sitting at ABCD123@. This memory-shaping trick is called heap grooming.

When PHP later follows the old pointer, it has no clue that the memory was released and reused by something else.

Fooling PHP About What Data Is

PHP stores each value in a container called a zval, which has two parts: the value itself and a label saying what type of value it is. PHP believes the label and processes the memory accordingly. If an attacker controls both parts, they can put in any content and attach any label, and PHP will go along with it.

Used cleverly, a false label can make PHP read and reveal memory from its own process. That matters because modern operating systems use ASLR (Address Space Layout Randomization), a defense that shuffles where things are placed in memory so attackers cannot guess locations. A memory leak undoes that shuffle. Once the attacker can see where key items are stored, they can rebuild the memory map of the process, which is the knowledge needed to turn the bug into a working exploit.

PHP2Shell Impact

If an attacker successfully exploits PHP2Shell, three things can go wrong:

Full takeover: the attacker can run any command they like on your server, which means they are effectively in control of it.

Data leak: the contents of PHP’s memory can be exposed. That memory may hold passwords, tokens and API keys, even when the attacker never gets to run code.

Server crashes: repeated attempts can knock PHP workers over and bring servers down.

What CERT-In and PHP Said

CERT-In and the PHP project both rate PHP2Shell as critical and tell organizations to update immediately. Any PHP version below 8.2.35, 8.3.36, 8.4.27 or 8.5.12 on its branch is vulnerable, and PHP 8.1 and older no longer get fixes from the PHP project.

CERT-In published Vulnerability Note CIVN-2026-0510 on October 21, 2026, rating it Critical. It warns that a remote attacker can run arbitrary code on a target system by sending a specially crafted request, which could lead to full system compromise. The note names all organizations and individuals using PHP as its audience, and the root causes as memory corruption and improper resource control.

For Older PHP versions

• Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
• PHP 8.1 and older get no updates from the PHP project. Some vendors provide backported fixes, so ask yours, or move to a supported version.
• For teams building from source, the PHP security team published minimal backports for PHP 7.4, 8.0 and 8.1.
• If you rely on the volunteer-run rpms.remirepo.net repository, the PHP project urges you to switch to distribution packages or build from source. That repository would not have updates on release day.

Official Stopgaps If You Cannot Update

These measures only reduce exposure to specific attack paths. They do not make an installation safe.

CVE-2026-109618 (memory exhaustion)

• Set memory_limit=-1 where apps can’t override it. Real allocation failures can still reach the bug.
• Use a low post_max_size (8M without uploads, 32M with), and cap request size and structure at the web server or proxy.
• Use container or cgroup limits, not RLIMIT_AS or RLIMIT_DATA.

CVE-2026-109619 (stale state)

• Set session.upload_progress.enabled=0 in php.ini or server config and restart workers. It blocks only the confirmed paths.
• On PHP 8.5, set fatal_error_backtraces=0 and restart.
• Remove settings that emit early diagnostics. Hiding the messages doesn’t help.
• Fix reachable fatal errors and timeouts.

Found PHP2Shell on Your Servers? Here’s Your Patch-and-Hunt Playbook

Patching is the only complete fix for PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Upgrade to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or later), restart every process that runs PHP, then check whether attackers got in first. Your own code can be clean and you can still be exposed, because the flaw is in PHP itself.

Step 1: Find every PHP runtime

The hard part is knowing where PHP runs. Check:

• Hosting panels, phpMyAdmin and webmail on non-standard ports
• Hidden versions (confirm with php -v and php-fpm -v)
• Containers and CI images, which may still run old PHP
• Appliances and control panels with bundled PHP

Step 2: Patch in order

• Start with Apache mod_php hosts, the highest risk.
• On PHP 8.1 or older, move to a supported branch.
• Rebuild containers with –pull –no-cache.
• Restart Apache, PHP-FPM, LiteSpeed and queue workers.
• Review memory_limit and post_max_size afterward.

If you can’t patch today

Take servers off the public internet. Disabling opcache and session.upload_progress helps a little but is not a fix. Use a WAF and least privilege.

Detection

Watch for odd multipart requests, repeated HTTP 500 errors, oversized PHPSESSID cookies, worker crashes, and unexpected child processes or outbound connections.

If exposed before patching

Assume memory secrets leaked. Rotate database passwords, API keys and session signing keys. Run public exploit code only in an isolated lab.

After Patching: Close the Gaps PHP2Shell Can Still Slip Through

The hardest PHP to find sits inside third-party products: hosting control panels, network appliances, monitoring tools, helpdesk software, and CMS or LAMP stack images. You often can’t patch these yourself, so watch vendor advisories and update as soon as fixes arrive. The Dutch NCSC’s PHP dependency inventory can help identify affected products.

The cloud needs attention too. Google App Engine Standard (PHP 8.2+) and Cloud Run with base image updates enabled can update automatically, but custom container images cannot. Rebuild them on a patched PHP version and redeploy, whichever cloud you use.

Patching is the priority, but also run web application penetration testing, restrict access privileges, segment networks, improve monitoring, and keep an accurate PHP inventory. The CERT-In advisory shows that one flaw can hit many services at once, so regular VAPT helps find overlooked systems, validate controls and prioritise fixes.

PHP2Shell FAQs