Compromised eMudhra certificate authorities

eMudhra generated the private keys of eight of its intermediate certificate authorities (CAs) incorrectly, so anyone can recover them from the public certificates. With those keys, an attacker can issue a valid HTTPS certificate for any domain, such as api.stripe.com or api.mollie.com. The eMudhra intermediate CA compromise was made public on October 20th 2026.

Firefox, Chrome, Safari and Edge blocked the eight intermediates between October 17th and 20th. Those browser updates do not cover PHP. Its curl and OpenSSL extensions accept any certificate that chains to a root in a CA bundle file on disk, and they do not check revocation.

eComscan alerts when a CA bundle on your server still trusts the compromised intermediates. This can be the system bundle of your Linux distribution, or a bundle that is shipped inside your store code.

Risk for ecommerce stores

Your store calls the APIs of payment providers, shipping services and ERP systems over HTTPS. An attacker who can intercept that traffic can present a forged certificate for the API hostname, and PHP will accept it. The attacker can then read the API secret keys and customer data in your requests, or send back forged responses, such as a payment confirmation for an unpaid order.

To intercept traffic, the attacker needs a position on the network path between your server and the API, for example a compromised router at your hosting provider or a poisoned DNS resolver. The attacker does not need access to eMudhra to forge a certificate. The flaw has been present since the intermediates were created in April 2025.

Affected bundles

A CA bundle trusts the compromised intermediates if it contains one of these roots:

eComscan checks the system bundle (/etc/ssl/certs/ca-certificates.crt, /etc/pki/tls/certs/ca-bundle.crt and similar paths) and every file in your store named cacert.pem, cacerts.pem, ca-bundle.crt, ca-bundle.pem or ca-certificates.crt. The alert names the root that the bundle contains.

eComscan reports identical copies of a bundle as one alert. If 40 sites on your server run the same WordPress version, or every deploy directory contains the same vendor tree, the alert shows the number of identical files and the path of one of them. A new deploy with the same bundle does not trigger a new alert. Once you replace every copy with a fixed bundle, eComscan reports the alert as fixed.

These bundles in ecommerce code override the system bundle for live API calls:

Fixing the system bundle

Update the ca-certificates package to the fixed version for your distribution:

# Debian and Ubuntu
apt-get update && apt-get install --only-upgrade ca-certificates

# Alpine Linux
apk upgrade ca-certificates

# Fedora
dnf upgrade ca-certificates

At the time of writing, the latest packages for RHEL 9 and its rebuilds (ca-certificates 2025.2.80_v9.0.305-91.el9) and for Amazon Linux 2023 still trust emSign ECC Root CA - G3. On RHEL, Rocky Linux, AlmaLinux and Amazon Linux 2023, run the following as root to distrust the Comodo AAA Services root and emSign ECC Root CA - G3 until your vendor ships a fix:

d=/etc/pki/ca-trust/source/blocklist; [ -d $d ] || d=/etc/pki/ca-trust/source/blacklist
trust extract --overwrite --format=pem-bundle \
  --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' \
  $d/Comodo_AAA_Services_root.pem &&
trust extract --overwrite --format=pem-bundle \
  --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \
  $d/emSign_ECC_Root_CA_-_G3.pem &&
update-ca-trust

Your server will then reject every certificate issued under these two roots. The fixed packages for Debian, Ubuntu and Alpine Linux remove the same roots.

Fixing bundles in your store code

For Composer-based stores, run composer update composer/ca-bundle to get a fixed version.

WordPress and the Stripe PHP library have not released a fixed bundle yet. Until they do, replace their bundle with the current Mozilla bundle from curl.se:

cd /path/to/your/store
curl -o wp-includes/certificates/ca-bundle.crt https://curl.se/ca/cacert.pem
curl -o vendor/stripe/stripe-php/data/ca-certificates.crt https://curl.se/ca/cacert.pem

A WordPress update or composer install puts the vendor's copy back. If that copy is still the old one, eComscan will alert again and you need to repeat this step. Security plugins that compare core files against the WordPress release, such as Wordfence, will report ca-bundle.crt as modified.

Checking a server yourself

Run this on your server to test the default bundle of curl and PHP:

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo VULNERABLE
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo VULNERABLE
php -r 'echo @file_get_contents("https://dv-g3b-emudhra.we-have-a-problem.com/") === false ? "OK\n" : "VULNERABLE\n";'

A certificate error means the bundle no longer trusts the compromised intermediates. To test a specific bundle file, use the certificate chains from the disclosure site:

curl -sO https://emudhra.we-have-a-problem.com/chains.zip && unzip -oq chains.zip
for f in chains/dv-g3b-emudhra.we-have-a-problem.com.pem chains/dv-g3b-aaa-emudhra.we-have-a-problem.com.pem; do
  openssl verify -CAfile wp-includes/certificates/ca-bundle.crt -untrusted $f $f
done

If OpenSSL prints OK, the bundle still trusts the compromised intermediates.

More information

• Disclosure site, with patched versions of other software
• Mozilla incident report
• Mozilla dev-security-policy thread