Incident Report

Security update: eMudhra certificate authority compromise

October 21, 2026. Status: resolved. No downtime.

S

Sitery Team

Northern Nevada

Summary

Eight intermediate certificates issued by the eMudhra certificate authority were found to have private keys that anyone could calculate. The eMudhra root was trusted by default in several places on the Sitery platform. We removed it from all of them. We have no reason to believe the keys were used against any Sitery site. There was no downtime.

Timeline

  • October 17: The weak keys are reported privately to browser vendors and eMudhra. Chrome and Firefox block the affected certificates within hours.
  • October 20: Mozilla discloses the issue publicly and removes the eMudhra root from Firefox.
  • October 21: Operating system vendors release certificate updates removing the root. Node.js ships the same change in its security release.
  • October 21: Sitery removes the root from every trust list on the platform.

Cause

A certificate authority’s private keys must be large random numbers. The eight affected eMudhra keys were single-byte values and can be recovered from the public certificates in under a second. Six of the certificates issue website certificates and two issue code-signing certificates. They had been in use since April 2025.

Anyone holding the keys can issue a certificate for any domain, and software that trusts the eMudhra root will accept it as genuine. An attacker able to intercept a connection could then read or change it without the software noticing.

Current web browsers are protected: they block the affected certificates directly and reject certificates missing from public Certificate Transparency logs. Most other software is not. Command-line tools, programming languages, package managers, build systems and devices trust a fixed list of certificate authorities, and most do not check whether a certificate has been revoked. They stay exposed until the root is removed from their list.

Exposure on Sitery

Three separate trust lists included the eMudhra root. In each case this was the vendor’s default, not a Sitery configuration:

  • The server operating system’s certificate list.
  • The list built into Node.js, used by the runtimes for Sitery Next.js sites. Node.js does not use the operating system’s list.
  • The list bundled with WordPress (wp-includes/certificates/ca-bundle.crt), used by each WordPress site for outgoing requests such as update checks.

Visitors to Sitery sites were not affected. Site certificates are issued by Let’s Encrypt and Google Trust Services.

What we did

  • Installed the operating system certificate update on every server and restarted the services that load the list at startup.
  • Removed the root from the bundled certificate list on every WordPress site.
  • Rebuilt the Node.js runtimes used by Sitery Next.js sites on releases without the root. See the Node.js report.

What you need to do

Nothing for sites hosted on Sitery.

This issue is not specific to hosting. Any computer or server you manage may trust the eMudhra root. Updating the operating system covers software that uses the system list, but not software that ships its own. Check and update:

  • Your operating system’s certificate package (ca-certificates on Linux).
  • Node.js: 22.23.4, 24.22.1, 26.12.1 or later.
  • Python projects using certifi, Java keystores, and other runtimes with their own list.
  • Container images. Rebuild them so they pick up the updated packages.
  • Build servers and CI runners, which download code and often hold deployment credentials.

Devices that cannot be updated, such as older routers, printers and appliances, will continue to trust the root until it expires in 2039.