TS-2026-007
Vulnerability from tailscale - Published: Fri, 10 Jul 2026 00:00:00 GMT
Description: Insufficient inbound packet filtering in Services permitted access to loopback-bound listeners.
What happened?
Tailscale Services are virtual tailnet destinations that can be hosted from one or more nodes on your tailnet. They allow you to manage networked resources such as databases separately from the nodes that back them.
In Tailscale versions prior to 1.98.9, nodes advertising services could accept inbound traffic to service IPs on ports that they did not advertise. In these scenarios Tailscale would forward these packets to any process on the host loopback interface listening on the same port, allowing them to be accessed remotely.
Tailscale now filters and rejects these packets with the appropriate TCP RST response when no corresponding handler exists for the service port.
This vulnerability is fixed in Tailscale version 1.98.9 or newer.
What was the impact?
A user with ACL grants to a Tailscale Service could address it on non-advertised ports and reach processes listening on loopback on the node hosting the service.
Who was affected?
Users of Tailscale Services that rely on loopback-only network access restrictions on the nodes they use to host services.
What do I need to do?
If you host Tailscale Services on nodes alongside processes bound to loopback, upgrade to Tailscale version 1.98.9 or newer.
Show details on source website{
"guidislink": false,
"id": "https://tailscale.com/security-bulletins/#ts-2026-007",
"link": "https://tailscale.com/security-bulletins/#ts-2026-007",
"links": [
{
"href": "https://tailscale.com/security-bulletins/#ts-2026-007",
"rel": "alternate",
"type": "text/html"
}
],
"published": "Fri, 10 Jul 2026 00:00:00 GMT",
"summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Insufficient inbound packet filtering in Services permitted access to loopback-bound listeners.\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003eTailscale \u003ca href=\"https://tailscale.com/docs/features/tailscale-services\"\u003eServices\u003c/a\u003e are virtual tailnet destinations that can be hosted from one or more nodes on your tailnet. They allow you to manage networked resources such as databases separately from the nodes that back them.\u003c/p\u003e\n\u003cp\u003eIn Tailscale versions prior to 1.98.9, nodes advertising services could accept inbound traffic to service IPs on ports that they did not advertise. In these scenarios Tailscale would forward these packets to any process on the host loopback interface listening on the same port, allowing them to be accessed remotely.\u003c/p\u003e\n\u003cp\u003eTailscale now filters and rejects these packets with the appropriate TCP RST response when no corresponding handler exists for the service port.\u003c/p\u003e\n\u003cp\u003eThis vulnerability is fixed in Tailscale version 1.98.9 or newer.\u003c/p\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eA user with ACL grants to a Tailscale Service could address it on non-advertised ports and reach processes listening on loopback on the node hosting the service.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eUsers of Tailscale Services that rely on loopback-only network access restrictions on the nodes they use to host services.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eIf you host Tailscale Services on nodes alongside processes bound to loopback, upgrade to Tailscale version 1.98.9 or newer.\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: Insufficient inbound packet filtering in Services permitted access to loopback-bound listeners.\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003eTailscale \u003ca href=\"https://tailscale.com/docs/features/tailscale-services\"\u003eServices\u003c/a\u003e are virtual tailnet destinations that can be hosted from one or more nodes on your tailnet. They allow you to manage networked resources such as databases separately from the nodes that back them.\u003c/p\u003e\n\u003cp\u003eIn Tailscale versions prior to 1.98.9, nodes advertising services could accept inbound traffic to service IPs on ports that they did not advertise. In these scenarios Tailscale would forward these packets to any process on the host loopback interface listening on the same port, allowing them to be accessed remotely.\u003c/p\u003e\n\u003cp\u003eTailscale now filters and rejects these packets with the appropriate TCP RST response when no corresponding handler exists for the service port.\u003c/p\u003e\n\u003cp\u003eThis vulnerability is fixed in Tailscale version 1.98.9 or newer.\u003c/p\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eA user with ACL grants to a Tailscale Service could address it on non-advertised ports and reach processes listening on loopback on the node hosting the service.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eUsers of Tailscale Services that rely on loopback-only network access restrictions on the nodes they use to host services.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eIf you host Tailscale Services on nodes alongside processes bound to loopback, upgrade to Tailscale version 1.98.9 or newer.\u003c/p\u003e"
},
"title": "TS-2026-007",
"title_detail": {
"base": "https://tailscale.com/security-bulletins/index.xml",
"language": null,
"type": "text/plain",
"value": "TS-2026-007"
}
}
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.