Is Your PHP Patched? Why the FBI and Japan’s PM Warned About PHP2Shell

PHP2Shell security graph: 69.3% of sites run PHP, 59% of hosts on PHP 8.1 or older, CVSS 9.2

Security guide · PHP · Updated October 25, 2026

Is Your Website Running a Vulnerable PHP Version? Why the FBI and Japan's Prime Minister Both Said to Check Today

Two critical flaws in PHP itself, nicknamed PHP2Shell, let an outsider run code on a server without logging in. This guide covers what happened, who is affected, how to check your own server in two minutes, and what to do if you can't patch today.

By Zubair Hussain, Full Stack Developer · · 16 min read · Video added October 25, 2026 · Facts last checked October 24, 2026

Read in: EnglishاردوEspañolहिन्दीРусскийDeutschالعربية

Is your PHP patched? PHP2Shell security guide A stack of three server units on the right with a red warning triangle on top. On the left, the headline Is your PHP patched and the two CVE numbers CVE-2026-109618 and CVE-2026-109619. SECURITY GUIDE · PHP2SHELL Is your PHP patched? CVE-2026-109618 · CVE-2026-109619 · CVSS 9.2 The 2-minute check, patched versions, safe test plan zubairhussain.xyz
Cover graphic, published October 24, 2026.
Do this first. On the machine that serves your site, run php -v (and php-fpm -v if you use FPM). You need 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a newer release in the same branch. Packages from a Linux distribution can keep the old version number after a backport, so read the package changelog. If you can't patch today, the FBI's advice was to take the system offline until you can.
69.3%of sites with a known server-side language use PHP (W3Techs, Oct 21)
9.2CVSS 4.0 score for each of the two flaws
0logins needed by an attacker, per PHP's advisory
59%of hosts that disclose a version ran PHP 8.1 or older (Mallory, Oct 20)

What happened, in order

PHP is the language behind WordPress, Drupal, Joomla, Magento and a large share of custom shops and dashboards. On October 20, the PHP project warned that it would ship an emergency security release the next day. It didn't publish details, but a leak made the date and the CVE numbers public ahead of the planned coordinated disclosure, and attackers had already started probing by the morning of October 21, before the fix existed.

The fix came out earlier than scheduled, around 13:35 UTC on October 21. The two bugs are tracked as CVE-2026-109618 and CVE-2026-109619, and the community nickname is PHP2Shell, a nod to Log4Shell.

PHP2Shell timeline, July to October 2026 Five steps. July 30: researchers begin scanning PHP. October 20: PHP pre-announces an emergency release, CERT-EU publishes an advisory and details leak. October 21 morning: first attacks seen by Cloudflare. October 21 at 13:35 UTC: patched versions released. October 21: FBI, NSA and UK NCSC warn and Japan's prime minister posts. Jul 30 Researchers startscanning PHP Oct 20 PHP pre-announces fix,CERT-EU advisory, leak Oct 21, morning First attacks seen(Cloudflare) Oct 21, 13:35 UTC Patched releasespublished Oct 21 FBI, NSA, NCSC warn,Japan's PM posts Not drawn to scale. Sources listed at the end of the article.
Attacks started before the patch was public. That gap is the whole story.

Which PHP versions are safe

According to the PHP project, releases before the ones below are vulnerable. Unofficial reports say the bugs reach back as far as PHP 5.4, which would mean old servers are exposed too.

Patched versions announced October 21, 2026
BranchPatched inNotes
8.58.5.12Current branch
8.48.4.27Supported
8.38.3.36Supported
8.28.2.35End of life on December 31, 2026
8.1 and olderNo official releaseThe project published minimal source backports for 7.4, 8.0 and 8.1. Distribution and long-term-support vendors may ship their own fixes. Otherwise, upgrade the branch.

The old-version problem is bigger than it sounds. Security firm Mallory counted roughly 884,000 internet-facing hosts advertising PHP 8.1 or older on October 20, which was 59% of the 1.5 million hosts that reveal a version at all.

