AI found a decade-old hole in PHP. The PHP security vulnerability you need to patch today

Keep the visible “Last updated” date accurate. This story is moving daily, and freshness is a ranking and trust signal for news-led queries.

On 21 October 2026, the PHP project put out a message every PHP user needed to read: “All PHP users are strongly encouraged to update immediately.” There is no complete workaround.

The reason is PHP2Shell, a pair of critical bugs in the PHP engine itself. They let an attacker run code on a web server without a password and without touching your application code. PHP runs on 69.3% of websites whose server language is known. Security researcher Kevin Beaumont put it plainly: “it’s one of the biggest vulns in years.”

This guide explains what broke, how the attack works, and what to do about it today, this week, and this quarter. Every technical claim below links back to PHP’s own advisories or to the researchers and agencies who worked on the response.

PHP2Shell in 60 seconds

• What: two critical flaws, CVE-2026-109618 and CVE-2026-109619, each rated CVSS v4.0 9.2.
• Impact: unauthenticated remote code execution on the web server.
• Who: every PHP installation that serves web requests, with the highest risk on Apache mod_php.
• Fix: update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. PHP says there are no complete workarounds.
• Urgency: Amazon saw an exploitation attempt on 17 October, four days before the fix. It now reports broad exploitation in the wild.

What is PHP2Shell?

PHP2Shell is the name given to two memory safety bugs in the PHP interpreter, the program that actually runs your PHP code. Because the bugs live in the engine, a clean, well-written application is exposed just the same. Patchstack notes that Wiz showed code execution against the latest WordPress container image, with no plugin at fault.

PHP’s security advisory says the risk covers “all PHP installations serving web requests”. That includes:

On versions, the fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Anything below those on a supported branch is vulnerable. Wiz, whose researchers found the bugs, says the flawed code goes back to PHP 5.4 and has been present for more than a decade.

That last point matters more than it looks. W3Techs data shows 34.7% of PHP websites still run PHP 7.x or older. The PHP project no longer supports any of them.

How the two PHP security vulnerabilities work, in plain English

Both bugs come from the same idea: PHP gets interrupted at a bad moment and leaves its memory in a mess that an attacker can then use.

CVE-2026-109618: the out-of-memory crash

When PHP runs out of memory, it bails out of the request with a low-level jump (longjmp()). PHP’s advisory explains that if this happens while the request is only half set up, the cleanup code then trusts data that was never properly built.

The attacker’s job is to cause that out-of-memory moment on purpose. The advisory lists several ways a crafted multipart form upload can do it while appearing to stay inside PHP’s limits: a missing content length, unlimited headers per part, empty file fields that slip past max_file_uploads, and deeply nested field names that multiply the work.

The confirmed result is code execution as the web server user, tested over HTTP against Apache mod_php with default settings. PHP’s fix removes the jump entirely. PHP now stops at the next safe point instead, with a hard exit if memory keeps climbing.

CVE-2026-109619: memory that outlives its request

A PHP worker handles many requests, one after another. The second advisory shows that some global state (error, session, object and extension data) can keep pointing at memory from a request that has already finished and been freed.

A fatal error, an out-of-memory event, or a timeout can interrupt the reset that should wipe this state. The next request on the same worker can then read the stale pointer before normal startup cleans it. That is a classic use-after-free. With careful control of the memory layout, it becomes remote code execution. The two confirmed paths run through INI warnings raised early in a request and through session upload progress handling.

Put simply, the first bug breaks the house, and the second lets the next visitor walk in through the wreckage.

Timeline: attackers moved before the patch did

The usual playbook is simple: a fix ships, then attackers study it. PHP2Shell broke that order.

Amazon’s conclusion is the line every IT leader should pin to the wall: “For critical vulnerabilities in internet-facing systems, measure patch and mitigation timelines in hours.” It now describes PHP2Shell as “broadly exploited in the wild”.

Why PHP2Shell is different

Critical PHP bugs are not new. Three things make this one a turning point.

1. AI turned an old flaw into a working exploit

The Wiz team was blunt about how this happened. The flaws had been sitting in PHP for years, they told Help Net Security, but proving they could be exploited took “an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier.”

Wiz says its researcher used AI models to find the bugs, build and adapt the exploit across PHP versions, and validate the patch. One person did in a week what “previously would have taken a world-class team months.” Raluca Ada Popa, Head of Gemini Security at Google DeepMind, called frontier AI “a game-changer for cyber defense.”

The uncomfortable corollary: the same tools are available to attackers. Code that has been “safe enough” for ten years now faces a much more patient and much faster reviewer.

2. Your code review never looked here

Most security budgets go to the application: code reviews, dependency scans, penetration tests. PHP2Shell sits one layer below all of that, in the runtime. An exploit fires during request parsing, before your first line of code runs. Wiz warns that application logs “may contain little context” for exactly this reason.

3. The long tail will last for years

Patching a supported server is quick. The danger is everything else: old PHP 7 sites, forgotten staging servers, appliances and vendor products that bundle PHP quietly. Forensics expert Hal Pomeranz summed it up: “So many embedded installations out there that will never be patched. Too many forgotten, unmaintained apps. There will be a long tail for this one.”

With a third of PHP websites still on 7.x or older, that tail is long indeed.

