eMudhra certificate compromise

What it means for your AI agents

Agents call model providers, SaaS APIs and MCP servers over TLS. A trusted certificate that shouldn't be lets someone impersonate those services and read or alter what your agents send and receive.

• Check the trust stores your agent hosts and containers use, not only browsers.
• Prefer pinning or a restricted trust store for high-value agent connections.
• Watch for agents talking to look-alike endpoints while the affected certificates are still trusted.

Details

A compromise of intermediate certificate authorities can allow an attacker holding a fraudulent but trusted certificate to impersonate a service or intercept traffic. The risk depends on whether a client or service still trusts the affected intermediates.

This is a certificate-trust incident, not a CVE-scored software vulnerability. It requires a different response: review trust stores and client software as well as applications and infrastructure that perform certificate validation.

Risk

Researchers found that some clients still accepted affected certificate chains, allowing forged certificates to pass validation.

Affected deployments

Clients and services that still trust the affected eMudhra intermediates. Check customer-managed trust stores, origins and mutual TLS configurations.

Recommended action

Apply the trust-store and client updates in the official response to systems that still trust the affected intermediates.

1. 1Identify customer-managed clients, origins, mutual TLS configurations, and container images that may trust the affected intermediates.

Check your exposure with an agent

Paste this into an AI agent that can see your infrastructure. It asks for a read-only check of what's affected, including the systems behind your agents, and a table you can act on. Copying it changes nothing.

Assess whether the infrastructure you can access is affected by eMudhra certificate compromise. Work read-only within your authorized access: do not run exploits, change configuration, restart services or install anything.

1. Confirm the affected and fixed versions from the vendor advisories and CVE records.
   Cite each source and the date you read it. Say plainly what you could not verify.

2. Inventory the systems that could run the affected software, including the hosts, containers, MCP servers, tool runners and sandboxes behind any AI agents. For each, record the asset, environment, owner if known and the version actually running, from read-only evidence (package metadata, version commands, platform inventory).

3. Note which affected systems are reachable from the internet or from agents and tools, and which credentials (model-provider keys, tool tokens, service accounts) are stored on them.

4. Report one row per asset: asset, running version, affected (yes / no / unknown), reachable from, credentials at risk, evidence, and the next step. List anything you could not access as a gap rather than assuming it is safe.