Why the FBI, NSA, NCSC and Japan's PM all spoke up

Agencies don't normally post about a programming language. Four things made this one different:

  • It's the runtime, not an add-on. The flaw sits in PHP core, so a perfectly maintained WordPress install on an old PHP is still exposed. Vaisha Bernard of Eye Security put it bluntly: updating plugins won't solve this.
  • No login needed. PHP's own advisory describes unauthenticated remote code execution. For mod_php, the highest-risk setup, a single request can trigger it before any application code runs.
  • Scale. With roughly 70% of identifiable sites on PHP, even a small fraction of unpatched servers is a lot of targets, and many products bundle PHP quietly: control panels such as cPanel and Plesk, plus appliances.
  • Speed. Exploitation began before the fix was public. Cloudflare's CTO described its early firewall rules as a stopgap and told people to patch as soon as the release landed.

The FBI Cyber Division, on X, told organizations to update using the guidance on php.net and, if that wasn't possible right away, to take the system offline "until it can be fully mitigated." The NSA gave the same advice, and the UK's NCSC told anyone who couldn't apply PHP's interim fixes in time to consider the same. Japan's prime minister, Sanae Takaichi, posted on the evening of October 21 asking companies to find out whether their public websites run PHP and to be ready to apply the fix when it dropped at 11 PM Japan time. The FBI and the Japan Hacker Association both described the worst case as full server takeover: stolen, encrypted or destroyed data.

Why companies are changing their patch policies

This part mixes reported facts with my own reading, so I've separated them in the table. The middle column is what was reported. The right column is what I think it pushes companies toward.

Old habit, what happened this week, likely policy change
Old habitWhat was reportedPolicy shift (my read)
Patch on the monthly cycleAttacks appeared before the fix was public. ITdaily notes the window between disclosure and exploitation has shrunk from weeks to days, and now hours.Emergency path for internet-facing runtimes, measured in hours, with an on-call owner.
Old PHP "still works"59% of version-revealing hosts were on 8.1 or older, which gets no official fix.An unsupported runtime counts as an open incident, not a backlog item.
Inventory is the app listPHP also ships inside control panels and appliances.Inventory runtimes and bundled products, not just your own code.
Going offline is unthinkableDPG Media in Belgium took several sites offline. Brussels' VUB and several hospitals did too, and Belgium's national cyber centre put its own site in maintenance mode.A written, pre-approved "take it offline" runbook, with the business owner's sign-off in advance.
Rely on volunteersThe PHP Foundation said critical security work leans on volunteers and that it needs more funding for paid maintainers.Companies that run on PHP budget for upstream maintenance, not only for their own staff.

How PHP runs, and where the bug lives

A request passes through several layers before your page appears. Knowing the layers explains why plugin updates don't help and why the web server setup matters.

Request path through a PHP website, with the PHP2Shell layer marked Seven stacked layers: visitor, CDN or web application firewall, web server, PHP server API such as mod_php or PHP-FPM, the PHP runtime with its memory manager and request state where the two flaws sit, the application such as WordPress, and the database. Side notes: firewall rules are only a stopgap, mod_php is the highest risk setup, only patching fixes it, and logs should be watched for the web server user launching shells. Visitor or bot CDN and web application firewall Web server: Apache, Nginx, LiteSpeed PHP SAPI: mod_php, PHP-FPM, php-cgi, FrankenPHP PHP runtime (the Zend engine)memory manager · per-request state · the two flaws live here Your app: WordPress, Laravel, Magento Database Firewall rules help, butthey are only a stopgap. mod_php: the highest-risksetup per PHP's advisory. Only patching fixes this layer. Watch for the web userlaunching shells or curl.
The flaw is below your application. WordPress, Laravel and Magento all sit on top of it.

As described in PHP's advisories and in reporting by ITdaily and Kaspersky, one bug involves a memory shortage that interrupts PHP while a request's internal data is only half built, and PHP later treats that data as complete. The other leaves request state behind after the memory under it is freed, and a later request in the same worker process can touch it. Kaspersky also reports that one confirmed attack path uses the session.upload_progress feature, which is on by default. I'm deliberately not going further than that. The advisories and the patches are public, and the practical answer is the same either way: update.

