The eMudhra CA compromise and ngrok: what's affected and what to do

Researchers found the private keys for eight eMudhra intermediate CA certificates, so anyone who has those keys can forge TLS certificates that chain to two widely trusted roots: emSign ECC Root CA - G3 and AAA Certificate Services.

Short version: if you run the ngrok agent with its default configuration, your tunnels aren’t affected by the eMudhra CA compromise. A few non-default settings and auxiliary features do rely on your host’s certificate store. If you use any of them, update your OS CA bundle or upgrade to agent v3.39.12. Details below.

Am I affected?

“Possibly” means an attacker with a privileged network position could, in theory, intercept that connection with a certificate chained to one of the affected roots. It doesn’t mean we’ve seen that happen.

How to check

1. Run ngrok config check to find your config file, then open it.
2. Look for connect_cas or root_cas. If it isn’t there, you’re on the default, pinned path.
3. Search your scripts and service definitions for ngrok api, --traffic-policy-url, and proxy_url.

If none of those turn up, you don’t need to do anything.

Why the default path is safe

Most software that makes TLS connections trusts whatever root certificates the operating system trusts. That’s the right default for a browser, but it means one compromised CA anywhere in that list can impersonate any site.

The ngrok agent doesn’t connect to ngrok that way. By default, it pins ngrok’s own root CA: it accepts a certificate for the ngrok service only if it chains to our root, no matter what the host trusts. The OS accepts a certificate chained to one of the affected roots, but the agent rejects it because it doesn’t chain to ngrok.

Agent updates are protected on a separate path. ngrok signs them, and the agent verifies that signature independently of TLS, so an attacker can’t use a compromised CA to push a spoofed update either.

This is a deliberate choice. ngrok agents often run in places we don’t control: customer data centers, appliances, locked-down hosts with CA bundles that are years old. Pinning means the security of the connection back to ngrok doesn’t depend on how well each of those hosts is maintained.

Where the host trust store still applies

Pinning covers the agent’s connection to the ngrok service. Some features talk to other endpoints and use the host’s trust store, the same way any HTTP client would:

• ngrok api calls the ngrok API and sends your API key.
• --traffic-policy-url fetches a Traffic Policy from a URL you provide.
• HTTPS proxy_url connects through your proxy.
• connect_cas: host tells the agent to skip pinning and trust the host store for the ngrok connection. This setting is common behind enterprise TLS-inspecting proxies.

What to do

Do one or both of these:

• Update the OS CA bundle on hosts that run the agent to remove the affected roots, then restart the agent.
• Upgrade to ngrok agent v3.39.12 (download). It’s built on a patched Go release that blocklists the affected roots no matter what’s in the host trust store. Choose this option if you can’t reliably update CA bundles on the hosts where the agent runs. On Windows, use the direct download tab, because the Microsoft Store build can take a couple of days to update.

Still on agent v2? It’s past end-of-life and won’t get fixes like this one. Follow the upgrade guide.

Questions

Contact support@ngrok.com or fill out this form.