PHP2Shell: the hard part is not hearing about it, it's knowing which server to fix today

On 21 October 2026 at 13:48 UTC, two critical flaws in PHP itself were officially published. Ubuntu’s notice with the fixed packages followed eight minutes later. That part went well.

Here is the part that didn’t. On Ubuntu 24.04, the patched PHP still prints this:

$ php8.3 -v | head -1
PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)

The upstream release that fixes PHP2Shell is 8.3.36. A patched server says 8.3.6. Compare the two numbers, the way most people and plenty of tools do, and a fixed server looks vulnerable. The reverse mistake is worse: wave the finding away with “that’s just a backport” on a server that never got the update.

If you have a security team, this is an afternoon. If you are a twenty-person company with one person who also runs the printers, it is the afternoon nobody has. That gap is what this article is about.

If you only read one block, read this:

• PHP2Shell is two flaws, CVE-2026-109618 and CVE-2026-109619: remote code execution in PHP itself, no login needed according to PHP’s own vector. Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and in your distribution’s packages.
• On Ubuntu and Debian, php -v does not tell you whether you are patched. The package version and its changelog do. Commands below.
• From 14:17, when NVD received the CVEs, to its analysis at 17:01, a scanner that matches against NVD’s product identifiers had nothing to match. Which source your tool reads decides when you hear.
• No government list says it is exploited. Amazon’s threat intelligence says it is being broadly exploited. Patch first, argue later.

The two bugs

PHP2Shell is the name the flaws go by. CVE-2026-109618 (“RCE via OOM corruption”) and CVE-2026-109619 (“RCE via stale global state”) are memory-handling bugs in PHP’s core. Almost every way PHP serves web requests is affected: PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed.

PHP scored both 9.2 on CVSS 4.0. NVD, the US National Vulnerability Database, later scored both 9.8 on CVSS 3.1. The two versions of the scale do not compare, but the vectors do, and they disagree on one thing: PHP rates the attack complexity as high and says the attack needs preconditions (AT:P); NVD rates the complexity as low.

Hour by hour: what each source knew

Times are UTC, as each source shows them, read on 22 October. “(i)” marks a time we infer.

Read the table as three kinds of tool. One that reads Ubuntu’s security notices had the fixed versions eight minutes after publication (Ubuntu’s CVE tracker listed them from 15:50; we did not read Debian’s times). One that matches against NVD’s product identifiers had nothing to match for 2 hours and 44 minutes, from 14:17 to 17:01. One that waits for the list of exploited vulnerabilities is still waiting: as of 22 October, neither CVE is on it.

Why a small company cannot keep up by hand any more

The numbers of the last year say the same thing from three directions.

• Exploiting a vulnerability is now the most common way in. In Verizon’s 2026 Data Breach Investigations Report it is the first initial access vector, at 31% of the breaches where the way in is known, and the first for small and medium businesses too, at 26% (Verizon counts as such companies under 1,000 employees).
• Attacks often start on day one. VulnCheck counted that 23% of the vulnerabilities newly added to its own list of exploited ones in the first half of 2026 were exploited on or before the day their CVE was published (29% in 2025).
• Patching does not keep up. In the same Verizon report, organisations had fully fixed only 26% of the known-exploited vulnerabilities they had to fix in 2025, and the median time to fix them was 43 days.

PHP2Shell fits the pattern. Amazon says one of its honeypots recorded an exploitation attempt on 17 October, four days before disclosure, that “additional proof-of-concept exploits appeared within hours” of the release, and, on 21 October, that “PHP2Shell is now being broadly exploited in the wild”.

AI is part of this story. The PHP Foundation thanks Calif, Wiz, OpenAI Codex Security, OSTIF and Quarkslab, and says “the growth of AI-assisted research also means the PHP security team receives far more reports than before”. Wiz writes that showing the flaws could be exploited took “an exceptionally complex chain of steps”, and that “frontier AI models substantially reduced that barrier”. Amazon writes that “AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit”, and adds that, for critical vulnerabilities in internet-facing systems, “a 7-day or 30-day SLA assumes a delay that no longer exists”. If Amazon is right, turning a fix into an attack got cheaper. Patching by hand did not.