How to fix PHP2Shell, step by step

PHP’s release notes are clear: “There are no complete mitigations, updating is the only safe choice.” Here is how to do it properly.

1. Find every PHP runtime you own. Start with internet-facing servers, then staging, containers, internal tools, and vendor appliances. The NCSC stresses that discovery should cover all versions, not only old ones.
2. Check the version the web server actually uses. php -v shows the command-line build, which can differ from the one serving pages. Check php-fpm -v, your Apache module, or a temporary phpinfo() page that you delete straight after.
3. Update to a fixed release.

4. Use the right channel. Linux distributions and LTS vendors received the patches in advance, so their packages may carry the fix under their own version numbers. Check your vendor’s advisory. If you use the volunteer run rpms.remirepo.net, PHP advises switching to distribution packages or building from source, as that repository had no update on release day.
5. Rebuild containers. A patched host does nothing for an old image. Pull fresh base images, rebuild and redeploy, and check what is running in production, not just what is in the registry.
6. Restart every worker. A new binary on disk is not a patch until Apache, PHP-FPM, or your app server has been restarted. It is an easy step to miss.
7. Ask your host and SaaS vendors. If you are on shared hosting or a managed platform, ask in writing whether they run a fixed build. Vendor products that bundle PHP need their own updates.

On PHP 8.1 or older? The PHP project no longer supports these versions. Given the severity, it published minimal source backports for 7.4, 8.0, and 8.1 for people who build from source. Treat that as a lifeline, not a plan. PHP 8.2 itself reaches end of life on 31 December 2026, so the real fix is a supported branch.

Cannot patch today? Buy time, then hunt

PHP has published interim settings, and it is honest about them: they “do not make an installation safe.” Use them only to bridge the gap to an update.

; php.ini or FPM pool (applies before request parsing) 
session.upload_progress.enabled = 0 
post_max_size = 8M          ; or 32M if uploads are required 
upload_max_filesize = 8M    ; must stay below post_max_size 
; PHP 8.5 only 
fatal_error_backtraces = 0 

; PHP-FPM pool, so applications cannot override it
php_admin_value[memory_limit] = -1

; php.ini or FPM pool (applies before request parsing) 
session.upload_progress.enabled = 0 
post_max_size = 8M          ; or 32M if uploads are required 
upload_max_filesize = 8M    ; must stay below post_max_size 
; PHP 8.5 only 
fatal_error_backtraces = 0 

; PHP-FPM pool, so applications cannot override it
php_admin_value[memory_limit] = -1

A few rules from PHP’s guidance that people get wrong:

• Set these in php.ini, the FPM pool, or server config. ini_set() and .user.ini files are too late.
• Restart every worker afterward.
• Do not use RLIMIT_AS or RLIMIT_DATA as a memory cap. A container or cgroup limit is the safer option.
• Fix fatal errors and timeouts that attackers can trigger, rather than hiding them.

Other ways to shrink the attack surface:

• Block multipart uploads at the proxy if your application does not use them. AWS suggests this too, after you check the impact.
• Turn on WAF rules. Cloudflare, Fastly, Vercel and others shipped protections. They only help if your origin refuses traffic that bypasses the WAF.
• Take it offline. If none of this is possible, the NCSC advises considering taking the system offline until it is fixed.

How to tell if you were hit

AWS’s advice is to start your investigation from the earliest known exploitation, 17 October, not from the disclosure date. Look for:

• POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS
• unusual multipart requests followed by memory limit errors or bursts of HTTP 500 responses
• unexpectedly large or malformed PHPSESSID cookies in responses
• PHP workers restarting with no clear reason
• unexpected processes or file changes on web servers

If a server was exposed and unpatched, treat it as possibly compromised. The bugs can leak process memory, so rotate the credentials it held: database passwords, API keys, and session secrets. AWS has published indicator IP addresses, but notes they belong to shared anonymization services, so use them to investigate rather than as a block list.

What PHP2Shell should change in how you run software

The patch closes two CVEs. It does not close the gap PHP2Shell exposed. Four lessons are worth taking into your next leadership meeting.

Know what you run. You cannot patch a server you do not know exists. A live inventory of runtimes, versions, and owners is now basic hygiene, not a nice-to-have.

Measure patching in hours. Many patch policies still allow days or weeks for critical fixes. Here, attackers had a working exploit before the patch existed. If your honest answer to “how fast can we ship a runtime fix?” is weeks, that is the real finding.

Retire end-of-life software on purpose. Every PHP 7 site is a bet that nothing this serious will happen again. Budget the upgrade before an incident forces it, and remember PHP 8.2 joins that list on 31 December 2026.

Hold vendors to the same bar. Your exposure includes your agency’s hosting, your SaaS tools, and the appliances in your rack. Ask them the same questions you ask your own team, and ask for the answer in writing.

Sources

Primary sources from the PHP project:

• PHP news archive 2026: pre-announcement, security advisory and release notes
• GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
• PHP supported versions

Researchers, agencies and industry:

• Wiz Research: PHP2Shell
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure
• UK NCSC: critical security issue affecting PHP
• Help Net Security: PHP2Shell patched, update now
• Patchstack: PHP vulnerable to critical RCE
• W3Techs: usage statistics of PHP