Two emergency PHP patches landed on 21 October, and the advice everywhere is the same: update now. That advice is right, and it is incomplete. The flaw lets an attacker run code as the account PHP runs under — so the question that follows the patch is what that account could read.
What happened
On 21 October 2026, the PHP project shipped emergency fixes for two critical PHP vulnerabilities in the engine itself, now widely called PHP2Shell: CVE-2026-109618 and CVE-2026-109619. Each is rated 9.2 on CVSS v4.0. Both are remote code execution flaws: either one can let an attacker who isn't logged in run code on a web server, simply by sending it crafted requests.
The flaws had sat in the PHP codebase for more than a decade. They were found by researchers at OpenAI, Wiz and Calif, working with Cloudflare and the PHP Foundation. The release was brought forward a day after the CVE numbers leaked.
The response has been unusually wide. The NSA urged organisations to prepare updates, national cyber agencies in the UK, EU, Canada, Australia and Singapore issued their own alerts, and some operators — the Wikimedia Foundation among them — took systems offline as a precaution. Amazon's threat intelligence team recorded an exploitation attempt on 17 October, four days before disclosure, and public proof-of-concept code is already circulating.
Patching comes first. But the detail that matters most for the days after is easy to miss: the attacker's code runs as the account PHP runs under. Whatever that account can read, the attacker can read too.
Am I affected?
If a server runs PHP and answers web requests on a version below the fixed release for its branch, assume yes. That includes every WordPress site: WordPress itself isn't the vulnerability, but it runs on whatever PHP version your host provides.
| PHP branch | Affected | Fixed in |
|---|---|---|
| 8.5 | Below 8.5.12 | 8.5.12 |
| 8.4 | Below 8.4.27 | 8.4.27 |
| 8.3 | Below 8.3.36 | 8.3.36 |
| 8.2 | Below 8.2.35 | 8.2.35 |
| 8.1 and older | End of life | No fix from the PHP project |
End-of-life versions are the hard case. PHP 8.1, 8.0, 7.x and 5.x get no upstream patch, and they are still widely deployed on internet-facing servers. PHP 8.2 joins them when it reaches end of life on 31 December 2026, so a server patched to 8.2.35 today still needs an upgrade plan.
What to do today
- Patch internet-facing servers first, then everything else.
- Restart PHP-FPM or the web server after updating, so running workers load the fixed version.
- Plan the end-of-life systems. Upgrade to a supported branch, or use a vendor that back-ports fixes, until you can.
- Don't rely on a WAF rule or config change alone. PHP says updating is the only complete fix.
That closes the door. The next section is about what may already have walked out of it.
The part patching doesn't fix
Most breaches aren't break-ins. They're logins. PHP2Shell is a genuine break-in — but what an attacker does next usually is a login, with credentials taken from the server they broke into.
A typical PHP web server can read far more than its own code:
- Database passwords hardcoded in
wp-config.php,.envor a config file — often for an account that can read and write every table. - Cloud access keys for storage buckets, queues or email services.
- API tokens for payment providers, CRMs and third-party apps.
- SMTP credentials that can send mail as your domain.
- SSH keys or deploy tokens left on the box by a build pipeline.
This is secrets sprawl: hardcoded credentials scattered across servers, config files and pipelines, each one a working key for whoever reads it. None of them change when you patch. If someone ran code on an unpatched server — and attempts were seen from 17 October — they may still hold working credentials after the fix is in. These are machine identities, or non-human identities, and they're the ones nobody remembers to rotate.
An identity checklist for PHP2Shell
- List what the PHP account can read. Config files, environment variables, mounted secrets, keys in the web root. That list is your exposure.
- Start credential rotation on any internet-facing server that was unpatched after 17 October. Patching closes the hole; rotating every secret the PHP account could read makes anything already taken useless.
- Cut the database account down to what the app needs. Most web apps don't need to drop tables or create users.
- Use secrets management, not config files. Fetch credentials at runtime from a secrets manager (CyberArk Credential Provider or Conjur, Keeper Secrets Manager, or one of the HashiCorp Vault alternatives), so there is nothing useful sitting on disk to steal — and rotation becomes a setting, not a project.
- Prefer short-lived credentials. Cloud instance roles and tokens that expire in minutes are worth far less to an attacker than a key that lasts for years — the same idea behind zero standing privileges.
- Watch where those credentials are used. A database login or API call from somewhere new is often the first sign that something was taken.
FAQ
What is PHP2Shell?
PHP2Shell is the nickname for two critical remote code execution flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, disclosed and patched on 21 October 2026. One is triggered by how PHP handles running out of memory mid-request; the other by internal state that outlives the memory behind it.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Versions 8.1 and older are end of life and get no fix from the PHP project.
How do I check my PHP version?
Run php -v on the server, or check your hosting control panel. The command line can report a different version from the one serving your website, so confirm the web server's version too — your host can tell you, or a temporary phpinfo() page will (delete it straight after).
What is remote code execution?
Remote code execution (RCE) is a vulnerability that lets an attacker run their own commands on a system over the network. With PHP2Shell, no login is needed — and the commands run with the permissions of the PHP account.
Is PHP2Shell being exploited?
Exploitation attempts have been reported, including one Amazon recorded before disclosure, and public proof-of-concept code exists. How many systems were actually compromised isn't yet known.
Is a WAF enough?
No. WAF rules and config changes can block some known paths, but PHP says updating is the only complete fix.
If we've patched, do we still need to rotate credentials?
For internet-facing servers that were unpatched after 17 October, yes. Patching stops new attacks; it does nothing about credentials that may already have been copied.
What is secrets management?
Secrets management is the practice of storing, controlling, rotating and auditing machine credentials — passwords, API keys, tokens, certificates — in one secured system, instead of leaving them in code and config files. Applications fetch what they need at runtime, so a compromised server doesn't hand over keys that last for years.
Know what your servers can reach
Applied IAM's engineers deploy and run privileged access and secrets management for a living, certified across CyberArk, SailPoint, CISSP and Security+. If you're evaluating where your web servers' secrets live, or which credentials to rotate first after PHP2Shell, book a 30-minute call. We'll help you map it.
Sources: PHP security advisories; reporting by CNBC, CNN/ABC7, Help Net Security, Tenable, watchTowr and Recorded Future, 21–22 October 2026.
