Skip to content
← All posts
10 min read

php2shell: Two Critical PHP Flaws and the 10-Minute Fix

Two critical PHP RCE flaws (CVE-2026-109618, CVE-2026-109619) hit every PHP version since 5.4. Here is how I check a server and patch it in minutes.

php2shell: Two Critical PHP Flaws and the 10-Minute Fix
Watch: php2shell: Two Critical PHP Flaws and the 10-Minute Fix

php2shell: Two Critical PHP Flaws and the 10-Minute Fix

Two flaws in PHP itself, not in your app, let an attacker run code on your server without a password. I spent the morning checking what is actually confirmed, and this post is the result: how to tell if you are exposed in ten seconds, the exact patch sequence, and the stopgaps that only half-work if you cannot patch today.

What actually happened

Two vulnerabilities in PHP core were disclosed on October 21, 2026, and researchers nicknamed the pair php2shell. CVE-2026-109618 corrupts memory when PHP runs out of it mid-request. CVE-2026-109619 is a use-after-free: a PHP worker keeps global state pointing at memory owned by a finished request, and a later request on the same worker can be tricked into using it. Both carry a CVSS v4.0 score of 9.2 from the PHP project.

One correction before anything else, because the wrong number is everywhere: when the CVE IDs leaked on October 20, they traveled with a score of 10.0 attached. That figure was wrong. The official score is 9.2 for both bugs. Still critical, still drop-everything, just not the leaked ten.

The timeline matters for how much you should trust the calm voices. Wiz Research found the first bug on August 19, 2026, using frontier AI models as part of the hunt, and reported it to PHP on August 24. Calif found a critical flaw too, through OpenAI's Patch the Planet program. The patched releases were scheduled for October 22, then moved up to October 21 after the leak. Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Am I affected? The honest matrix

If your site serves PHP on the web, you are in scope. That covers PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Wiz and Cloudflare both state that every PHP version from 5.4 onward is affected by at least one of the two flaws. CLI-only PHP (cron scripts, command-line tools) does not expose these paths.

Your setup decides how urgent this is:

SetupRiskWhy
Apache mod_phpHighestFull unauthenticated RCE validated over HTTP with default limits, triggered during request body parsing, before any application code runs
PHP-FPMExposed, harderFPM design blocks the most direct path for CVE-2026-109618 and no complete FPM exploit has been demonstrated for it, but the session path for CVE-2026-109619 was validated against a normal FPM pool
FrankenPHPLikely highSource analysis says it calls request shutdown unconditionally, like mod_php
LiteSpeed (LSAPI)Likely, unvalidatedModels FPM; application-specific exploitation is likely but not demonstrated
CLI onlyOut of scopeThese paths need web requests

WordPress, Drupal, Joomla, Laravel: read this part twice. The flaw sits underneath your application. Wiz demonstrated unauthenticated RCE against the current WordPress, Drupal and Joomla container images. Updating WordPress core, your theme and every plugin changes nothing here. Only the server's PHP update fixes it.

The scale is the story. W3Techs put PHP at 69.3% of all websites whose server-side language is known, checked October 22. Of PHP sites, 26.9% run PHP 7 and 7.7% run PHP 5, branches with no official fix coming. If you maintain client sites for a living, some of them are almost certainly in that group, and an emergency version audit is billable, legitimate work this week. My contact section is how clients reach me for exactly this kind of check.

Check your version in 10 seconds

Run one command and compare one line. That is the entire test.

  1. Get the running version

    With shell access: php -v. The first line is your version. On the web side, use a temporary phpinfo page and delete it afterwards, or read the version from your hosting panel. WordPress without shell access: Dashboard, Tools, Site Health, Info tab, PHP version row.

  2. Compare against the fixed list

    Your branch is patched at or above: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Below your branch's number, you are vulnerable. On 7.4, 8.0 or 8.1, there is no official fixed release at all; you are looking for a vendor backport. On 5.x or early 7.x, there is no fix path.

  3. Write down what you found

    Note the branch and the exact version for every site you run or maintain. The next section assumes you know which of the three groups each site falls into: patchable branch, backport-only branch, or no-fix branch.

