Is Your PHP Patched? Why the FBI and Japan’s PM Warned About PHP2Shell
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.
Read in: EnglishاردوEspañolहिन्दीРусскийDeutschالعربية
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.
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.
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.
| Branch | Patched in | Notes |
|---|---|---|
| 8.5 | 8.5.12 | Current branch |
| 8.4 | 8.4.27 | Supported |
| 8.3 | 8.3.36 | Supported |
| 8.2 | 8.2.35 | End of life on December 31, 2026 |
| 8.1 and older | No official release | The 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 was reported | Policy shift (my read) |
|---|---|---|
| Patch on the monthly cycle | Attacks 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 list | PHP also ships inside control panels and appliances. | Inventory runtimes and bundled products, not just your own code. |
| Going offline is unthinkable | DPG 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 volunteers | The 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.
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 you see | What to do |
|---|---|
| At or above the patched version, processes restarted | Good. Keep watching logs for a few days. |
| Packaged PHP, version looks old | Read the changelog for the CVE IDs. If the fix isn't listed, update the package. |
| PHP 8.1 or older, no vendor backport | Move to a supported branch. Use PHP's published backports only as a short bridge. |
| Can't update today | Apply 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 hosting | Ask 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.
- 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 -mon 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.
- 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
- Follow the PHP project's announcements at php.net/archive/2026.
- Check CISA's Known Exploited Vulnerabilities catalog and the NVD entry for CVE-2026-109618.
- Run
composer auditin every project, and add it to CI so it fails builds on known-vulnerable dependencies. - Keep a written inventory of where PHP runs, who owns each system, and which SAPI it uses.
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.
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.
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.
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
- PHP project security announcements (php.net)
- FBI Cyber Division post on X
- Newsweek: FBI issues advice as security issue hits global websites
- Kaspersky: PHP2Shell, how to protect your server
- ITdaily: PHP2Shell actively exploited ahead of patch
- BleepingComputer: PHP warns admins of two critical flaws
- OfficeChai: Japan's Prime Minister and the FBI warn over PHP
- tech-ish: Japan's PM, the NSA and the FBI on PHP
- Simon Willison's live blog of Code w/ Claude 2026 for the multi-agent announcement
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
تبصرے
ایک تبصرہ شائع کریں