The eMudhra compromise: getting every service to a verified fix

The hardest part of responding to eMudhra may be finding every piece of software that needs an update. Across a large engineering organization, that includes production services, old container images, and tools running inside CI.

A patch is only useful where it gets applied. Platform teams need to identify potentially affected software, get the required updates into use, and verify that nothing was left behind.

What happened

On October 20, 2026, researchers disclosed that the private keys of eight eMudhra intermediate certificate authorities had been compromised. These authorities help establish the trust behind digital certificates. An attacker with the affected keys could impersonate websites or services to clients that still accept their certificate chains.

Major browsers had already blocked the intermediates. The researchers also reported that Certificate Transparency requirements protected browsers enforcing those requirements. Many command-line tools, libraries, and other clients do not use the same protections. Those clients need their own updates. Whether attackers exploited the flaw remains unknown. The incident write-up tracks affected software and available fixes.

For platform teams, the response starts with the software estate: where affected certificate bundles, runtimes, and libraries may be in use, and who will update them.

Find what may be affected before counting fixes

If you haven’t accounted for your full software estate, your “100% scan coverage” claim is fiction.

Here’s the approach we recommend: start with the repositories and services the organization owns, then connect them to package inventories, build records, and deployed artifacts. Compare the relevant packages and versions with the incident’s remediation guidance. Waiting for scanners to raise findings can leave affected software out of the response while advisory coverage catches up.

The scope extends to software used to build and deliver applications, including sandbox images and CI pipelines that teams run outside the centrally managed platform. For example, a Python script in CI might use an old certificate bundle to download artifacts over HTTPS. Updating the production image would leave that script’s certificate bundle unchanged. The CI environment needs its own assessment and, if affected, an update.

Legacy services and unclear ownership make this work harder. Without current package evidence, teams cannot establish whether a service needs a fix. It stays in scope until someone can answer that question.

An unchanged Dockerfile can produce two different answers

Consider FROM debian:12. That line looks identical before and after an upstream image receives a patched certificate bundle.

An image built before the fix still contains the old files. Updating the base image upstream does not change containers already running. Teams need to rebuild with patched inputs and deploy the replacements. Docker’s guidance explains why images need regular rebuilding.

The operating system may not be the only copy to update. Runtimes and libraries can carry their own trust material. Go also released a certificate-verification fix, which means affected binaries need rebuilding with a patched Go release.

A busy service may get rebuilt this afternoon. A stable service with no planned changes may sit untouched. If your response depends on the next pull request, the second service can remain outside the conversation.

Turn the response into checks teams can act on

A guardrails engine gives platform teams a way to collect evidence across services, evaluate a shared requirement, and enforce it through engineering workflows.

Earthly Lunar provides that engine. It centrally collects and normalizes data from repositories and CI/CD, so a new requirement does not depend on each team adopting another pipeline template. Teams can build on existing collectors and guardrails, using Lunar’s AI skills to create custom checks for their requirements.

Lunar can sync repositories from a GitHub organization and import components and ownership from a catalog such as Backstage. Its collectors add repository, dependency, SBOM, and CI evidence, helping identify potentially affected components and gaps in coverage. That view still needs to be reconciled with deployed software, including older artifacts outside the connected systems.

For eMudhra, custom guardrails can check collected package and runtime evidence against the required fixed versions and give developers specific failure messages. Lunar includes guardrails for missing dependency and container scan data. Add freshness requirements alongside those checks to keep components awaiting assessment visible.

Platform can scope those guardrails by component, domain, or tags, then move from PR feedback to blocking at configured merge or release gates. The requirement applies across different build and release workflows, including within the same CI vendor.

A Lunar initiative groups related guardrails under an owner. Its results give platform and security a shared view of failures to work through. Affected services with no planned releases still need an owner and a deadline for rebuilding and redeploying; a release gate alone cannot fix software already running.

Make base-image updates explicit

Pinning a base image by digest gives you an exact image identity instead of a tag that can move. Let Renovate or Dependabot propose updates, and use guardrails to block noncompliant merges and releases until the required fixes are included. Test and deploy the rebuilt software.

A pin does not make an image safe, and an unchanged pin keeps selecting the old image. Docker recommends pairing digest pins with updates.

Lunar’s existing dependency-automation guardrails can check for Renovate or Dependabot configuration and whether Docker update rules are configured.

Verify the fix, then verify completion

Scanners provide another layer of verification. Lunar integrates with scanners including Trivy, Grype, and Snyk. Its Trivy and Grype integrations can scan images recorded as pushed by the Docker collector and rescan those references daily, bringing new findings to quiet services without a code change.

Measure how much of that estate your scanners actually cover, and how fresh the results are. Include older images and verify registry access. Require a successful scan of the artifact being released within your defined freshness window. A scan of today’s floating tag may describe different bytes from the image running in production.

The gaps included software that had already been scanned. In Earthly’s October 21 checks of container images built before the patch, one scanner reported no matching advisories. Another, using a database updated later that day, identified affected Go, Python certifi, and Debian packages. It classified the Debian finding as “unknown.” An outdated Alpine certificate bundle produced no finding.

A rule that blocks only high and critical findings can overlook a relevant advisory with an unknown severity. Matching the incident’s advisory IDs directly avoids that particular gap. It cannot catch an advisory the scanner has not reported, so retain package/version checks against the remediation guidance. A build date after October 20 does not establish that the required fixes were included.

Closing the response also requires deployment evidence that patched artifacts replaced affected ones. A successful build alone does not establish that. For tools used inside CI, verify that the jobs actually use the updated versions.

The immediate goal is to account for every affected service: which artifact was checked, which fix it contains, and whether the replacement is deployed. The target is 100% of affected software updated, including tools used inside CI. Components without evidence or an owner must stay in the count.

Keeping those checks running gives the next advisory a response process that already has owners, evidence, and enforcement.

Bring your eMudhra response requirements to a Lunar demo. See how your platform team can enforce required updates, expose gaps in scan coverage, and track what still needs attention.