PHP2Shell CVE-2026-109618 CVE-2026-109619 | Am I affected?

Live updates: this post is a snapshot. For the latest on PHP2Shell (CVE-2026-109618 and CVE-2026-109619), follow the Mallory story. It updates automatically as advisories, exploits and attack activity appear.

Correction, Oct 21: our Oct 20 version undercounted PHP services on older branches because of how Shodan matches short version strings. Recounted by exact version, 73.5% of services that disclose a PHP version run 8.1 or older, not 59%.

PHP released fixes on October 21 for two critical remote code execution flaws in PHP core, CVE-2026-109618 and CVE-2026-109619, together known as PHP2Shell. An unauthenticated attacker can trigger them before any application code runs. Security vendors report millions of exploitation attempts, but no confirmed compromise. Our recount finds that about three in four internet-facing PHP services that disclose a version run PHP 8.1 or older, and PHP will not release fixes for those versions. Two days after release, about 1 in 10 services on supported branches showed a fixed version. Common dependency and container scanners do not flag these CVEs, so a clean scan does not mean a server is safe.

At a glance

Am I affected?

• Yes, if a web server runs PHP older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 through mod_php, PHP-FPM, CGI, FrankenPHP or LiteSpeed. The application does not matter: WordPress, Drupal, Magento, Laravel and Symfony sites are all exposed through the PHP they run on.
• Yes, if a web server runs PHP 8.1 or older. PHP published source patches for 7.4, 8.0 and 8.1, but no fixed release. Only some distributions and vendors ship backports (see Who has shipped fixes).
• Probably not, if PHP runs only from the command line, for example Composer, PHPUnit or cron scripts, and never answers HTTP requests.
• Check the package, not only the version. Debian, Ubuntu, Red Hat, SUSE, Plesk and cPanel fix older branches without changing the PHP version number. Compare your package release with the vendor advisory.
• On hosting or an appliance, ask the vendor. You cannot patch a PHP that the vendor ships. See Products that run PHP and the hosting list below.

What to do now

1. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's patched package. Then restart every PHP worker (PHP-FPM, Apache, LiteSpeed) and confirm the running version.
2. Even after updating, set session.upload_progress.enabled=0 until PHP's next regular release. PHP recommends this to block CVE-2026-115560, which the Oct 21 releases do not fix (details).
3. Patch Apache mod_php servers first. Then PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.
4. On PHP 8.1 or older, move to a supported branch. If you cannot move now, get a vendor backport, or build from PHP's source-only fix for 7.4, 8.0 or 8.1. Until then, restrict access (VPN, IP allowlist) or take the service offline.
5. If you cannot patch today, apply PHP's interim measures. They reduce risk but do not make a server safe:
   • Set session.upload_progress.enabled=0 in php.ini or the server configuration, and restart every worker. Under mod_php, make sure .htaccess cannot turn it back on.
   • Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration. Check that no pool, directory or application setting puts a finite limit back. Keep post_max_size low (8M without uploads, 32M with uploads).
   • On PHP 8.5, set fatal_error_backtraces=0.
   • Do not use RLIMIT_AS or RLIMIT_DATA as a limit. They can trigger the vulnerable failure.
6. Ask hosting providers and appliance vendors whether they have deployed the fix. Updating WordPress, Drupal or Laravel does not update PHP.
7. Check the PHP version that each web server actually runs, for example with php -v for the same binary or a phpinfo() page behind authentication. Do not rely on a clean dependency or container scan (see below).
8. Watch for exploitation signs. Look for unexpected child processes of the web server, new files in web roots, PHP worker crashes, and sudden spikes in HTTP 502 errors. Turn on your WAF vendor's rules for these CVEs.

Is it being exploited?

As of 04:15 UTC, October 24: attacks are widespread, but no one has published a confirmed compromise. Reliable exploits exist privately at Trail of Bits and VulnCheck, but none is public.

Attack volume

