loading
loading
eMudhra root CA issue: the default ngrok agent isn't affected Short version: ngrok wasn’t breached. This is an issue with a third-party certificate authority. If you run the ngrok agent with its default configuration, you don’t need to do anything. A few non-default settings 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. What happened Researchers found the private keys for eight eMudhra intermediate CA certificates. 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. This affects any software that trusts those roots, not just ngrok. 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 - Run ngrok config check to find your config file, then open it. - Look for connect_cas or root_cas. If it isn’t there, you’re on the default, pinned path. - 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.
document fetched 2026-10-24 11:26