When a Critical PHP Flaw Lands, Which of Your Websites Are Exposed?

Which of Your Websites Are Exposed When a PHP Vulnerability Lands?

Your exposed websites run PHP below the fixed release, on a server you or your host must patch. PHP2Shell is the name for two critical flaws in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, fixed on October 21, 2026. CISA said they allow remote code execution without a login and affect all PHP installations serving web requests. CISA added both to its Known Exploited Vulnerabilities catalog on October 26.

No version got a pass for being old. The flaws reached back to PHP 5.4, and official fixes shipped only for PHP 8.2 and later, Infosecurity Magazine reported. The UK's National Cyber Security Centre (NCSC) told organizations not to limit discovery to outdated versions.

How Do You Narrow PHP Vulnerability Exposure by Version?

Narrowing by PHP version sorts every site into one of four groups, and each group has a different next step.

PHP exposure groups during PHP2Shell, and the next step for each

Only the middle two groups need urgent work, and the PHP 8.1 group needs a decision, not just a patch.

Offline was real advice. CISA told organizations that could not update right away, or that still ran PHP 8.1 or earlier, to take PHP-based systems offline until patched. Knowing each site's PHP version lets you take offline only the few sites that can't be fixed yet.

Installed isn't the same as running. The researchers who found the flaws say Apache, PHP-FPM, and long-running PHP workers must be restarted after the upgrade, as Rescana's advisory summarizes. Confirm the version each site reports, not the package you installed.

Where Does Each Answer Live: the Code or the Host?

Module and package versions live in the code, but the PHP version a site actually runs is set by its server or hosting platform. A Composer file, the dependency list a PHP project keeps, says which PHP versions the code accepts. It doesn't say which one production runs.

Where each exposure answer lives, and who usually holds it

CISA told organizations to inventory every system running any version of PHP, warning that PHP often sits inside other software where it isn't directly visible. That inventory is quick only when you already know which host runs which site.

What Changes When the Flaw Is in a CMS Module or Plugin, Not in PHP?

A CMS module or plugin flaw moves the answer from the host to the code. On Wednesday, October 28, 2026, inside Drupal's weekly release window for contributed modules, the Drupal Security Team published SA-CONTRIB-2026-254 for Commerce Core. It rated the flaw highly critical and reported it as actively exploited in the wild. Exposure came down to one fact: which Commerce Core version each site ran.

The answer lived in each site's lock file, the record of the exact package versions a site installs. For a WordPress plugin flaw, the equivalent is each site's installed plugin list. A team with every repository connected to its record could answer with a lookup. A team without that link checks site by site.

What Can't a Vulnerability Scanner See?

A vulnerability scanner can't flag a flaw until it is listed in the database the scanner checks. Until then, only your own record can answer.

PHP2Shell shows that gap: Amazon recorded a PHP2Shell exploitation attempt dated October 17, four days before disclosure.

The Commerce Core flaw showed the gap again. Drupal published its advisory on October 28, and the CVE record, CVE-2026-118539, followed on October 30, per OpenCVE. A tool that matched only CVE records had nothing to flag for about a day and a half. When the record appeared, it carried a Medium CVSS score of 6.5, against Drupal's highly critical rating.

During the gap, a team works from advisories and its own record:

• Watch vendor and host channels directly: PHP project announcements, Drupal's security advisories, your host's notices, and national alerts such as CISA's.
• Put interim protection, such as firewall rules, in front of sites you can't patch yet.
• Decide which sites go offline if they can't be protected, as CISA and the NCSC advised.
• Check exposed sites for signs of compromise from before the fix, which the NCSC also recommended.

Exposure Is a Records Problem Before It Is a Patching Problem

Our view: the patch is the same for every team. What separates a fast, narrow response from taking everything offline is whether the record already holds the answers.

Our own October bore that out. We already kept an inventory of our sites and the PHP version each runs. All of the roughly 25 sites where we manage PHP were affected, and identifying and fixing them took about 45 minutes.

In mixed portfolios, that record tends to split in two. The code half, modules and packages, stays current because developers change it with every release and dependency tools read it automatically. The runtime half, PHP version and host, sits with whoever runs the server and goes stale quietly.

The runtime half goes stale for ordinary reasons. A host upgrades PHP across its platform, a site moves to a new server, or staging and production drift apart, and nobody updates the record.

What Should Your Record Hold Before the Next Flaw Lands?

Every site needs five facts on record before the next flaw lands. Our guide, Website Governance Starts With a Site Inventory, sets out the full record; these are the fields a security event tests first.

Five facts every site record needs before the next security advisory

1. Every site, including staging copies and the ones nobody has touched in a year.
2. The PHP version production runs, read from the server or host, with the date it was checked.
3. Where it is hosted, and who controls the PHP runtime there.
4. What code it runs: the CMS, modules, and packages at their exact versions, from the repository.
5. Who patches it, named separately for the runtime and the code.

A runtime flaw like PHP2Shell needs facts two, three, and five. A module or plugin flaw like the Drupal Commerce advisory needs facts four and five.

Find your gaps:

• If your record lists the CMS version but not the running PHP version, a runtime flaw sends you back to every host.
• If your PHP versions came from a spreadsheet updated last quarter, treat them as unknown until checked.
• If one name covers the site owner and the patch owner on every row, you haven't recorded who patches the runtime.
• If some sites aren't linked to a repository, a module or plugin flaw means checking those sites by hand.

If two or more describe you, fill those fields first.

PHP 8.2 stops receiving security fixes on December 31, 2026, according to the PHP 8.2.35 release notes, so a site patched to 8.2.35 has weeks of coverage left.

Our Drupal 10 end-of-life decision calendar recommends asking your host for PHP 8.4.

Where Does a Website Governance Platform Like Auditray Fit?

A website governance platform keeps the record this guide describes and checks every site against it continuously. It doesn't patch. Vardot built Auditray for this question, and we also sell support and maintenance, so weigh this section accordingly.

Auditray keeps one inventory of every site across Drupal, WordPress, and other stacks, imported from the spreadsheet you already have, with custom fields for owner, team, host, and vendor. It detects each site's technology and hosting stack automatically and checks each site against one standard you set.

On PaaS hosts such as Upsun, Pantheon, and Acquia, its hosting integrations read the PHP version each site actually runs. 

With a repository connected, Auditray tracks dependencies and known vulnerabilities and can export a software bill of materials (SBOM). That's where a code-level flaw, such as the Drupal Commerce advisory, shows up. Individual checks can be rerun to confirm a fix.

Where Should You Start?

Start with the sites you'd least want to take offline, and fill in the five facts for those first. Then run the next advisory against your record before you run it against your sites.

To see that record across your own portfolio, explore Auditray: create a workspace, import your site list, and connect one repository. If you'd rather have Vardot's team handle patching and follow-through, see our Drupal support and maintenance services.