The patch closes the door. It doesn't recover the credentials that already left through it.
Roughly seven in ten websites run on PHP. An unpatched PHP server can be broken into with one web request and no password. That hole has been there for 14 years, and attackers reached it before the patch did.
The flaw is PHP2Shell: two critical vulnerabilities in the PHP runtime itself, CVE-2026-109618 and CVE-2026-109619. The fix shipped on October 21, 2026, four days after the first exploitation attempts were seen. PHP sits behind 69% of websites whose server-side language is known.
Upgrading PHP is the easy part. The hard part is what attackers already took: database credentials, API keys, session tokens and personal data, each still valid until someone rotates it. Treat every secret the server could read as stolen, including any it fetched from a vault.
A vault with automated rotation makes the cleanup fast. Without one, it is slow, manual work. Either way, rotation fixes the stolen credentials and does nothing about the other two problems. The leaked personal data will fuel targeted phishing and identity attacks for months, and breaches will spread from organizations that patched late to those that depend on them.
This is the first week of a long event.
Critical web vulnerabilities surface most weeks, and most of them don't deserve the label "dangerous". PHP2Shell does, for four reasons.
With Apache mod_php, PHP is embedded in the web server itself. On those servers the exploit fires while PHP is still parsing the request, before any application code runs. PHP-FPM and other setups are affected too, under extra conditions.
The danger: the attack is over before your login page, your multi-factor check or your application's logging is reached. It can succeed and leave no trace where you would normally look.
PHP's advisory for CVE-2026-109619 lists memory disclosure as a confirmed impact. The process that handles requests keeps credentials, tokens and session data from earlier requests in memory, and an attacker can read it without dropping a file or running a command.
The danger: There may be no web shell to find. An investigation that finds nothing has not shown that nothing was taken. Rotate the server's credentials anyway.
Amazon's threat intelligence team saw the first exploitation attempt on October 17, 2026. The CVE identifiers leaked on October 20, 2026, so PHP released the fix a day early. Proof-of-concept exploits were circulating hours before the planned release, and Amazon now describes PHP2Shell as broadly exploited in the wild.
The danger: A server patched the day the fix shipped may already have been compromised, and the gap between disclosure and mass exploitation was hours, not days.
Calif Research, the firm that found the bugs, traces the earliest affected code path to PHP 5.4.0, released in 2012. A related flaw surfaced in a 2024 audit, but nobody proved it exploitable, so nobody fixed it.
The danger: 14 years of PHP releases are exposed, and more than a third of PHP-powered sites run PHP 7 or older, branches that will never get an official fix. Those servers stay exploitable for months.
Next to the PHP code on a typical server: a config.php with the database password. A .env file with API keys, cloud access keys, mail credentials and OAuth client secrets. Process memory holding the tokens and personal details of whoever was signed in. The PHP process reads all of it, so an attacker whose code runs inside that process can too.
With those secrets, the attacker no longer needs the vulnerability. Every login looks like legitimate traffic, and none of it trips a detection written for the PHP flaw. The vulnerability was the entry. The identities are the payload. A PHP vulnerability becomes an identity problem.
This is a forecast, based on how credential theft has played out before.
Wave 1 is now and runs for weeks. Automated exploitation of anything unpatched. Web shells and cryptominers installed. Config files and environment variables harvested at scale. Active sessions hijacked.
Wave 2 starts within a week and continues for months. The harvested credentials are used: database logins from new places, cloud keys to pull data and OAuth secrets to mint tokens for SaaS applications. None of it requires an exploit, and all of it appears to be authorized access.
Wave 3 runs for months or more. Leaked personal data and session details fuel targeted phishing and account takeover against your customers and employees. Some organizations will be breached through a vendor, partner or SaaS provider that ran PHP, patched late and rotated nothing. Their incident becomes yours.
The Cybersecurity and Infrastructure Security Agency (CISA) has urged immediate patching but, at the time of writing, hasn't listed either CVE as known to be exploited. That is not a reason to wait; the first attempts came before any detection signature existed.
In the next hours. Find every place PHP runs, including appliances that bundle it. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor's backported package; there is no complete workaround. Isolate anything you can't patch. Investigate from October 17, not the disclosure date.
In the next days. Assume any secret the server could read is in someone else's hands. Inventory them, rotate them starting with the ones that reach the most systems, and invalidate active sessions. Then audit the systems those credentials open for use you didn't authorize.
In the next months. Change what a web server is allowed to hold. Static secrets in files on an internet-facing host are standing privilege. Move them into a vault that rotates them automatically. Give applications and services just-in-time access scoped to the task, so a stolen credential stops working quickly and reaches only what the task needs. Put phishing-resistant authentication in front of the people who will be targeted. Ask your vendors which of these they've done.
If a credential is stolen, the damage should stop at that credential. The Delinea Platform is built for that outcome; it limits how far an attacker can move and what they can reach if they get in.
Credentials are vaulted and rotated automatically, and in brokered sessions they are injected at the proxy at the moment of use, so database passwords and API keys no longer live in config.php or .env. Access is granted just-in-time, scoped to the task and revoked when it's done. Each privileged action is authorized as it happens and tied to a named identity, so when the board, auditors or regulators ask what happened and why it was allowed, you have an answer.
Patch today, then treat the patch as the beginning. Exploitation started before disclosure, so patching does not mean the attacker is gone, nor does it restore a single credential that was stolen. This is week one. Plan for the year.
See how the Delinea Platform vaults and rotates the credentials PHP2Shell exposes.
A note on Delinea: Delinea products and services do not use PHP and are not affected by these vulnerabilities. Read it in full at the Delinea Trust Center.