• Amazon saw an attempt in its MadPot honeypots on Oct 17, four days before disclosure. More attempts from several sources followed on Oct 21 between 02:00 and 08:00 UTC. Amazon says "it's unclear if any of these attempts would have succeeded in real-world systems."
• Cloudflare reports that it "observed attack traffic targeting our customers", and that attackers changed their payloads to try to get past its rules. Its CEO wrote on Oct 22 that attempts grew to millions after the announcement.
• Imperva counted 482,342 attack requests against 21,998 sites in 103 countries in the first 24 hours. It says these "do not represent confirmed successful exploitation".
• Check Point says one in ten organizations were "impacted". It defines that as exploitation attempts: "we have no way of knowing if the attack has been successful".
• VulnCheck canaries recorded scanning on Oct 21 with tools named php2shell-scan and php2shell-verify. One scanner reached 188 canary hosts. At 17:22 UTC, a China-based IP tried to plant a web shell through the session upload-progress path. Its attempts to read the shell back all returned 404, so the attempt failed.
• watchTowr reports exploitation in its honeypot network since October 21. Imunify360 and Patchstack hosting partners also reported attempts.

Botnets

• cowrAI recorded PHP2Shell attempts on its honeypots that tried to download a Mirai-variant DDoS bot.
• Sophos first reported a compromise, then corrected it on Oct 22 at 21:21 UTC. Its telemetry shows "scanning and a small number of failed exploitation attempts" and "no evidence of a successful compromise". The Potassium botnet malware the attackers tried to install was not delivered.

Exploit code