Check your own server

Only run these on servers you own or are authorized to administer. Start with the machines facing the internet.

1. Find the version that actually serves web traffic

# The command line version (can differ from the web version)
php -v

# PHP-FPM (name varies by distro: php-fpm, php-fpm8.3, php8.3-fpm)
php-fpm -v

# Is Apache loading mod_php?
apachectl -M | grep -i php

# Which PHP processes are running, and as which user?
ps -eo pid,ppid,user,cmd | grep -E "php-fpm|apache2|httpd|frankenphp|lsphp" | grep -v grep

2. Don't trust the version number on a distro package

# Debian or Ubuntu
apt changelog php8.3-fpm | head -n 30

# RHEL, Rocky, Alma
rpm -q --changelog php | head -n 30

# After updating, reload so running processes pick up the new code
sudo systemctl restart php8.3-fpm   # adjust the unit name
sudo systemctl restart apache2      # or httpd / nginx as needed

3. A tiny PHP script that checks the branch rule

Save it as check-php-version.php and run it from the command line. It compares your version to the minimum patched release for the branch. It can't know about distro backports, so treat a "VULNERABLE" result as "go read the changelog" on a packaged install.

<?php
// check-php-version.php  |  run: php check-php-version.php
$fixed  = ['8.5' => '8.5.12', '8.4' => '8.4.27', '8.3' => '8.3.36', '8.2' => '8.2.35'];
$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;

echo 'Running PHP ' . PHP_VERSION . ' via ' . PHP_SAPI . PHP_EOL;

if (version_compare($branch, '8.2', '<')) {
    echo "No official fix for $branch. Ask your vendor for a backport or upgrade." . PHP_EOL;
    exit(2);
}
if (!isset($fixed[$branch])) {
    echo "Branch $branch is not in this list. Check php.net/archive/2026.php." . PHP_EOL;
    exit(3);
}
if (version_compare(PHP_VERSION, $fixed[$branch], '>=')) {
    echo "OK: at or above {$fixed[$branch]}." . PHP_EOL;
    exit(0);
}
echo "VULNERABLE: update to at least {$fixed[$branch]}." . PHP_EOL;
exit(1);

4. Look for signs it already happened

Kaspersky suggests reviewing logs from October 20 onward. The warning sign is the web server process doing things a web server shouldn't: starting shells, running curl or wget. The FBI says that if you find signs of compromise, isolate the system, keep server and PHP logs, and report to an FBI field office or ic3.gov.

# Children of the web server or PHP-FPM that look like shells or downloaders
ps -eo pid,ppid,user,comm --forest | grep -E "www-data|apache|nginx" | grep -E "sh|bash|dash|curl|wget"

# Recently changed PHP files under your web root (last 3 days)
find /var/www -type f -name "*.php" -mtime -3 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort | tail -n 40

Neither command proves you're clean. They're a first pass before a proper review.

What your result means
What you seeWhat to do
At or above the patched version, processes restartedGood. Keep watching logs for a few days.
Packaged PHP, version looks oldRead the changelog for the CVE IDs. If the fix isn't listed, update the package.
PHP 8.1 or older, no vendor backportMove to a supported branch. Use PHP's published backports only as a short bridge.
Can't update todayApply PHP's interim mitigations from php.net/archive/2026.php. Remember they reduce risk and don't fix it. The FBI's advice is to take the system offline.
Shared hostingAsk your host to confirm in writing that the patched release is live.

Test the patch safely

The urge to patch production immediately is right in this case, but a rushed update that breaks checkout is its own bad day. The pipeline below keeps both goals.

