Compromised certificate authority

Summary for merchants

There are a handful of companies who act as SSL autorities. One of them (eMudhra) used the password "4" and as a result, SSL (https) cannot be trusted until every server is updated. Otherwise, you cannot guarantee that your application is actually communicating with Stripe, Mollie, or any of your other suppliers.

Most servers will auto-update to remove eMudhra from their trusted list, however many applications ship their own trust-list. eComscan will inspect such lists and warn you if eMudhra is still there.

If eComscan alerted you about this, send this page to your developer or hosting provider and ask them to update the flagged bundles. Once they replace every flagged bundle, eComscan reports the alert as fixed.

Details

eMudhra generated the private keys of eight of its intermediate 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 flaw has been present since the intermediates were created in April 2025.

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.

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.

Affected bundles

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.

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 each vulnerable bundle file separately, with its path. If 40 sites on your server run the same WordPress version, the report lists 40 files. Deploy tools such as Deployer and Capistrano put each deploy in a new release directory. Until you deploy a fixed bundle, eComscan reports the bundle in each new release directory as a new issue.

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