PHP2Shell: Two Critical PHP Flaws, and the Config Files Every PHP Site Keeps Next to Its Code

A flaw in PHP is rarely just a flaw in PHP. It is a flaw in every site that keeps its database password in a file the PHP process can read, which is almost all of them. The PHP project has released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which are being called PHP2Shell. The UK's National Cyber Security Centre says attackers may be able to run commands on PHP web servers, possibly without authentication. Romania's DNSC published its own alert on 21 October.

Updating is the urgent step. What you do about secrets depends on whether you can show nobody got in first.

What is confirmed

The NCSC describes the trigger as an out-of-memory condition that leads to memory corruption, says any PHP version is affected and that older unsupported versions must be upgraded to a supported release, and notes the issue has now been fixed. Krebs on Security reports fixed releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and says Ubuntu has shipped updated packages. The NCSC also tells organisations to find every PHP install starting with internet-facing systems, to track vendor updates for appliances and services that bundle PHP, and to apply the PHP team's hardening steps or temporary mitigations if they cannot patch at once. If neither is quick, take the system offline. The DNSC alert, of which we read only the opening lines, says the PHP security team made an announcement about it on 20 October.

Krebs reports that working exploits exist and that Cloudflare has detected some exploitation and deployed firewall rules. It says Wiz expects mass exploitation to install web shells that give attackers remote control of sites. Wiz, Calif and OpenAI are reported to have coordinated with the PHP team before disclosure to verify patches and measure exposure.

What is not established

The “nearly 70 percent of websites” figure. Krebs states it in his own opening with no outside source attributed. Treat it as an estimate of how common PHP is, not as a count of vulnerable sites.
Who is exploiting it and how much. Cloudflare reports “some” exploitation. The NCSC page does not say whether exploitation has been observed. Nobody has published victim numbers.
Exact fixed versions for your stack. The version numbers above come from one article. Take them from the PHP project's advisories and your distribution, and for bundled PHP from the vendor.
Whether a workaround is enough. A widely shared configuration setting was, according to the firm that suggested it, not sufficient on its own. Do not rely on a workaround in place of the patch.

Why the config file is the real prize

A web shell runs as the web server or PHP account, with that account's file access. On a typical PHP application, that account can read the application's own configuration: the database host and password, authentication keys and salts, mail-server credentials, payment or analytics keys and any .env file. It can often read the same for every other site on the machine, if sites share a user or a directory tree.

That is why an attacker who plants a shell does not need a second exploit. Everything the account can reach is available within minutes, and the stolen database password can be used from anywhere the database accepts connections, long after the shell is removed.

What to do

Inventory PHP everywhere. Web servers, content management systems, self-hosted applications, control panels and appliances that bundle PHP. Start with anything reachable from the internet.
Patch or apply the vendor package. Move to a fixed release for your branch, or the distribution or appliance vendor's update. Where you cannot patch quickly, use the PHP team's temporary mitigations, put a web application firewall rule in front, or take the site offline.
Hunt for web shells. Look for PHP files that appeared recently in upload, cache and temporary directories, files whose modification times do not match a deployment, and unexpected scheduled tasks or new administrator accounts. Preserve logs before cleaning up.
Decide whether you can prove it was untouched. For an internet-facing site that ran a vulnerable version after the exploits circulated, assume it may not have been, unless logs show otherwise.
If you suspect compromise, rotate what PHP could read. That means database passwords, application secret keys and salts (which also invalidates sessions), API keys, mail credentials and anything in .env or configuration files. Rotate the database password first and restrict where the database accepts connections.
Check what that account could reach on the rest of the host. Shared users, backup files left in the web root and other sites on the machine are all in scope.
Reduce what the next shell inherits. Keep secrets outside the web root, give each application its own operating-system user and its own database account with only the access it needs, and prefer short-lived credentials where the platform supports them.

The step after rotation

A new database password or API key has to reach whoever deploys it, often a developer or a hosting provider. Under pressure it gets pasted into a ticket or chat thread, where it outlives the incident. Send each value once, to the one person who needs it, over a channel that does not keep it.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not a patching or hosting tool. It cannot update PHP, find a web shell, move secrets out of your web root or tell you whether your site was compromised. Do those with your hosting and security tooling, and use a one-time link for the moment one person gives another a new credential.