• SANS ISC says "no reliable exploit has been made available publicly". A second diary explains that public exploits assume an 8 MB memory limit where real servers use 128 MB. They also read memory addresses from the server itself, and can only run very short commands. That describes public code. The private exploits below show that reliable exploitation is possible.
• A public research exploit achieves remote code execution against PHP 8.5.11, but only with ASLR turned off.
• Trail of Bits CEO Dan Guido says its private exploit is now "production-grade" (Oct 24, 02:52 UTC). He says it works with a stock php.ini-production, display_errors=off, a normal memory limit, multiple workers and ASLR on, under load. He lists ARM64 and x86-64 targets, MediaWiki, WordPress, phpBB and Laravel, and both Apache with mod_php and nginx with PHP-FPM, ending in "root". On Oct 22 he had reported a shell on an unmodified MediaWiki installation. Trail of Bits has not published the exploit.
• VulnCheck says it had a weaponized exploit for CVE-2026-109618 by 1:30 AM ET on Oct 22. It chains a memory leak VulnCheck found into RCE with ASLR on and display_errors=off. As of 5:30 PM ET on Oct 23, it supports PHP 8.4.10 to 8.4.26 and 8.5.10 to 8.5.11 under mod_php on AMD64 and ARM64 with default settings, including default WordPress Docker installs. VulnCheck shares it only with customers.
• VulnCheck also reviewed the public proof-of-concepts. "Only a very small number have been legitimate exploits." It found one that bypassed ASLR on x86-64, but only for PHP 8.4.26 with default heap settings. In VulnCheck's testing it did not work outside that setup.
• Systems with ASLR turned off are easier targets. Kevin Beaumont reports that Palo Alto firewall VMs, Citrix NetScaler and HPE System Management Homepage ship PHP with ASLR off, which makes the public techniques much easier to use. He expects public exploits that work with ASLR on "probably next week".
• A Metasploit module is proposed but not merged (PR #22036, open as of Oct 23).
• Many proof-of-concept repositories are public, and most do not work. At least one fake proof-of-concept hides a malicious payload. Do not run untrusted exploit code.

Official status

• The Dutch NCSC (updated Oct 23, 15:43) knows of one report of possible abuse abroad, and calls exploitation technically complex.
• The UK government told Parliament on Oct 22 that it is "not currently aware of any confirmed compromise of central government systems".
• Palo Alto, Fortinet, Juniper and Cisco all say they are not aware of malicious exploitation against their products.
• CVE-2026-109618, CVE-2026-109619 and CVE-2026-115560 are not in the CISA Known Exploited Vulnerabilities catalog (Oct 23 release, 19:30 UTC).

What the bugs are

PHP's advisory and the public fix explain both flaws.

• CVE-2026-109618 (memory-exhaustion corruption):
  • When PHP runs out of memory while it parses an incoming request, it stops abruptly and leaves internal data half-built.
  • The cleanup step then treats that data as valid.
  • On Apache mod_php the worker process survives this and keeps running, which is why mod_php carries the highest risk.
• CVE-2026-109619 (stale state between requests):
  • Data that belongs to one request can survive after its memory is freed.
  • The next request handled by the same worker can then use it.
  • Confirmed paths include session upload progress, which is on by default, and a PHP 8.5 error-reporting feature.

PHP fixed both flaws in one change per branch. Early public theories blamed a different upload-progress bug, and many circulating proof-of-concept scripts follow that theory. PHP's security team found no working public exploit at release time.

On Oct 22, a researcher reported a crash in PHP 8.5.12 that looked like a bypass of the fix. PHP's Jakub Zelenka replied that it is "unrelated issue with minimal impact" and "has nothing to do with the RCE". PHP has not released any version after 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

A third CVE: CVE-2026-115560

On Oct 23 at 10:12 UTC, PHP published an informational advisory for CVE-2026-115560, which PHP calls "an unlikely RCE vector". It applies only when all of these are true:

• The application sets session.serialize_handler to php_binary or php_serialize in its configuration.
• It then switches the handler to php at runtime with ini_set() before it calls session_start().
• Session upload progress is still enabled.

The Oct 21 releases do not fix it. PHP will fix it in the next regular release and publish a full advisory then. Until then, PHP recommends session.upload_progress.enabled=0. If you set this as an interim measure on Oct 21, keep it. There is no CVSS score, NVD record or OSV record yet.

Why your scanner may not flag it

The flaws are in the PHP interpreter, not in an application or framework. A Laravel, Symfony, WordPress or Magento site is exposed because it runs on a vulnerable PHP, whatever the version of the application. Many security scanners look at the application's dependencies, so they miss the interpreter. We tested this at 21:45 UTC on October 21:

• Dependabot: GitHub has no global advisory for either CVE. PHP published the advisories only on the php-src repository, so Dependabot has nothing to alert on.
• composer audit and lockfile scans: OSV and the Packagist advisory database have no record for the PHP interpreter.
• Official Docker php images: Trivy gave the same result for the vulnerable php:8.3.35-apache and the fixed php:8.3.36-apache, with no finding for either CVE. These images compile PHP from source, and Trivy only reads the Debian packages. Grype finds the PHP binary in these images, but it did not report these CVEs in our test.
• Distribution packages: Debian and Ubuntu PHP packages are flagged, because their security trackers list the CVEs.

Software bills of materials (SBOMs) do not close the gap either. We looked for vendor SBOMs for 223 commercial and open-source products. For about three in four, we found none, and many others are available only to customers on request. Of the 39 SBOM files we could download, 32 do not list a PHP interpreter. Some of those products do not use PHP, such as TrueNAS. Others, such as Zabbix, Nextcloud and Pimcore, list their PHP libraries but not the PHP that runs them.

We checked again on Oct 23 at about 22:00 UTC:

• GitHub still has no global advisory, so Dependabot still has nothing to alert on.
• OSV still has no record under the CVE IDs. It has records only for Bitnami's PHP packages, such as BIT-php-2026-109618.
• NVD has analyzed both CVEs and published version ranges, so scanners that match against NVD can now find them.
• A Trivy user reports that php:8.2.30 images are still not flagged.
• The Nuclei template for these CVEs is merged. It is marked intrusive because it detects the flaw by crashing a PHP worker. Do not run it against production without approval.

Until your scanner shows these CVEs, check the running PHP version directly.

Who has shipped fixes

As of 22:15 UTC, October 23:

Fixed

• Linux distributions:
  • Debian 12 (php8.2, DLA-4848-1) and 13 (php8.4, DSA-6574-1).
  • Ubuntu 14.04 to 26.10. 14.04, 16.04, 18.04 and 20.04 are fixed through Ubuntu Pro.
  • Alpine edge and 3.24 (PHP 8.4 and 8.5).
  • Fedora 43, 44, 45 and Rawhide.
  • Red Hat Enterprise Linux 10, 9 (PHP 8.0, php:8.2 and php:8.3) and 8 (php:7.4 and php:8.2), plus EUS, E4S and AUS streams back to 8.4. See the Red Hat VEX for each erratum.
  • AlmaLinux 8, 9 and 10, including AlmaLinux-only builds for php:7.2, php:7.3, php:8.0 and php:8.1.
  • Rocky Linux 8, 9 and 10, and Oracle Linux 8, 9 and 10.
  • SUSE Linux Enterprise 16.0, 15 SP4 to SP7 (php8 and php7), SLE 12 (php74), and openSUSE Leap 15.6.
  • Amazon Linux 2023 (PHP 8.2 to 8.5) and Amazon Linux 2 PHP 8.2 (Extras).
• Container images: the official Docker php image.
• PHP packages and builds:
  • Ondřej Surý's PPA, including 5.6, 7.4, 8.0 and 8.1.
  • windows.php.net.
  • remi repository, including 7.4, 8.0 and 8.1.
  • CloudLinux alt-php 5.2 to 8.5 on CloudLinux 7, 8 and 9.
• Hosting control panels:
  • cPanel EasyApache 4 (ea-php74 to ea-php85), and the PHP that cPanel & WHM itself runs on.
  • DirectAdmin, including 7.4, 8.0 and 8.1.
  • Plesk: the panel's own PHP (Obsidian 18.0.81 Update 4 and 18.0.80 Update 11), and PHP for hosted sites: 8.2 to 8.5, and 7.4, 8.0 and 8.1 on Linux.
  • CloudLinux ea-php packages for cPanel EasyApache 4 (ea-php52 to ea-php85).
  • HestiaCP, including the panel's own PHP.
• Cloud and hosting platforms:
  • AWS Elastic Beanstalk: PHP 8.4 and 8.5 platforms (Oct 21), PHP 8.2 and 8.3 platforms (Oct 22). AWS says its own services are not affected (bulletin 2026-143-AWS).
  • Heroku, including 8.1. Apps must be rebuilt and redeployed.
  • Laravel Cloud, all regions. Running apps were patched in place.
  • Pantheon, including LTS versions.
  • Kinsta, all versions.
  • Hostinger shared hosting. VPS customers must update PHP themselves.
  • GoDaddy Managed Hosting for WordPress, Web Hosting and Windows Hosting.
  • WP Engine and SiteGround.
  • Azure App Service on Linux, built-in images on the Latest and Standard release channels (8.2 to 8.5). The Extended channel gets the fix last. Custom containers need a rebuild.
  • Bref 3.0.14. Redeploy to use the fixed layers.
  • FrankenPHP 1.13.2.
  • Google Cloud runtimes. App Engine flexible and custom images need a redeploy.
  • Hetzner managed hosting.
  • One.com (8.2 and later).
  • OVH web hosting, PHP 7.4 to 8.5.
  • Clever Cloud, including 7.4, 8.0 and 8.1.
  • DigitalOcean App Platform PHP buildpack and Functions runtimes (redeploy to use them).

Not yet fixed

• Red Hat Enterprise Linux 9 php:8.4 module stream.
• SUSE Linux Enterprise 16.1 and 16.2, SLE 15 before SP4, and openSUSE Leap 16.0 and 16.1.
• Amazon Linux 2 core PHP and Amazon Linux 2023 PHP 8.1: no fix planned.
• Debian 11 (bullseye): not listed in the Debian security tracker.
• Vercel community PHP runtime: 8.5 and 8.4 are fixed; 8.3 and 8.2 are not. Redeploy to use the fix.
• DigitalOcean Marketplace 1-Click images (WordPress, LAMP, LEMP, Laravel and others): DigitalOcean delisted them until patched and has not said they are fixed. Servers already created from them do not update themselves.

Unofficial backports for end-of-life PHP: independent developers have published patches for PHP versions that no vendor fixes. They come with no support commitment, and upgrading remains the real fix:

• PHP 7.3 on CentOS 7, and PHP 5.4 and 5.3 on Amazon Linux: source patches and build scripts, no binaries (Leon Lai).
• PHP 5.4.16 on Enterprise Linux 7 and 5.3.3 on Enterprise Linux 6: patches plus signed RPMs (Oleksii Molchanov).
• TuxCare's commercial extended support also ships fixed builds, according to Molchanov.

No public statement found: Alibaba Cloud, which hosts about 111,000 versioned PHP services.

Products that run PHP

Many firewalls, NAS devices, phone systems, control panels and self-hosted apps run PHP. Some ship their own copy of PHP. An operating system update does not fix that copy; only the vendor can. Others use the PHP from the operating system, so the operating system update is the fix. The table shows which is which, for the products we checked.

Palo Alto Networks PAN-OS and Panorama are the most serious case so far. Palo Alto's advisory says all versions are affected. On Oct 23 it published expected hotfix dates of Oct 26 to Oct 30, depending on the version (for example 11.2.10-h16, 11.1.16-h4 and 10.2.18-h13 on Oct 26, and 12.2.4-h1 on Oct 28). The risk is highest when the management interface is reachable from the internet. Palo Alto rates the impact on its products as denial of service (CVSS-B 8.7) and is not aware of exploitation. Kevin Beaumont reports that Palo Alto firewall VMs run with ASLR off, which would make exploitation easier. As of 04:15 UTC on Oct 24, no hotfix had been released. Palo Alto recommends restricting management access to trusted internal IP addresses. Its Oct 24 update lists 25 Threat Prevention IDs (543004, and 97622 to 97678, from content version 9162). These protect the management interface only if management traffic is routed through a dataplane port and decrypted so the firewall can inspect it. Cloud NGFW, Prisma Access, WildFire and Strata Cloud Manager are not affected.

Products that do not use PHP

These products are sometimes assumed to run PHP. Their web interfaces use another language, so these CVEs do not affect them. PHP apps that you install on top of them can still be affected.

• Internet exposure. Between 18:00 and 18:20 UTC, Shodan saw about 95,000 Nextcloud, 76,000 pfSense, 68,000 Coolify, 65,000 phpMyAdmin, 62,000 XAMPP, 47,000 HestiaCP, 20,700 OPNsense and 10,000 FreePBX web interfaces. One service is one IP address and port. A count shows exposure, not confirmed vulnerability.
• FreePBX is a clear legacy risk. About half of the FreePBX services that show a PHP version run PHP 7.4, which PHP stopped supporting in 2022.
• Pull and redeploy containers. The official Docker images listed above were rebuilt with fixed PHP between 18:11 and 18:42 UTC. Containers started from an older image keep the old PHP until you pull the new image and redeploy.

Where the unpatched services are

Shodan sees 2.6 million internet-facing services that report a PHP version. 73.5% of them (1.9 million) run PHP 8.1 or older, and PHP will not release fixes for these. A second scanner, Netlas, gives 75.9% on its own data.

Source: Shodan host counts, Oct 21, 2026. Each patch version counted from the X-Powered-By header and from Apache Server headers. One service is one IP address and port.

PHP 7.4 alone accounts for about 411,000 services. More than half of them run 7.4.33, the last release, which PHP stopped supporting in 2022.

About 92,000 services still report PHP 5.5.9 from Ubuntu 14.04, which went out of standard support in 2019. Canonical fixed this version, but only through Ubuntu Pro. Only 247 of these services run an Ubuntu Pro build. About half of the 92,000 are on Alibaba Cloud in China.

By country

• 35 of the 73 countries with at least 1,000 versioned services are at 80% or higher.
• The largest of these are China, Italy (90%), South Korea (89%), Hong Kong and Algeria (99.9%).

By provider

Amazon hosts the most PHP services, and its own Linux will not fix some of them: Amazon lists "No Fix Planned" for the core PHP in Amazon Linux 2 and for PHP 8.1 in Amazon Linux 2023. All Amazon, Alibaba and OVH network names are combined. Shared hosting puts many websites on one IP address, so far more websites are affected than services. Some distribution packages fix the flaws without changing the version number, so a version banner alone does not prove a service is vulnerable.

Apache mod_php: the highest-risk setup

Only mod_php adds a PHP/x.y.z token to Apache's Server header. With that token, we count at least 565,000 internet-facing mod_php services. Of those that show the version only in the Server header, 83% run PHP 8.1 or older. The real number is higher, because Debian and Ubuntu hide this token by default.

How fast are servers patching?

At 22:05 UTC on Oct 23, about two days after release, Shodan saw a fixed version on 62,449 of about 601,000 services that report PHP 8.2 to 8.5 in the X-Powered-By header (10.4%). PHP 8.5 leads, and 8.2 lags:

Source: Shodan host counts, Oct 23, 2026, 22:05 UTC. Branch totals count "X-Powered-By: PHP/8.x."; fixed counts are the exact fixed version.

The largest counts of fixed services are on Amazon (about 8,600 across its networks), Hetzner (3,210), OVH (2,012), DigitalOcean (1,695) and Cloudflare (1,667) addresses. Hostinger hosts about 45,600 services that report PHP 8.3, and Shodan still sees none on 8.3.36. Hostinger says the fix is installed on all its hosting servers except VPS, so it may have patched without changing the reported version.

On Oct 21 at 21:42 UTC, about eight hours after release, Shodan saw a fixed version on 2,149 of about 606,000 services that report PHP 8.2 to 8.5 in the X-Powered-By header (0.36%). The count was 103 at 15:22, 144 at 15:52 and 312 at 17:15 UTC. It grows as Shodan scans servers again, so it lags real patching. Distribution packages that keep the old version number do not show up here.

Updates

Sources and method

• PHP project: security release announcement, October 21, 2026; advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp
• PHP Foundation: Today's PHP security release
• Exploitation reports: Cloudflare, watchTowr, Patchstack, CloudLinux / Imunify360, Huntress, Sansec, CISA KEV
• Oct 22 to 23 exploitation and exploit reports: Amazon, Imperva, Check Point, Sophos, cowrAI, VulnCheck, Trail of Bits (Dan Guido), SANS ISC 33450 and 33452, Kevin Beaumont, NCSC-NL, Basel-Stadt, UK House of Lords (Hansard, Oct 22).
• CVE-2026-115560: PHP informational advisory, Oct 23, 2026. Fix-bypass clarification: oss-sec.
• Affected range: NVD CVE-2026-109618, NVD CVE-2026-109619, Wiz, Calif, Google Cloud GCP-2026-070
• Patch status:
  • Distributions: Debian, Ubuntu, Red Hat Bugzilla, SUSE Bugzilla, Amazon Linux, Fedora, Red Hat VEX, SUSE, remi, AlmaLinux, Rocky Linux.
  • Red Hat errata: RHSA-2026:87070, RHSA-2026:87071, RHSA-2026:87072, RHSA-2026:87079, RHSA-2026:87080, RHSA-2026:87151.
  • Appliances and products: Palo Alto Networks, Netgate forum, Sophos, Fortinet, F5, Citrix, Synology advisories, Synology packages, QNAP advisories, mailcow, HestiaCP, Coolify, OPNsense packages, XAMPP downloads. Container image PHP versions were read from the image configuration in Docker Hub.
  • AWS: security bulletin 2026-143-AWS; Elastic Beanstalk: Oct 21 PHP platform release.
  • Control panels: cPanel, cPanel & WHM 136, DirectAdmin, Plesk, CloudLinux.
  • Cloud and hosting platforms: Heroku, Hetzner, One.com, OVHcloud, Azure App Service, Laravel Cloud, Pantheon, Kinsta, Bref, FrankenPHP, Clever Cloud, DigitalOcean, Hostinger, GoDaddy, WP Engine, SiteGround, Vercel community PHP runtime.
• Service counts: Shodan /shodan/host/count, Oct 21, 2026, 16:04 to 16:22 UTC.
  • Every patch version from 4.0 to 8.5 was queried separately, in two forms: "X-Powered-By: PHP/<version>", and Apache Server headers that carry a PHP/<version> token with no X-Powered-By header.
  • Country and provider tables come from the same queries.
  • Counts are IP and port pairs that Shodan has seen recently, not unique organizations.
  • Our Oct 20 version used one query per branch ("X-Powered-By: PHP/<major.minor>"). That form undercounts for several branches. For example, it returned 71,183 services for 7.4, but 7.4.33 alone has 225,173.
• Cross-check: Netlas, index 2026-09-29, IP responses only. Netlas finds 75.9% of versioned PHP services on 8.1 or older.
• Appliance counts: Shodan /shodan/host/count, Oct 21, 18:00 to 18:20 UTC, by login-page title or favicon hash. FreePBX PHP versions come from the X-Powered-By header.
• Patch rate: Shodan counts of "X-Powered-By: PHP/<fixed version>" at 15:22, 15:52, 17:15 and 21:42 UTC on Oct 21, and 22:05 UTC on Oct 23, with an organization facet for the provider split. The 21:42 UTC and Oct 23 denominators count "X-Powered-By: PHP/8.x." for 8.2 to 8.5 at the same time. Ubuntu 14.04 counts use the "X-Powered-By: PHP/5.5.9-1ubuntu4" banner. Branch totals were counted at 15:52 UTC.
• Product table: vendor advisories, release notes, package repositories, staff forum posts and container image configurations, checked October 21 between 22:40 and 23:00 UTC, and rechecked October 23 between 22:04 and 22:15 UTC. Rows link their source where one exists. The "Runs PHP for web requests" column says Yes only when a vendor document, source code, package list or image configuration shows it.
• SBOM search: public SBOM portals, vendor security pages and searches for 223 products. We inspected each downloaded SBOM for a PHP interpreter component.
• Scanner test: October 21, about 21:45 UTC. GitHub global advisory API, OSV API and Packagist advisory API queried for both CVEs. Trivy 0.76.1, Grype 0.121.0 and OSV-Scanner 2.7.0 run against the official php:8.3.35-apache and php:8.3.36-apache images.