Compromised eMudhra Certificates and a Critical PHP Flaw Put Site Operators on Alert

Two severe internet security flaws have surfaced together, according to security releases seen by Ars Technica. One involves TLS certificates protected by extremely weak encryption, which could affect VPNs and IoT devices. The other is a severe PHP flaw that reaches content management systems including WordPress and Drupal (Engadget).

India-based eMudhra said eight of its intermediate CA certificates were compromised. Intermediate certificates sit between a trusted root authority and the certificate a web server presents, so they inherit trust from the root. The company said these eight chain to roots trusted by the Mozilla, Microsoft, Apple and Chrome root programs. The private keys behind the affected certificates were only three to eight bits long, against the usual 384 bits. A 384-bit key has far too many possible values to search, whereas a key of three to eight bits has only a few hundred at most, so recovering it means testing a very small number of candidates. eMudhra revoked the eight certificates and attributed the fault to a script used to generate them (Engadget).

The browser response has been staggered. Google Chrome blocked the intermediates on October 17, 2026, and Apple followed on October 19, 2026 (LWN.net). Mozilla blocked them as well and published a security post on October 20, 2026 (Mozilla Security Blog). That post states that an attacker able to intercept a user's connection could use the compromised certificates to impersonate websites and potentially read or modify traffic. Mozilla's Bugzilla record for the incident, bug 2083449, includes an update dated October 18, 2026, which logs the eight certificates as revoked on the CRL with reason caCompromise, with revocation times varying by certificate (Mozilla Bugzilla). Apple's trusted root documentation says blocked certificates are believed to be compromised and will never be trusted (Apple Support).

Mozilla security expert Dennis Jackson warned that a macOS utility may continue to trust the compromised eMudhra certificates, because it does not check for revocation information (Engadget).

In my view, that detail matters most for anyone whose tooling relies on the operating system's trust decisions rather than a browser's. Revocation checking is a known weak point in the public key infrastructure, and a utility that skips it will keep accepting a chain that browsers have already rejected. The two stories are different halves of one problem. The certificate trust model worked as designed once the defect was visible, but the long tail of software that makes its own trust decisions is where the gap sits.

The PHP issue is a separate thread with a tighter clock. The PHP Foundation said it was releasing security patches for two critical PHP vulnerabilities, each rated 9.2 out of 10 in severity, scheduled for 14:00 UTC on October 21, 2026 (Engadget). Security firm watchTowr said it confirmed the PHP vulnerability and that it affects every PHP version from PHP 5 (2004) onward. A tool called PHP2Shell was shown running code on web servers, including the latest versions of WordPress, MediaWiki, Symfony and Drupal. Sansec said it expected mass attacks to begin within 15 minutes of the PHP security release (Engadget).

eMudhra's homepage describes more than 1,000 large enterprise customers, more than 100 million issued digital certificates, and active customers in more than 50 countries. Those figures give a sense of how far a compromised intermediate can reach.

The broader context here for PHP site operators is simpler. Patches exist, they are scheduled for release, and the attack tooling has been shown against major content management systems. Mass exploitation is forecast to begin quickly after release, so the gap between a patch becoming available and a patch being applied is the exposure that matters. Sites that auto-update core and plugins, or that can apply a PHP runtime update within hours, are in a stronger position than those waiting for a maintenance window.

In my view, there is also something encouraging in how quickly the ecosystem moved on the certificate side. Within days, three major browser vendors had acted on a compromised intermediate, and the incident was documented in public bug trackers and vendor advisories. That kind of coordination lets an error in one small certificate authority be contained without breaking the wider web.