CVE-2026-109618: Check Your PHP Version Today

On October 21, 2026, PHP shipped an emergency security release for two critical remote-code-execution (RCE) flaws in PHP core: CVE-2026-109618 and CVE-2026-109619, together nicknamed "php2shell." Both are rated CVSS v4.0 9.2 (Critical) by the PHP security team. If you run Laravel, WordPress, Symfony, or plain PHP and don't know which PHP version your server runs, check it now and apply the October 21 release.

The flaws were supposed to be disclosed under embargo on October 22. Technical details leaked the day before, so the PHP security team pulled the release forward to October 21, 2026 at 14:00 UTC.

Does this affect you?

The short version: if you run a maintained branch (8.2–8.5), update today. If you run PHP 8.1 or older, you will not get an official fix — you need to move to a supported version.

What actually happened

The timeline, in order:

• October 20, ~15:20 UTC — a Hacker News post reports two upcoming PHP RCE disclosures before the embargo lifts.
• October 20 — PHP confirms a critical security release is coming. Security firm watchTowr confirms the leak is real.
• October 21, 14:00 UTC — PHP publishes the out-of-band release.

The nickname "php2shell" comes from an exploit tool named PHP2Shell, credited to Calif.IO. A screenshot of that tool leaked alongside the advisory. Its banner claims it works against every PHP release from 5.4.0 onward — but that claim is unverified. watchTowr reproduced CVE-2026-109618 in a lab. Huntress reported no in-the-wild exploitation at the time of writing, and the flaws are not on CISA's Known Exploited Vulnerabilities (KEV) catalog yet.

That "not exploited yet" window is exactly why you should move today. The patch tells attackers where to look, so researchers expect attacks to start shortly after release.

What the vulnerability is

Remote code execution means an attacker who can reach your PHP application can run their own code on the server — read files, pull the database, drop a webshell, pivot to other machines. It's the worst class of bug a web server can have, because the attacker needs no password and no valid login.

The exact PHP component that's vulnerable has not been named in PHP's published advisory yet. PHP's notice confirms two critical RCE flaws in PHP core; the CVE identifiers and the "remote code execution" classification come from researchers and reporting, not from PHP's advisory, which so far names neither the CVEs nor a vulnerable function. The CVE record on cve.org is still marked "reserved."

Treat that as a reason to patch, not a reason to wait. You don't need to understand the internals to be at risk. If your server runs an unpatched, in-support PHP version, the fix exists and you should apply it.

You'll also see reports claiming "all PHP 5 through 8 is affected." That range is rumor, not vendor fact — it traces back to the leaked tool banner. Until PHP's advisory confirms a range, treat the maintained branches (8.2–8.5) as the ones that matter, because they're the only ones that will get a fix.

How to check your PHP version

If you built with an AI assistant and never touched the server underneath, start here. (For the rest of what to verify before launch, see our vibe coding security checklist.)

1. On the server: php -v

SSH into the box and run:

php -v

You'll get a line like PHP 8.3.7 (cli). That's your CLI version. Note that the version PHP-FPM serves for the website can differ from the CLI version on the same box, so don't stop here.

2. phpinfo() — then delete it

Create a tiny file in your web root (for example info.php) containing only:

<?php phpinfo(); ?>

Load https://yourdomain.com/info.php in a browser. The first block shows the PHP version, the server API (FPM, Apache, FastCGI), and the loaded php.ini. Delete the file immediately after. A public phpinfo() page is a free reconnaissance gift to attackers.

3. Your hosting panel

cPanel, Plesk, and most managed hosts show the PHP version per site, usually under "Select PHP Version" or "PHP Settings." Most also let you change it per domain. If a "managed" host hides the version entirely, open a ticket and ask — you're entitled to know what runs your site.

4. Your Docker image tag

If you deploy with Docker, check the tag in your Dockerfile or docker-compose.yml:

docker inspect --format '{{.Config.Image}}' your-container

A tag like php:8.3-fpm tells you the branch but not the patch level. Run docker exec your-container php -v to see the exact version inside the running container.

A quicker external check: Rustine's free quick scan reads the X-Powered-By header your site sends and flags it when the advertised PHP version is affected. If PHP is detected but its version is hidden, Rustine reminds you to check it yourself — because a hidden version is not a patched version.

What to do today

1. Update to the October 21 release

Apply the release published on October 21, 2026 for your branch (8.2, 8.3, 8.4, or 8.5). Get it from php.net or wait for your distribution's package. Distro packages (apt, yum, the official Docker images) usually lag php.net by hours to a day — the official images and building from source get you the fix fastest.

