TL;DR: Researchers found private keys for eight eMudhra intermediate CA certificates that could let an attacker forge TLS certificates chaining to trusted roots, according to ngrok. The default ngrok agent path remains safe because it pins ngrok’s root CA, but non-default settings that rely on host trust stores need CA bundle updates or agent v3.39.12.
At a glance
What this is: ngrok says a compromise of eight eMudhra intermediate CA private keys can affect TLS trust on non-default agent paths, while the default pinned connection remains protected.
Why it matters: Identity and access teams should treat certificate trust stores and pinning choices as governance controls, because a compromised CA can undermine service authentication on hosts that still trust affected roots.
Context
A certificate authority compromise becomes an authentication problem when a forged certificate can still chain to a trusted root. In this case, the issue is not whether TLS exists, but whether the relying party accepts the right trust anchor and whether host-level trust stores are kept current.
For ngrok agents, the practical question is which connection path is in use. Default pinning narrows the blast radius, while non-default trust-store-dependent features inherit the security of the underlying host certificate bundle.
Key questions
Q: What breaks when a certificate root is not widely trusted?
A: When a root is not widely trusted, certificate validation can fail across browsers, devices, and applications even if the certificate itself is intact. The operational impact includes warnings, blocked connections, failed integrations, and support overhead. For identity teams, the failure is usually ecosystem trust coverage, not cryptography.
Q: When should teams prioritise certificate pinning over host trust stores?
A: Prioritise pinning when the connection carries sensitive credentials, policies, or administrative control and the host trust store cannot be tightly governed. Host trust is broader and more flexible, but pinning reduces the chance that a compromised or outdated root can impersonate the intended service.
Q: What signs show that certificate trust is too broad in production?
A: Look for workflows that depend on default OS roots, TLS inspection exceptions, stale CA bundles, or undocumented proxy and policy-fetch paths. If different code paths validate certificates differently, the environment has inconsistent trust boundaries and a higher chance of accidental acceptance of forged chains.
Q: How should teams handle certificate trust after a CA compromise?
A: Treat the event as a trust inventory problem first and a certificate replacement problem second. Identify every certificate that chains to the affected intermediates or roots, remove those trust anchors where you control them, and reissue or migrate any service that still depends on the exposed chain.
Technical breakdown
How CA compromise turns into certificate forgery
When an intermediate CA private key is exposed, an attacker can issue certificates that appear legitimate to clients relying on the compromised trust chain. The risk is not the encryption algorithm itself but the authority behind certificate issuance. If the affected roots remain trusted on the host, the forged chain may validate even though the certificate was not legitimately issued for that service. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practical implication: Review which trust anchors your agents and clients accept, especially where host-managed CA bundles are used.
Why certificate pinning changes the trust model
Certificate pinning limits validation to a specific expected root or certificate chain instead of the full operating system trust store. That means a compromised public CA may still be trusted by the host, but the pinned client rejects it because the chain does not match the expected identity. This is a narrower and more deliberate authentication model, but only for the paths where pinning is actually enforced.
Practical implication: Use pinned trust paths for high-value service connections where host trust stores cannot be assumed current.
Where host trust stores still create exposure
Some client features intentionally use the host’s certificate store, such as API calls, fetched policy URLs, and proxy-based connections. Those paths behave like ordinary HTTPS clients, so they inherit whatever roots the host trusts. In environments with TLS inspection, stale CA bundles, or broadly trusted enterprise roots, that can reintroduce the very impersonation risk pinning is meant to avoid.
Practical implication: Inventory every outbound TLS path and decide explicitly whether it should inherit host trust or an enforced trust chain.
Threat narrative
Attacker objective: The attacker wants to impersonate trusted endpoints and intercept or influence TLS-protected connections that rely on the compromised trust chain.
- Entry occurs when an attacker with access to compromised intermediate CA private keys can mint a certificate that appears valid to TLS clients.
- Escalation occurs if the target host still trusts the affected roots or uses a non-pinned trust path, allowing the forged chain to validate.
- Impact is impersonation of the service endpoint, which can expose API keys, policy content, or other sensitive traffic on affected paths.
Breaches seen in the wild
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Certificate trust is an identity control, not just a transport setting. When a client accepts the wrong trust anchor, it can authenticate the wrong endpoint with full confidence. That makes certificate lifecycle governance part of identity assurance, especially where service-to-service traffic carries keys, tokens, or policy data. Practitioners should treat CA trust as an access boundary, not a background configuration detail.
Default pinning reduces exposure, but only on the paths where it is actually enforced. The operational mistake is assuming one secure connection model covers every auxiliary feature. API calls, fetched policies, and proxy-mediated flows can still depend on host trust stores, so the real control question is which path determines authentication for each function.
Compromised CA material creates a verification trust gap. The gap appears when the host trust store and the application’s intended trust model diverge, allowing forged certificates to validate in one context but not another. That makes certificate lifecycle management part of runtime identity governance, not just PKI administration. Practitioners should map every trust-dependent path to an explicit owner and review cycle.
The governance lesson is that pinning and host trust are different security promises. Pinning gives you constrained assurance, while host trust gives you ambient compatibility. Security teams need to know which promise each workflow depends on, because mixed models make incident scoping harder and can leave only some traffic protected when a CA is compromised.
What this signals
Verification trust gaps emerge whenever an application’s intended trust model differs from the host’s CA store. That gap is operationally important because the security team may believe a connection is pinned when only some paths are. The cleanest response is to document which workloads inherit host trust and which enforce a fixed certificate chain, then align change control to that split.
Host-managed CA bundles remain a convenience mechanism, but they are not a universal identity control. In environments that rely on proxies, fetched policies, or legacy agents, certificate governance has to be treated like access governance: explicitly scoped, reviewed, and continuously checked.
For practitioners
- Audit every TLS trust path Identify where the agent uses pinned trust and where it inherits the host CA bundle, including API calls, fetched policy URLs, proxies, and any connect_cas: host deployments.
- Remove affected roots from managed hosts Update operating system CA bundles on hosts running the agent, then restart the service so stale trust stores stop validating the compromised roots.
- Upgrade systems that cannot be remediated quickly Move affected deployments to agent v3.39.12 where the patched Go runtime blocklists the compromised roots even if the host trust store still contains them.
- Retire unsupported agent versions Plan an immediate upgrade path off agent v2 because end-of-life software will not receive trust-store protections or other security fixes for this incident.
Key takeaways
- A compromised intermediate CA can turn TLS into an endpoint impersonation problem if the affected roots remain trusted.
- The default ngrok agent path is safer because it pins ngrok’s root CA, but non-default trust-store-dependent paths inherit host certificate risk.
- The practical control is to align trust stores, pinning choices, and agent versions so certificate validation matches the security model you expect.
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Browser and Computer-Use Agent Security Guide · Secrets in Docker Hub images (RWTH Aachen study) · Sisense breach 2024
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The incident begins with exposed private keys that can be abused to forge trusted certificates. |
| Recommendation — Revoke and replace any exposed certificate private keys and treat CA key leakage as an NHI secret incident. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article is about certificate trust and replacement of compromised authentication material. |
| Recommendation — Apply IA-5 to manage certificate replacement, revocation, and trust-store updates without delay. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Certificate trust determines whether a service is authorised as the expected endpoint. |
| Recommendation — Align certificate validation rules to PR.AA-05 so only authorised trust anchors are accepted. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Leaked CA private keys enable trusted credential abuse against TLS validation flows. |
| Recommendation — Map compromised CA material to TA0006 and monitor for forged certificate use on affected paths. | ||
Key terms
- Certificate Authority Compromise: A certificate authority compromise occurs when an attacker can use stolen or abused CA material to issue certificates that clients may trust. In practice, the danger is endpoint impersonation, because valid-looking certificate chains can satisfy TLS checks even when the certificate was never legitimately issued for that service.
- Certificate Pinning: A trust control that restricts a client to a specific certificate authority, public key, or certificate for a given connection. It can reduce exposure to unexpected certificates, but it also makes trust changes harder because the client may reject valid replacements after rotation or revocation.
- Trust Store: A set of certificates that a system accepts as trusted for authentication or encryption decisions. If the store is stale or poorly maintained, systems may continue accepting identities that should no longer be valid, which turns trust management into an operational security risk.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org