TS-2026-013
Vulnerability from tailscale - Published: Wed, 21 Oct 2026 00:00:00 GMT
Description: Leaked private keys for eMudhra TLS intermediate certificates
What happened?
To validate TLS connections, the Tailscale client and Tailscale servers rely on the host operating system's root certificate store (for example, ca-certificates on Linux).
Our control plane certificates are signed by Let's Encrypt, so the Tailscale client also embeds Let's Encrypt CA certificates, in case they're absent from your system's certificate store.
Tailscale accepts any TLS connection which is signed by a certificate trusted by the system certificate store.
Eight TLS intermediate certificates owned by eMudhra Limited have been compromised. This would allow an attacker to create new certificates for websites they do not control, and these certificates would be trusted by any device that trusts the compromised certificates. Users connecting to the malicious website would receive no warning about incorrect certificates.
Tailscale v1.104.2 or later includes Go 1.27.3, which explicitly distrusts the compromised certificates, even if they are still included in your system certificate store.
Tailscale's internal services have been updated to distrust the compromised certificates, by updating to Go 1.27.3 and updating the host certificate stores.
What was the impact?
An attacker could create TLS certificate for domains they did not own. Devices would accept these TLS certificates as valid and connect to the attacker-controlled website.
Who was affected?
This issue affects any device running on an operating system where the compromised eMudhra intermediate root certificates remain in the system certificate store.
Standard Tailscale mesh traffic between nodes (WireGuard end-to-end encryption using Tailscale node keys) is not affected, as node-to-node data plane traffic does not rely on public Web PKI or system certificate stores.
What do I need to do?
Update to Tailscale v1.104.2 or later.
Show details on source website{
"guidislink": false,
"id": "https://tailscale.com/security-bulletins/#ts-2026-013",
"link": "https://tailscale.com/security-bulletins/#ts-2026-013",
"links": [
{
"href": "https://tailscale.com/security-bulletins/#ts-2026-013",
"rel": "alternate",
"type": "text/html"
}
],
"published": "Wed, 21 Oct 2026 00:00:00 GMT",
"summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Leaked private keys for eMudhra TLS intermediate certificates\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003eTo validate TLS connections, the Tailscale client and Tailscale servers rely on the host operating system\u0027s root certificate store (for example, \u003ccode\u003eca-certificates\u003c/code\u003e on Linux).\nOur control plane certificates are signed by Let\u0027s Encrypt, so the Tailscale client also embeds Let\u0027s Encrypt CA certificates, in case they\u0027re absent from your system\u0027s certificate store.\nTailscale accepts any TLS connection which is signed by a certificate trusted by the system certificate store.\u003c/p\u003e\n\u003cp\u003eEight TLS intermediate certificates owned by eMudhra Limited have been compromised.\nThis would allow an attacker to create new certificates for websites they do not control, and these certificates would be trusted by any device that trusts the compromised certificates.\nUsers connecting to the malicious website would receive no warning about incorrect certificates.\u003c/p\u003e\n\u003cp\u003eTailscale v1.104.2 or later includes Go 1.27.3, which explicitly distrusts the compromised certificates, even if they are still included in your system certificate store.\u003c/p\u003e\n\u003cp\u003eTailscale\u0027s internal services have been updated to distrust the compromised certificates, by updating to Go 1.27.3 and updating the host certificate stores.\u003c/p\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eAn attacker could create TLS certificate for domains they did not own.\nDevices would accept these TLS certificates as valid and connect to the attacker-controlled website.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eThis issue affects any device running on an operating system where the compromised eMudhra intermediate root certificates remain in the system certificate store.\u003c/p\u003e\n\u003cp\u003eStandard Tailscale mesh traffic between nodes (WireGuard end-to-end encryption using Tailscale node keys) is not affected, as node-to-node data plane traffic does not rely on public Web PKI or system certificate stores.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eUpdate to Tailscale v1.104.2 or later.\u003c/p\u003e",
"summary_detail": {
"base": "https://tailscale.com/security-bulletins/index.xml",
"language": null,
"type": "text/html",
"value": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Leaked private keys for eMudhra TLS intermediate certificates\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003eTo validate TLS connections, the Tailscale client and Tailscale servers rely on the host operating system\u0027s root certificate store (for example, \u003ccode\u003eca-certificates\u003c/code\u003e on Linux).\nOur control plane certificates are signed by Let\u0027s Encrypt, so the Tailscale client also embeds Let\u0027s Encrypt CA certificates, in case they\u0027re absent from your system\u0027s certificate store.\nTailscale accepts any TLS connection which is signed by a certificate trusted by the system certificate store.\u003c/p\u003e\n\u003cp\u003eEight TLS intermediate certificates owned by eMudhra Limited have been compromised.\nThis would allow an attacker to create new certificates for websites they do not control, and these certificates would be trusted by any device that trusts the compromised certificates.\nUsers connecting to the malicious website would receive no warning about incorrect certificates.\u003c/p\u003e\n\u003cp\u003eTailscale v1.104.2 or later includes Go 1.27.3, which explicitly distrusts the compromised certificates, even if they are still included in your system certificate store.\u003c/p\u003e\n\u003cp\u003eTailscale\u0027s internal services have been updated to distrust the compromised certificates, by updating to Go 1.27.3 and updating the host certificate stores.\u003c/p\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eAn attacker could create TLS certificate for domains they did not own.\nDevices would accept these TLS certificates as valid and connect to the attacker-controlled website.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eThis issue affects any device running on an operating system where the compromised eMudhra intermediate root certificates remain in the system certificate store.\u003c/p\u003e\n\u003cp\u003eStandard Tailscale mesh traffic between nodes (WireGuard end-to-end encryption using Tailscale node keys) is not affected, as node-to-node data plane traffic does not rely on public Web PKI or system certificate stores.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eUpdate to Tailscale v1.104.2 or later.\u003c/p\u003e"
},
"title": "TS-2026-013",
"title_detail": {
"base": "https://tailscale.com/security-bulletins/index.xml",
"language": null,
"type": "text/plain",
"value": "TS-2026-013"
}
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.