Safe patch pipeline for a PHP site Six steps in a row: inventory every PHP runtime, staging with the same SAPI and extensions, automated and smoke tests, canary on a small share of traffic, production, then verify the version and watch the logs. A rollback arrow returns from canary to staging. 1. Inventoryevery PHP runtime 2. Stagingsame SAPI + modules 3. Testssuite + smoke flows 4. Canarysmall traffic share 5. Productionrolling restart 6. Verifyversion + logs rollback if error rate or memory climbs
Same steps whether you run one VPS or a fleet.
  • Match the real setup. Staging should use the same SAPI (FPM or mod_php), the same extensions and the same memory limits as production. php -m on both, then diff the output.
  • Run the test suite, then click through the money paths. Login, checkout, search and anything that handles file uploads.
  • Watch memory. Because one flaw involves out-of-memory handling, look at memory use and error rates under load after the update.
  • Verify the web version, not only the CLI. If you must expose version info for the check, do it on a temporary, access-restricted page and remove it afterward. A public phpinfo page is a gift to attackers.
  • Have a rollback. Keep the previous package available, but don't roll back to a vulnerable release for longer than you have to.

How researchers find bugs like this

People often ask how anyone finds a flaw in something as mature as PHP. In practice it's a mix of methods, mostly aimed at the C code underneath the language.

How a vulnerability goes from discovery to patch Four discovery methods on the left: manual code review, fuzzing with memory sanitizers, static analysis, and AI-assisted scanning. They feed one chain: reproduce and minimize, report privately to maintainers, fix with a CVE and a coordinated date, release and advisories, defenders patch. Manual code reviewFuzzing + sanitizersStatic analysisAI-assisted scanning Reproduce andminimize Report privately to maintainersFix, CVE, coordinated dateRelease + public advisoriesDefenders patch quickly
PHP2Shell broke the third step: details leaked before the coordinated date.
  • Code review. Reading the memory-handling and request-lifecycle code paths with failure cases in mind, such as "what if allocation fails halfway through?"
  • Fuzzing with sanitizers. Feeding huge amounts of malformed or extreme input, including low-memory conditions, while tools like AddressSanitizer flag illegal memory access.
  • Static analysis. Tools that scan source for patterns that tend to lead to bugs.
  • AI-assisted scanning. A spokesperson for security startup Calif told Newsweek that it began scanning PHP on July 30 as part of OpenAI's Patch the Planet initiative and found the flaws within days, then contacted the PHP Foundation. Google Cloud said Wiz Research used several AI models across discovery, patch validation and detection. Newsweek reports OpenAI saying Calif used its GPT-5.6 Sol model to find one flaw, while Wiz independently found and reported both.

The responsible path ends with a private report and a coordinated release. Attackers use the same tools, and ITdaily's point is that AI can shrink the time between a patch landing and someone working out the flaw from it. That's why "patch within hours" is becoming the standard for internet-facing runtimes.

How site owners find out about problems like this

A web-app flaw for comparison

PHP2Shell is a runtime bug, so it's different from the mistakes developers make in their own code. Here's the classic one, SQL injection, so you can see the difference. This is a teaching example for code you own. Only test systems you're authorized to test.

<?php
// Risky: user input is pasted straight into the query
$id  = $_GET['id'];
$sql = "SELECT name, price FROM products WHERE id = $id";
$rows = $pdo->query($sql)->fetchAll();

A request like ?id=5 OR 1=1 changes what the query means, and in your access logs, injection probing often shows up as odd quotes, UNION or OR 1=1 in query strings. The fix is to keep data and SQL separate:

<?php
// Safer: a prepared statement with a typed parameter
$id   = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if ($id === false || $id === null) { http_response_code(400); exit; }

$stmt = $pdo->prepare('SELECT name, price FROM products WHERE id = :id');
$stmt->execute([':id' => $id]);
$rows = $stmt->fetchAll();

The lesson: fixing your own code doesn't cover runtime bugs, and patching the runtime doesn't cover your own code. You need both habits.

Using multiple Claude agents for the boring parts

An emergency like this is mostly repetitive work across many machines and repos, which is the kind of job that splits well between several AI agents. Anthropic's Claude Managed Agents added multi-agent orchestration, where a lead agent hands parts of a task to specialist agents, at its Code with Claude event in May 2026, and a public beta was reported later. Anthropic also announced Claude Code Security in February 2026 as a research preview for finding and fixing vulnerabilities in a codebase. Features and availability change, so check Anthropic's current docs before you plan around them.

