Tails 7.15.1 is a security emergency from the Tor Project that updates Tor Browser to 15.0.26 and blocks the compromised certificates of Indian CA eMudhra. The incident stems from eight eMudhra intermediate keys that had only three to eight bits of entropy, letting researcher Scott Helme crack them in under a second. Mozilla, Apple, and Microsoft raced to revoke the affected certs, and Google confirmed Certificate Transparency limited real-world exploitation. If you're running Tails 7.0 or newer, upgrade now to protect against forged clearnet sites over Tor.
Tails 7.15.1: emergency patch closes the door on forged eMudhra certificates
Tails is issuing an emergency release today to keep attackers from faking websites in front of some of the most privacy-conscious users on the planet. Tails 7.15.1, published by the Tor Project today, updates Tor Browser to 15.0.26 and blocks the compromised certificates of Indian CA eMudhra.
There's nothing new here, functionally. This isn't a feature drop. It's a supply-chain band-aid, and it's the second one of 2026 following Tails 7.10.1's kernel and expat patches. But for a tool used by journalists and activists who routinely deal with network-level adversaries, a forged cert is a much bigger deal than it is for a casual desktop OS.
Why an Indian CA became a global headache
eMudhra Limited is based in Bengaluru and dates back to June 16, 2008. It's licensed by India's Controller of Certifying Authorities and, after Mozilla approved four emSign root certificates in December 2018, it became the only Indian root trusted by major browsers. By 2026 it had issued well over 60 million digital certificates.
On October 17, browser root programs got the report that the private keys of eight eMudhra intermediates had been compromised.
And this is the part that still doesn't quite make sense.
A normal P-384 elliptic-curve key has about 384 bits of entropy. The numbers get absurd fast. The keys eMudhra shipped, by contrast, had between three and eight bits. That's not a weakness you trip over by accident. It's a wall you could knock down. Security researcher Scott Helme said he recovered several of the keys straight out of the public certificates in under a second.
The intended key-generation ceremony happened on April 30, 2025, according to eMudhra. The company blamed a flaw in a "key wrap/unwrap" step that produced a second, weak set of keys alongside the strong ones. Staff then used the wrong keys. As of October 21 it hadn't fully nailed down the root cause.
Ars Technica's Filippo Valsoda put it plainly: the whole thing is "extremely in the 'this should not be possible' category." His guess was that some key-generation interface had a size parameter accidentally set near zero. The community floated looser theories, from example code leaking into production to a generator that misfired.
How the browser world reacted
The response was fast because it had to be. Mozilla received the report Saturday at 20:06 UTC and had Firefox blocking the affected certs within a few hours via OneCRL, distributed through RemoteSettings. No update or restart required for most users.
Chrome's root program got a researcher report the same evening and landed a CRLSet block on the affected SPKI hashes. Apple blocked on October 19. Microsoft followed on October 20. Mozilla pulled the emSign ECC Root CA – G3 root from NSS and pushed Firefox 158.0.1 and ESR updates to catch people whose policies disable RemoteSettings.
Google confirmed something that kept the damage surprisingly contained: none of the six TLS intermediates had issued any certificates logged to Certificate Transparency. Chrome and modern Android reject unlogged certs, so those clients effectively couldn't have been fooled.
Which is the part people still misunderstand. CT protection is real for browsers that enforce it. It does nothing for older apps, embedded devices, or enterprise software that never checks. For a tool like Tails, where the threat model includes exit nodes and their ISPs, that blind spot matters more than it does for a stock workstation.
What Tails 7.15.1 actually does
Two changes, narrowly scoped.
First, Tor Browser moves from 15.0.25 to 15.0.26. This bundles the revocation database that blocks all eMudhra certificates, including the compromised intermediates and the G3 root. Because Tor Browser carries its own revocation list, it doesn't depend on a separate OS-level update to take effect.
Second, Tails updates the Debian ca-certificates package. That's the trust store that non-browser applications use to validate outbound TLS: update checkers, download tools, Git and the like. Without this step, you'd have a browser that's safe and everything else bundled in Tails that still trusts the bad root. The CVE for the Tor Browser fix is CVE-2026-113470, tracked under Mozilla Security Advisory 2026-112.
Oneself, the Tor Project's own framing is worth quoting. Tails says the attack "could be performed by a Tor exit node, the ISP of an exit node, or a government." It's also explicit that onion sites aren't vulnerable. That's the honest bit: .onion services use end-to-end encryption through the Tor circuit and never present public TLS, so an exit node can't impersonate them. Only clearnet browsing over Tor was at risk.
The upgrade
Automatic upgrades run from Tails 7.0 or later straight to 7.15.1. If that fails or isn't an option, you can do a manual upgrade through the Tails installer and keep Persistent Storage. A fresh install over it wipes Persistent Storage, so back it up first if you can't afford to lose it.
One quirk. After first startup, the updated revocation database can take a few minutes to build. Don't panic when the first browser launch looks slow. It's just compiling trust lists.
Head here to the Tails download page to grab 7.15.1.
