eMudhra compromised intermediate CA keys: what PHP servers need to check

What happened

• On 17 October 2026 a researcher reported that eight eMudhra intermediate CA certificates (six TLS, two code signing) had P-384 private keys that were integers below 256: 4, 56, 66, 115, 155, 156, 230 and 237. Mozilla confirmed that each key was zero in every byte except the last (Bugzilla 2083449).
• eMudhra says the keys came from an April 30, 2025 key ceremony on FIPS 140-2 Level 3 HSMs, where a wrap/unwrap step produced a second, weak set of keys that were then published by mistake.
• The TLS intermediates chain to emSign ECC Root CA - G3. Sectigo’s AAA Certificate Services root had cross-signed the same keys; Sectigo revoked those cross-signs on 19 October.

Is my PHP server affected?

PHP does not ship a CA list of its own. The openssl and curl extensions read openssl.cafile / curl.cainfo when set, and otherwise the default paths compiled into OpenSSL, normally the distribution’s ca-certificates bundle. Neither consumes Chrome’s CRLSet or Firefox’s OneCRL. Your server still trusts the compromised chain if that bundle still contains emSign ECC Root CA - G3 (or, for the cross-signs, AAA Certificate Services) and nothing else blocks the intermediates.

# Which CA file does PHP use? Run as the same user/SAPI as the site if you can.
php -r 'print_r(openssl_get_cert_locations());'
php -i | grep -E 'openssl.cafile|openssl.capath|curl.cainfo'

# Does PHP still trust the compromised eMudhra intermediates?
# Good result: bool(false) plus a "certificate verify failed" warning.
# Bad result: the page body is printed (the chain was trusted).
php -r 'var_dump(file_get_contents("https://dv-g3b-emudhra.we-have-a-problem.com/"));'
php -r 'var_dump(file_get_contents("https://dv-g3b-aaa-emudhra.we-have-a-problem.com/"));'

# Same check through the curl extension
php -r '$c = curl_init("https://dv-g3b-emudhra.we-have-a-problem.com/");
curl_setopt($c, CURLOPT_RETURNTRANSFER, true);
var_dump(curl_exec($c), curl_error($c));'

# Is the eMudhra root still in the bundle?
ls /etc/ssl/certs | grep -i emsign            # Debian/Ubuntu symlinks
grep -n "emSign ECC Root CA - G3" /path/to/cacert.pem   # curl/Mozilla-format bundle
# composer/ca-bundle version inside a project
composer show composer/ca-bundle | grep versions

Run the checks for each SAPI that matters. PHP-FPM and Apache mod_php can load a different php.ini from the CLI, so compare php --ini with a phpinfo() page served by the site.

How to fix it

# Debian / Ubuntu (and Debian-based php:* Docker images)
sudo apt-get update && sudo apt-get install --only-upgrade ca-certificates
dpkg -l ca-certificates

# RHEL / Fedora / AlmaLinux / Rocky
sudo dnf upgrade ca-certificates

# Alpine (php:*-alpine images)
apk upgrade --no-cache ca-certificates

# Composer projects that ship composer/ca-bundle
composer update composer/ca-bundle    # 1.4.16+ or 1.6.0+

# Restart long-running PHP processes afterwards
sudo systemctl restart php8.3-fpm     # or apache2 / httpd / your queue workers

; php.ini — for stacks with their own stale bundle (XAMPP, WAMP, old panels)
; Download a current Mozilla-derived bundle from https://curl.se/ca/cacert.pem
; (the 2026-10-20 release or later), then point both settings at it:
curl.cainfo   = "/path/to/cacert.pem"
openssl.cafile = "/path/to/cacert.pem"
; Restart Apache / PHP-FPM so the new values load.

Older all-in-one stacks and long-unpatched panels often pin curl.cainfo to a file that ships with the product and is never refreshed. Check the vendor’s release notes for an updated bundle, or point php.ini at a current cacert.pem as shown.

Who has shipped a fix

NSS 3.131.1 removes emSign ECC Root CA - G3. We fetched curl’s live cacert.pem (Last-Modified 20 October 2026) and it contains neither emSign ECC Root CA - G3 nor AAA Certificate Services. composer/ca-bundle 1.4.16 and 1.6.0 also add CaBundle::findDistrustedCertificate to flag the compromised intermediates in a chain.

Releases not in this list, including older distributions such as Ubuntu 20.04 or Debian 11, were not shown as patched on the sources we reviewed. Check your vendor’s tracker rather than assuming.

FAQ

Bundled stacks and hosting panels

XAMPP and hosting panels ship their own PHP builds, so their CA bundle may not follow the operating system’s ca-certificates updates. Check the product pages for XAMPP, cPanel, Plesk, DirectAdmin, CloudLinux, aaPanel and 宝塔面板, or the full product list.