Illustration: a multi-agent PHP patch review with a human approving changes A lead agent splits the job among three read-only specialist agents: an inventory agent that lists PHP versions per host, a dependency agent that runs composer audit across repositories, and a log agent that flags web server processes launching shells. They return findings to a report that a human reviews before any change is made. Lead agent: plan + merge Inventory agentPHP version + SAPI per hostread-only Dependency agentcomposer audit per reporead-only Log agentweb user launching shells?read-only Human reviews, then approves changes Illustration of a workflow. Not an Anthropic template.
My sketch of a sensible split. The key rule: agents read and report, people approve changes.

I'd give each specialist read-only access, because the cost of an agent running the wrong command on a production server is far higher than the time saved. Let them gather and summarize. Make a person approve every restart, package change and rollback.

Where the warnings came from

Japan was one of the loudest voices: the Prime Minister made a rare direct appeal to businesses on X. Here's the Prime Minister's Office in Tokyo, for context.

Prefer Blogger's own widget? In Compose view, use the Map icon on the toolbar to embed place details, opening hours, photos and reviews.

Video walkthrough

YouTube · Video walkthrough

PHP2Shell Explained: How to Check Your PHP Server in 10 Minutes (CVE-2026-109618 and CVE-2026-109619)

A screen walkthrough of the commands in this guide, the patched versions and the log checks.

Watch on YouTube →

Learn PHP security properly

I keep a growing reference with PHP concepts, coding terms, common vulnerabilities and practice exercises. It's the place to go if you want to understand the vocabulary used in this article, like SAPI, use-after-free, prepared statements and CVSS.

Open the PHP Master Guide on Notion →

FAQ

Is PHP2Shell only a WordPress problem?

No. The flaw is in PHP, so any application on a vulnerable PHP version is exposed: WordPress, Drupal, Joomla, Magento, Laravel and custom code.

I'm behind Cloudflare. Am I safe?

Not fully. Cloudflare released firewall rules for known attack patterns, including on free plans, but its own CTO called them a stopgap. Patch the runtime.

Is php -v enough to check?

It's a start. The command-line PHP can differ from the PHP your web server uses, and packaged installs can carry a fix under an old version number. Check the web SAPI and the changelog.

Do I really need to take the site offline?

The FBI and NSA recommend it only if you can't update right away. If you can patch within hours, patch. If you can't, weigh the cost of downtime against a possible server takeover.

I'm on PHP 8.1 or older. What now?

The PHP project has no official release for you. Ask your distribution or long-term-support vendor about a backport, or move to a supported branch. PHP also published minimal source backports for 7.4, 8.0 and 8.1 as a short-term bridge.

Sources and what I couldn't verify

Limits of this article. This is a fast-moving story. Reports differed on whether CISA had added the CVEs to its Known Exploited Vulnerabilities catalog when I checked, so look at the catalog yourself. Which AI model found which flaw comes from company statements as reported by Newsweek, and I haven't confirmed them independently. One outlet misspelled the Prime Minister's name, so I used the spelling from her own post and from other coverage. The exact interim mitigations are on php.net and I didn't repeat them, so you don't copy a version that may have been updated.

Need a hand checking or patching a PHP site?

I'm Zubair Hussain, a Full Stack Developer working on eCommerce sites, Next.js apps and client web projects, including speed fixes and bug fixes. If you're stuck, write to me and we'll sort it out.

Email zubair@zubairhussain.com Book a call

This guide on my portfolio · PHP Master Guide (Notion)

تبصرے

اس بلاگ سے مقبول پوسٹس

Claude 5 Explained: Fable 5.1 vs Opus 5 vs Sonnet 5 Features, Pricing & Best Model in 2026

GTA 6 Map Leak Explained: Vice City, Leonida, CyberLeek Claims & What’s Confirmed

Explore - IT