Hey there!

This week two separate security stories took over Hacker News. The first is PHP2Shell, a pair of critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that can let an attacker run their own code on a web server without logging in. The second is the eMudhra certificate compromise, where the private keys behind eight trusted certificate authorities turned out to be so weak that anyone could work them out.

The two aren't technically connected. They just broke in the same 48 hours, 20 and 21 October. Both are worth understanding, though, because the fix for each depends on software most of us never think about. In this post I'll go through what each flaw is, who's affected, and what you should update.

What PHP2Shell is

PHP runs a huge share of the web. W3Techs puts it on roughly 69% of websites whose server-side language is known, and that includes every WordPress site. So a bug in PHP itself, rather than in one plugin or app, is a big deal.

PHP2Shell lives in the code that sets up and cleans up every web request. In plain terms, the attacker sends a carefully built upload that makes PHP run out of memory at exactly the wrong moment. PHP's cleanup then leaves half-built data lying around and treats it as valid, and a later request on the same worker uses that mess to run the attacker's code. The second bug is a "use-after-free": memory that has already been released gets used again. Researchers say it can also leak secrets from a worker's memory even when it doesn't lead to full code execution.

What makes this one worse than past PHP scares is how little it needs. The well-known 2024 bug, CVE-2024-4577, only worked on Windows with particular language settings and CGI mode. According to the researchers at Calif, PHP2Shell works on default settings on ordinary Linux servers. PHP lists PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as affected, and rates mod_php the riskiest because the exploit fires before any application code runs.

PHP scores both bugs 9.2 on the CVSS v4.0 scale. You may have seen "CVSS 10.0" on social media; that came from posts made before the official release and isn't the official rating.

How it was found, and why the patch came early

Ryan Austin of the security firm Calif found the first bug using AI-assisted code review and reported it to PHP on 11 August. Wiz Research and OpenAI's Codex Security team are also credited. PHP had planned to release fixes on 22 October, but the CVE IDs leaked online on 20 October, so the release was pulled forward a day.

Whether attackers are already using it depends on who you ask. Amazon says it saw a first exploitation attempt on 17 October, four days before the fix, and now describes PHP2Shell as broadly exploited. Cloudflare reports early attacks too. On the other side, CISA, Huntress and the PHP Foundation said at release that they hadn't confirmed any successful compromise, and neither CVE was in CISA's Known Exploited Vulnerabilities catalog as of 22 October. So attempts are real, while confirmed break-ins are still disputed.

The real problem with PHP2Shell: old versions

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Many servers run something older. PHP 7.4, 8.0 and 8.1 only got minimal source-code fixes that you'd have to build yourself, and 5.4 to 7.3 get nothing at all. VirusTotal counted about 758,000 exposed servers on those unsupported versions, against about 272,000 on supported ones. For most of those machines the only real fix is an upgrade.

What happened with eMudhra

eMudhra is an Indian certificate authority, a company trusted to vouch that a website or a piece of software is who it says it is. When your browser shows a padlock, a chain of certificates like these is behind it. The keys at the top of that chain have to stay secret, because whoever holds one can issue certificates that software will trust.

A P-384 private key, the kind eMudhra used here, should be a random number with over a hundred digits. Eight of eMudhra's intermediate certificate keys were numbers below 256. As The Register pointed out, one of them was literally the number 4. Six of these intermediates issue website (TLS) certificates and two issue code-signing certificates, all under a root called emSign ECC Root CA - G3.

eMudhra traces the problem to a key-generation ceremony on 30 April 2025. It says a step on its hardware security modules created a second, weak key pair, which was used by mistake because the key labels looked alike, though it says the exact root cause isn't confirmed yet. Either way, the weak keys sat there for about 18 months, through two audit cycles. This was an operational failure, not a bug in an eMudhra software product.

How the eMudhra keys were caught, and who's still exposed

An independent researcher credited only as "Wayne" reported it to Apple, Google, Microsoft and Mozilla on 17 October. As proof, he signed the message "We have a problem here - Wayne" with each of the eight keys. Security researcher Scott Helme later recovered the keys in under a second on a laptop, as he explains in his write-up of the eMudhra key compromise.

Browsers moved fast. Chrome and Firefox blocked the eight certificates the same evening, Apple followed on 19 October and Microsoft on 20 October. Chrome removes the G3 root entirely from 27 October. Google says it found no website certificates from these intermediates in the public Certificate Transparency logs, and India's CERT-In says there is no confirmed malicious use. eMudhra and India's IT ministry also say the digital signatures used for Indian tax filings and eSign are unaffected.

The risk that's left sits in everything that isn't a browser. Helme showed that a forged certificate for api.stripe.com was accepted by curl, Python and Node with default settings. Those tools trust a list of certificate authorities stored on disk, and they don't check the Transparency logs, so they only stop trusting eMudhra once that list is updated. Go programs have to be rebuilt with a fixed Go version, and Docker images only pick up the fix when they're rebuilt on fresh base images.

The takeaway

The common thread here isn't a shared exploit. It's that both flaws were old and sat unnoticed: a PHP bug class going back years, and certificate keys that were guessable for 18 months. Both came to light through AI-assisted research, and in PHP's case Amazon saw an exploitation attempt four days before the fix.

If you run anything on PHP or handle servers, this is the short list from this week:

• Upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every PHP worker. Updating WordPress or a plugin won't help, because the bug is in PHP itself. If you're on shared hosting, ask your host which version you're on. The full details and temporary mitigations are in PHP's security advisory.
• Update your browser, and update the certificate bundles your code relies on: language runtimes like Node and Java, Python's certifi, your operating system's ca-certificates package, and Go (then rebuild).
• Rebuild container images on fresh base images, and check apps and devices that ship their own certificate list.
• If a new certificate error shows up, never fix it by turning off verification.

For everyday browsing, you're already covered once your browser updates. The work that's left is in the servers, pipelines and old PHP installs that only change when someone goes in and updates them.