The fix, step by step

Update, restart, verify. Three moves, and the middle one is the one people skip.

  1. Update PHP to your branch's fixed release

    Install 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or your distro or vendor build carrying the same fix. It does not have to come from php.net directly; Ubuntu, Debian and the common PPA and panel builds shipped patched packages within a day of disclosure.

  2. Restart every PHP worker

    Restart the PHP-FPM service, or Apache if you run mod_php. This is not ceremony. Workers are long-lived processes holding the old, vulnerable code in memory. Patch the files and skip the restart, and the running workers keep serving the vulnerable code until they recycle. You would be exactly as exposed as before, and you would feel safer, which is worse.

  3. Verify the running version

    Run php -v again after the restart and read the number out loud. Patched, restarted, verified: that is the whole job. On most servers it takes about ten minutes.

On shared or managed hosting, your host holds the patch. Your job is the check above plus one question to support: are we patched for php2shell? Real hosts moved fast this week. InMotion Hosting disabled the session upload progress setting fleet-wide on October 20 as a precaution, then rolled out patched builds. Wordify patched its whole platform on October 21, including source backports for 7.4 to 8.1. If your host cannot answer the question, that is information too. It is the same calculation I walk through in my Vercel vs VPS hosting cost breakdown: cheap hosting gets expensive the day you need someone competent at 2 AM.

Cannot patch today? Stopgaps, honestly labeled

PHP is explicit: updating is the only complete mitigation. Each item below is partial, and I am labeling them the way the advisories do.

  • session.upload_progress.enabled=0 in php.ini or the FPM pool, then restart workers. This blocks the demonstrated session producer and consumer paths for CVE-2026-109619. Do not set it in .user.ini or with ini_set(); those apply too late.
  • PHP 8.5 only: fatal_error_backtraces=0, set administratively, then restart. This removes the producer in the confirmed mod_php exploitation case for CVE-2026-109619.
  • For CVE-2026-109618, the advisory discusses enforcing memory_limit=-1 at the administrative level to remove the predictable per-request limit the confirmed exploit uses. Partial only: a genuine allocation failure underneath can still reach the vulnerable path. Do not use RLIMIT_AS or RLIMIT_DATA; they make memory mapping fail at the limit and trigger exactly the vulnerable path.
  • pm.max_requests=1 shrinks the same-worker window for CVE-2026-109619, at a real performance cost.
  • If your app does not use multipart forms, blocking multipart requests at the frontend closes a lot of surface.
  • Cloudflare put WAF protections live by default on October 21 at 03:02 UTC, on free and paid plans. Useful defense in depth. Cloudflare itself says patching is still required, and so do I.
  • If you cannot remediate an internet-facing mod_php system at all, NCSC UK's advice was to consider taking it offline until it can be fixed.

Were you already probed? A 60-second log check

Beazley Security's advisory (BSL-A1233) lists the signs, and Datadog's detection notes line up with them:

  • Unusual POST or multipart/form-data requests, including to endpoints that never accept uploads; excessive fields or headers; missing or malformed content lengths; deeply nested field names; references to PHP_SESSION_UPLOAD_PROGRESS in request bodies; bursts of HTTP 500s after such requests.
  • Unexpectedly large or malformed PHPSESSID response cookies. Wiz flags this as a sign of the memory disclosure path, the quieter attack where worker memory (passwords, tokens, API keys, certificates from other requests) gets read without code execution.
  • PHP and FPM logs full of memory-limit fatals, timeouts, worker crashes and unexplained worker churn near the suspicious traffic.
  • Child processes spawned by PHP or web server workers, changed web files or cron entries, unusual outbound connections.

If that shape shows up in your logs: preserve the logs before you restart anything, patch, and then rotate the secrets your PHP workers could read. Database passwords, API keys, session secrets. The memory disclosure path means "probably fine" is not a standard worth using.