Put that next to the table above. To do this job by hand for PHP2Shell, someone had to notice the CVE the same afternoon, know that php -v lies on Ubuntu, find every PHP package on every server (the command-line PHP and the one behind the web server are often different packages), compare each one with the right line of the right advisory, update, and check that the web server was restarted. Then do it again for the next one. In a company without a security team, that someone does not exist.

What NIS2 asks, and what it does not

NIS2 does not tell anyone to buy a scanner. Article 21 asks essential and important entities for “appropriate and proportionate” measures, and the list that follows includes, at point (e), “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”. In Italy the same list is Article 24 of Legislative Decree 138/2024, and the basic measures of the national agency, ACN, say vulnerabilities are to be resolved “prontamente” (promptly) and vendor security updates installed “senza ingiustificato ritardo” (without unjustified delay). Neither NIS2 nor the Italian rules fix a number of days.

Who is in scope: companies in the sectors of the directive’s two annexes that are medium-sized or larger, plus a short list of entities whatever their size. Many small companies are not directly in scope. They meet NIS2 anyway, through their customers: Article 21(3) asks every entity in scope to take into account the vulnerabilities of each direct supplier, and the recitals encourage writing security measures into supplier contracts.

So for a company in scope, handling vulnerabilities is an obligation, not an option, and its suppliers may find it written into their contracts. The law does not say how. What PHP2Shell shows is the part that does not work by hand: every server, every PHP package, the right line of the right advisory, every time a CVE like this one comes out. Keeping the inventory and matching new CVEs against it, so that a small team starts from a list instead of from nothing, is the job SentriKat exists for.

Checking a server properly

Ubuntu’s fixed versions, from its CVE tracker:

This is a backport: the distribution applies the upstream fix to the old version it ships, instead of moving you to the new one. ESM, in the last row, is Ubuntu’s Expanded Security Maintenance, which needs an Ubuntu Pro subscription.

The package database holds the answer. These two commands show it:

$ dpkg-query -W -f='${Version}\n' php8.3-cli
8.3.6-0ubuntu0.24.04.13

$ zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -n 'CVE-2026-10961[89]'
4:    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
293:    - CVE-2026-109618
294:    - CVE-2026-109619

The first is the version of the package: compare it with the one in Ubuntu’s notice for your release (USN-8948-1 for 22.04 and later, USN-8948-2 for older ones). The second is the distribution saying, in its own changelog, which CVEs this version closes. The package before it, 8.3.6-0ubuntu0.24.04.12, prints nothing for the same grep.

Both checks assume the package comes from Ubuntu’s own archive. A package from a third-party repository numbers its versions its own way: find out where yours comes from with apt-cache policy php8.3-cli first.

Debian’s fixed packages carry the upstream number: 8.4.27-1~deb13u1 on Debian 13 (advisory DSA-6574-1) and 8.2.35-1~deb12u1 on Debian 12, per Debian’s tracker. There, comparing the number works. Red Hat family distributions also backport their fixes; check your vendor’s advisory.

What we ran and what we only read: we ran the Ubuntu binary and read the changelog from the unpacked packages, not from an installed server; the dpkg-query line is the version field of the .deb, which is the same string. The Debian numbers and the stop-gap settings below we read in their sources and did not try.

Old versions are the other trap. PHP’s record lists only the 8.2 to 8.5 series, the supported ones. NVD’s product list reads “versions up to (excluding) 8.2.35” with no lower bound, so 8.1, 8.0, 7.x and 5.x are in it. Ubuntu shipped fixes for its 5.5, 7.0, 7.2, 7.4 and 8.1 packages, four of them under ESM. PHP no longer makes releases for 8.1 and older (BleepingComputer reports minimal source patches for 7.4, 8.0 and 8.1, for people who build their own), so for packaged PHP the fix comes from your distribution, whatever number php -v prints.

What this looked like in SentriKat

On SentriKat Cloud, both CVEs were in the catalogue at 16:06 UTC on 21 October, rated critical: before NVD’s analysis, and while the list of exploited vulnerabilities had nothing. At that hour a tool working from NVD’s data could not yet say which PHP installations were affected: the version ranges arrived with NVD’s analysis at 17:01.

Since 22 October, SentriKat Cloud matches a new CVE against your inventory within about two hours of NVD’s analysis.

