Two things happened this week that every company running a website should care about, and both come down to PHP2Shell, security headers, and what sits between them. On Tuesday, a working exploit for two unpatched bugs in PHP itself leaked online. PHP runs WordPress, Drupal, Joomla and most of the rest of the web. On the same weekend, a certificate authority called eMudhra admitted that anyone in under a second could recover the private keys for eight of its signing certificates. One of those keys turned out to be the number 4.
Both stories have an AI angle, and both raise the same question I get from clients: “We installed your security headers plugin. Are we covered?” The honest answer is no for the break-in and yes for part of what comes after. Here’s why.
What PHP2Shell is
The two bugs are tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 out of 10. Both let an attacker run code on your server without logging in. PHP released fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything older than 8.2, which the PHP project no longer supports, gets no official fix.
The flaw lives in how PHP cleans up after it runs out of memory while reading a request. An attacker sends a file upload designed to push PHP past its memory limit. PHP aborts the request without finishing its housekeeping, and the next request that hits the same worker process inherits leftover pointers from the crashed one. From there the attacker can read chunks of server memory, including other visitors’ session tokens and API keys, or write to it and take over the process. The vulnerable code dates to PHP 5.4, released in 2012. It sat there for fourteen years.
Wiz Research found it, and they are open about how. They used frontier AI models to locate the bugs, build the exploit chain, and adapt it to WordPress, Drupal and Joomla in hours. Their own write-up says one researcher did in a week what a world-class team would have needed months to do. That’s the part that should change how you think about risk. For a decade the defense against this bug was that nobody could figure out how to use it. AI removed that defense. Once the proof of concept leaked a day early, automated scanners started sweeping the internet for PHP servers within hours.
What happened at eMudhra
A certificate authority is one of the companies your browser trusts to vouch for websites. When you see the padlock, a CA signed a certificate saying this server is who it claims to be. eMudhra generated a batch of intermediate signing certificates in April 2025 with a faulty script. The private keys came out tiny. A researcher found the problem on October 17 by scanning the public certificate database, and another researcher published one of the keys on GitHub to prove the point.
Anyone holding one of those keys could have minted a certificate for google.com, or for your site, that every major browser would accept. Mozilla, Google and Apple blocked the certificates within days. eMudhra revoked them on October 18 and says none of the eight ever issued a certificate to a customer. Chrome’s Certificate Transparency logs back that up, since no certificates chaining to those intermediates were ever logged. So the practical damage appears to be nil. The lesson is still worth taking: the trust your padlock represents depends on a lot of other people getting their key ceremonies right.
PHP2Shell and security headers: where they fit, where they don’t
Our Advanced Security Headers plugin sets the seven HTTP response headers that tell a visitor’s browser how to behave on your site: Content Security Policy, Strict Transport Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the Cross-Origin set. Those headers travel from your server to the browser. They are instructions for the browser.
PHP2Shell works in the other direction. The attacker sends a crafted request to your server, and PHP mishandles it before your application, your theme, or any plugin runs a single line. The browser never enters the picture. A response header cannot stop a request from being parsed. Any vendor telling you their header plugin blocks PHP2Shell is selling you something.
The eMudhra case is similar. A forged certificate from a trusted CA passes every check a browser runs, and HSTS only forces the browser to use HTTPS. It does not tell the browser which certificate to expect. There used to be a header for that, called HTTP Public Key Pinning, and browsers dropped it years ago because sites kept locking themselves out. What caught eMudhra was Certificate Transparency, which is enforced by browsers and CAs, with no help from your server.
What the headers do protect
Getting code execution on a server is step one for an attacker. Step two is making money from it, and on a typical business website that means injecting JavaScript into your pages. Card skimmers on checkout pages. Redirects to scam sites. Fake login overlays. Crypto miners. This is where Content Security Policy earns its place.
A strict CSP tells the browser which scripts may run and where data may be sent. Injected inline script that doesn’t carry the right nonce or hash gets blocked. A skimmer that tries to post card numbers to an attacker’s domain gets blocked, and the browser reports the attempt back to the plugin’s violation dashboard. Frame restrictions stop someone wrapping your compromised page inside a phishing lure. None of that undoes the break-in. It does take the easy payout off the table.
The reporting side matters as much as the blocking side this week. Wiz notes that PHP2Shell runs below the application layer, so your WordPress logs may show nothing useful. A spike in CSP violations from a domain you’ve never heard of is often the first visible sign that a script got injected. Advanced Security Headers logs every violation with counts over 24 hours, 7 days and 30 days, and it can email you when the rate jumps. Learning Mode runs CSP in report-only for a week or two first, builds the policy from what your site loads, and only enforces when you say so, which is why it won’t take a working site down.
One caveat applies. An attacker who fully owns your PHP process can change the headers too. In practice most mass-exploitation campaigns are automated and lazy; they drop a payload and move on to the next of 22 million exposed servers. A strict policy defeats the lazy payload. Installing the plugin as a Must-Use plugin, which we recommend, keeps it loading even if the regular plugin list gets tampered with. If you want the headers to survive a determined attacker, mirror them at your CDN or edge as well, which is a conversation we’re glad to have.
What to do today
- Find out what PHP version each of your sites runs. In WordPress, Tools, Site Health, Info, Server shows it. If it is below 8.2.35, 8.3.36, 8.4.27 or 8.5.12, update now or ask your host when they will.
- If you’re on PHP 8.1 or older, you have no official fix. Ask your host for a backported patch or move to a supported branch this week.
- Until you’re patched, set
session.upload_progress.enabled = 0in php.ini and restart PHP. PHP’s own advisory says this blocks the confirmed path for CVE-2026-109619. It breaks upload progress bars and nothing else most sites care about. - Rotate any API keys, tokens or passwords that live in server memory on sites that were exposed before the patch. The memory-disclosure half of PHP2Shell leaks exactly those.
- Run your domain through securityheaders.com. If CSP is missing or still in report-only, that is the gap between a break-in and a break-in with a skimmer attached. Advanced Security Headers closes it quickly for $99 a year per site.
For eMudhra, browsers already handled the client side. If you run your own servers or containers, update the ca-certificates package so your own outbound connections stop trusting the revoked root as well.
The bigger point
“My site is too small to be a target” was always a weak argument. This week it stopped being an argument at all. The people scanning for PHP2Shell are scripts, and scripts don’t know how small you are. The researchers who built the exploit used the same AI models your team uses to write marketing copy and debug code. Defense has to assume the attacker has those tools too.
That means patching on a schedule measured in hours, not quarters. It means layering protections so that one failure, in PHP or in a CA you’ve never heard of, doesn’t hand over the whole site. Security headers are one of those layers. They were never the wall. They’re what limits the damage once the wall has a hole in it.
If you aren’t sure where your sites stand on either of these, send us the list of domains and we’ll check PHP versions and header configuration and send back a one-page report.
Sources
- Wiz Research: PHP2Shell, AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
- Sansec: PHP2Shell, critical PHP RCE (CVE-2026-109618, CVE-2026-109619)
- Palo Alto Networks Unit 42: Threat brief on CVE-2026-109618 and CVE-2026-109619
- Huntress: Rapid response to the leaked PHP2Shell vulnerabilities
- Mattias Geniar: Early mitigation steps for CVE-2026-109618 and CVE-2026-109619
- Techzine: Why PHP2Shell affects every company
- Help Net Security: eMudhra security blunder left trusted CA signing keys exposed
- Google Chrome Root Program: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
- BleepingComputer: Mozilla, Google and Apple block compromised eMudhra CA certificates
