PHP released fixes on October 21 for two flaws that are already being exploited. Together they are being called PHP2Shell, and both carry a CVSS score of 9.2. The technical detail matters less than one consequence of how they work: the attack lands before your application sees the request, so the password on your admin page is not standing between an attacker and your server.
What PHP2Shell is
Two separate bugs, tracked as CVE-2026-109618 and CVE-2026-109619. The first is a flaw in how PHP handles running out of memory, which leaves invalid data behind for its cleanup routines to work on. The second lets a worker process reuse state left over from an earlier request.
Both can lead to remote code execution, which means an attacker running their own commands on your server. Researchers also report memory disclosure alongside it, so passwords, session tokens and API keys held in memory can be read out.
PHP patched them on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches are affected too, and the fix for those is to move to a supported release.
Why the password on your admin page does not help
This is the part worth understanding, because it breaks the usual reassurance.
Datadog's analysis found that application-level authentication cannot block the attack. PHP processes the malicious request before any of your application code runs. Your login form, your admin password, your role checks and your user permissions all sit downstream of the vulnerable code.
So "that system is locked down, only staff can get in" is not an answer here. Neither is "it is only an internal tool". If the server is reachable and running an unpatched PHP, the gate is behind the problem rather than in front of it.
You are probably running PHP somewhere
Most businesses do not think of themselves as having PHP. They think of themselves as having a website.
PHP is underneath a great deal of ordinary business software. A marketing site on WordPress. Anything on shared or cPanel hosting. A customer portal or quoting tool a vendor built years ago and still maintains. The web admin interface on a piece of hardware in your comms cabinet.
The way to find it is not to ask who uses PHP. It is to list everything that serves a web page on your behalf, including the things somebody else hosts for you, and then ask what each one runs on.
What to do this week
Build that list, then get a version number for each item on it. For anything a third party hosts, ask them in writing which PHP version you are on and when they patched.
Upgrade anything you control to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or later on whichever branch you are on.
If you genuinely cannot patch something straight away, PHP published interim workarounds, including a per-worker memory limit for one flaw and turning off the session upload progress feature for the other. Treat those as a way to buy a few days, not as a fix.
Because these flaws can expose memory, treat any server that was reachable and unpatched as one whose secrets may have been read. Rotate the credentials and API keys it held. That step gets skipped often, and it is the one that turns a patched server into a safe one.
When to call someone
If it takes you more than a day to find out which PHP version your website runs, that delay is the real finding. The patching is routine. Not knowing what you have is the problem underneath it, and it will be the problem again at the next advisory.
An inventory of what you run, who hosts it and who is responsible for patching it is a one-time piece of work that pays for itself the first time something like this lands. If nobody owns that list at your organization, that is worth a conversation before the next one arrives.