When Ubuntu has published its fixed version of a package, SentriKat compares the package installed on each server with that version, not the number php -v prints. This is what that looks like, on a test installation with an invented company and server:

“Is it exploited?”

Not according to the government lists. The CISA catalogue did not list either CVE when we looked on 22 October, and ENISA’s vulnerability database, which carries them as EUVD-2026-107260 and EUVD-2026-107265, has no exploitation flag.

Two companies that watch attack traffic say yes. Amazon’s threat intelligence wrote on 21 October that “PHP2Shell is now being broadly exploited in the wild”, and told its readers to investigate from 17 October onwards. BleepingComputer reported that Cloudflare’s CTO said the company “was already observing early attacks”. The PHP Foundation says it “did not identify any functional exploits at the time of release/public disclosure”.

Waiting for the list is the wrong move here. No login needed and a routine package update: apply it first, find out how hard the exploit is later.

Today

1. List every PHP package, not only the one php -v finds: dpkg -l | awk '/^ii/ && /php/ {print $2, $3}'.
2. For each, compare the package version with the fixed one in the Ubuntu notice for your release or in Debian’s advisory, or grep the changelog as above.
3. Update with your usual process (on Ubuntu and Debian, apt update then apt upgrade), then check that php-fpm or Apache was restarted: systemctl status on the service shows when it started, and that must be after the update. A process that keeps running keeps the old code in memory.
4. If you cannot patch today, PHP lists stop-gap settings in its advisories, GHSA-w8hw-w9fx-j79w for the first bug and GHSA-6wmf-4rv5-p3rp for the second. They are not a fix, and for the second bug the advisory says there is no complete configuration mitigation.
5. If you do not control the server (shared hosting, managed WordPress), ask your host whether CVE-2026-109618 and CVE-2026-109619 are fixed on your server, and since when.
6. PHP you built from source is simpler for the 8.2 to 8.5 series: the number it prints is the real one, and it must be at least 8.2.35, 8.3.36, 8.4.27 or 8.5.12.

Sources

All read on 22 October 2026. Timestamps above are from these.

• CVE records: https://cveawg.mitre.org/api/cve/CVE-2026-109618 and .../CVE-2026-109619
• PHP security advisories: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w and .../GHSA-6wmf-4rv5-p3rp
• NVD records and history: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-109618 and https://services.nvd.nist.gov/rest/json/cvehistory/2.0?cveId=CVE-2026-109618
• CISA catalogue: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• ENISA: https://euvdservices.enisa.europa.eu/api/search?text=CVE-2026-109618
• Ubuntu: https://ubuntu.com/security/CVE-2026-109618, the notices https://ubuntu.com/security/notices/USN-8948-1.json and .../USN-8948-2.json (with the time of publication), the package archive http://security.ubuntu.com/ubuntu/pool/main/p/php8.3/
• Debian: https://security-tracker.debian.org/tracker/CVE-2026-109618 and advisory DSA-6574-1
• PHP release notes: https://www.php.net/ChangeLog-8.php and the release feed https://www.php.net/releases/index.php?json&version=8.3
• BleepingComputer, “PHP ships emergency patches for critical PHP2Shell flaws”, 21 October 2026
• The PHP Foundation, “Today’s PHP Security Release, and How We’re Strengthening PHP Security”, 21 October 2026: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
• Amazon, “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”, 21 October 2026: https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• Wiz, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet”, 21 October 2026: https://www.wiz.io/blog/php2shell-php-rce
• Verizon, 2026 Data Breach Investigations Report (incidents from 1 November 2024 to 31 October 2025): https://www.verizon.com/business/resources/reports/dbir/; the 31%, 26% and 43-day figures are in the report and its executive summary
• VulnCheck, “State of Exploitation 1H 2026”, 28 July 2026: https://www.vulncheck.com/blog/state-of-exploitation-1h-2026
• NIS2, Directive (EU) 2022/2555, Articles 2 and 21 and recital 85: https://eur-lex.europa.eu/eli/dir/2022/2555/oj
• Italy: Legislative Decree 4 September 2024 n. 138, Article 24: https://www.gazzettaufficiale.it/eli/id/2024/10/01/24G00155/sg; ACN Determination 379907/2025, Annex 1, measure ID.RA-08: https://www.acn.gov.it/portale/documents/d/guest/allegato-1-v2