What is confirmed, and what is still hype

I am keeping this section separate on purpose, because this story is being inflated in real time.

Confirmed: attack attempts. Cloudflare states it observed attack traffic targeting its customers, saw attackers mutating payloads to evade rules, and had WAF protections live hours before public disclosure. watchTowr honeypots reported attempts too, and the SANS Internet Storm Center raised its InfoCon to yellow. Working exploits exist in researcher hands: Datadog says it built exploits before disclosure and reproduced CVE-2026-109618 on PHP 8.5.11 with a single unauthenticated POST, and Rapid7 reports achieving RCE against both mod_php and FPM through different paths during research.

Not confirmed: mass successful breaches. As of writing, no widespread confirmed compromises of major targets have been publicly detailed, and the Dutch NCSC reported no confirmed abuse. Demo videos and unverified proof-of-concept repositories are circulating; a verified public exploit had not been confirmed at the time of writing. Some vendors have asserted in-the-wild exploitation without publishing evidence. I am going with the confirmed record: attempts yes, verified breaches not yet. I also checked CISA's Known Exploited Vulnerabilities catalog (release dated October 21, 2026, checked October 22): neither CVE is listed yet. That status can change; the attempts are reason enough to patch today.

Governments are not waiting for certainty. Dutch services including DigiD, MijnOverheid and the House of Representatives site went offline as a precaution. Japanese services ran emergency maintenance. NCSC UK advises patching immediately and considering going offline where remediation is not feasible, and the NSA urged updating or going offline.

My verdict: what I would do, in order

If you run one PHP site, do the ten-second check now and patch today. If mod_php is your setup, this jumps every queue you have, including mine. If you are on FPM, you patch today too; "harder to exploit" is a property of the exploit, not a property of your risk, and the session path was validated against FPM.

If you are stuck on 7.4, 8.0 or 8.1, find out today whether your vendor ships a backport. If the answer is no, the upgrade to 8.2 or newer stops being a someday project. And treat the stopgaps as a bridge measured in days, not a strategy: every one of them is partial, and the advisories say so in plain language.

The bigger picture is worth one honest paragraph. These bugs sat in PHP for over a decade. AI-assisted research found them in about a week of work. This time the models were pointed at defense, and the disclosure was coordinated and fast. The next set of eyes on old code may not be. Keeping your runtimes current is how you stay on the right side of that race, and it is the same discipline I push in my Next.js migration work: boring, regular, and much cheaper than the alternative.

FAQ

What is php2shell?

php2shell is the nickname researchers gave to two critical PHP core vulnerabilities disclosed on October 21, 2026: CVE-2026-109618 (RCE via out-of-memory corruption) and CVE-2026-109619 (RCE via stale global state). Both are rated CVSS 9.2 and can allow unauthenticated remote code execution.

Which PHP versions are affected by php2shell?

Every PHP version from 5.4 onward is affected by at least one of the two flaws, on any web setup: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. On supported branches, everything below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 is vulnerable.

How do I check my PHP version quickly?

With shell access, run php -v and compare the first line against the fixed versions: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Without shell access, WordPress shows it under Tools, Site Health, Info. Hosting panels usually list it under PHP settings.

What are the fixed PHP versions for php2shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026. Distro and vendor builds carrying the same fix are fine. After updating, restart every PHP worker (PHP-FPM or Apache) and verify the running version, because old workers keep the vulnerable code loaded.

I am on PHP 7.4, 8.0 or 8.1. Am I covered?

Not by an official release. Those branches are end of life. The PHP security team published minimal source backports that vendors and distros can package, so check whether your host ships a backported build. If not, moving to PHP 8.2 or newer is the real fix.

Is php2shell being exploited in the wild?

Attack attempts are confirmed: Cloudflare observed attack traffic against its customers from October 21 and watchTowr honeypots reported attempts. Confirmed successful mass breaches had not been publicly verified when this was written, and demo videos plus unverified proof-of-concept repos are circulating. Patch now rather than waiting for certainty.

Sources