I'm deliberately not printing exact version numbers here: as of this writing, php.net's changelog and the php-src advisory haven't published them yet, and a wrong number is worse than none. Check php.net for the release published on October 21 and match your branch.

2. Restart PHP-FPM

Updating the package is not enough — the running worker still has the old code loaded. Restart the process:

sudo systemctl reload php8.3-fpm   # replace 8.3 with your branch

If you use Apache with mod_php, restart Apache instead. Reloading PHP-FPM is graceful; you don't need a full reboot.

3. Check managed hosts

If a host "manages" PHP for you, the patch is their job, not yours. Open a ticket today: "The October 21, 2026 PHP security release fixes two critical RCE flaws — when will my sites be updated?" A good host applies it automatically; a bad one needs a nudge. Managed WordPress, Laravel Forge, and similar platforms usually roll it out fast, but don't assume.

4. Set expose_php = Off — after you patch

In php.ini:

expose_php = Off

This removes the X-Powered-By header that advertises your PHP version. Set it after updating. Hiding the version fixes nothing — it only stops you (and scanners) from seeing whether you're vulnerable, which is the opposite of what you want during an incident. It's good hygiene; it is not a patch. See our security headers guide for the other headers worth locking down.

5. Temporary mitigation, if you can't patch immediately

If your host can't apply the update for a day or two, security firm Sansec suggests two settings that may blunt the attack. They are not a fix and not a guarantee, but they're low-risk on a normal site:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

For PHP-FPM, set both in the pool config (for example /etc/php/8.3/fpm/pool.d/www.conf) using php_admin_flag, then reload the workers. Apply the real update as soon as you can.

The prompt for your coding agent

Paste this into Cursor, Claude Code, or your AI coding agent to check and patch a server you control:

You are helping me patch PHP for CVE-2026-109618 and CVE-2026-109619
(two critical remote-code-execution flaws fixed October 21, 2026).

1. Check what is installed and how PHP is served:
   php -v
   ls /etc/php/
   systemctl list-units | grep -i php

2. Update PHP to the October 21, 2026 security release for my branch
   (8.2, 8.3, 8.4 or 8.5). On Ubuntu/Debian:
   sudo apt update
   sudo apt install --only-upgrade php8.3-common php8.3-fpm php8.3-cli
   # replace "8.3" everywhere with my branch

3. Restart the process that runs PHP:
   sudo systemctl reload php8.3-fpm   # PHP-FPM
   # or: sudo systemctl restart apache2   # mod_php

4. Then check that `php -v` reports the release published on October 21,
   and that PHP-FPM is serving the new version. If the running version
   is still old, tell me before proceeding.

Two notes: the exact package names vary by distribution, and if a managed host owns your PHP, this prompt belongs in a support ticket, not a terminal.

How Rustine fits in

Rustine is a security scanner for apps built with AI. Its free quick scan reads the X-Powered-By header your site announces and flags it when the advertised PHP version is affected. If PHP is detected but the version is hidden, Rustine tells you to verify the version yourself rather than assume you're safe. The check is built for exactly this situation: you shipped a PHP app and you're not sure what's on the server. Run a free scan at rustine.io.

Frequently asked questions

Is my site affected by CVE-2026-109618?

If your server runs a maintained PHP branch — 8.2, 8.3, 8.4, or 8.5 — and you have not applied the October 21, 2026 release, assume yes and update today. If you run PHP 8.1 or older, there is no official fix; move to a supported branch.

Are PHP 5 and PHP 7 affected?

Unverified. The "every version from 5.4.0 onward" claim comes from a leaked exploit-tool banner, not from PHP's advisory, which has not confirmed an affected version range. What is confirmed: only 8.2 and later are supported, so only those branches will get a fix.

Is this being exploited in the wild?

Not at the time of writing. Huntress reported no in-the-wild exploitation, and the flaws are not on CISA's KEV catalog. That can change within hours of the patch — the patch reveals the bug.

Will hiding my PHP version protect me?

No. Setting expose_php = Off hides the version string but changes nothing about the vulnerability. Hide it after you patch, as hygiene, never instead of patching.

What if my host won't update?

Move. An unpatched PHP server on a supported branch with a public RCE is a liability. If your host won't commit to the October 21 release, plan a migration or switch to a supported branch you control.

Sources

• PHP: Upcoming Critical PHP Security Release and the PHP 8 ChangeLog
• php-src GitHub security advisories
• CVE Record — CVE-2026-109618 and CVE-2026-109619
• Huntress — Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities
• watchTowr — PHP Remote Code Execution FAQ: CVE-2026-109618 & CVE-2026-109619
• Sansec — Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619
• Phoenix Security — PHP Core RCE CVE-2026-109618/109619 Critical Fix