{
  "guidislink": false,
  "id": "https://tailscale.com/security-bulletins/#ts-2024-011",
  "link": "https://tailscale.com/security-bulletins/#ts-2024-011",
  "links": [
    {
      "href": "https://tailscale.com/security-bulletins/#ts-2024-011",
      "rel": "alternate",
      "type": "text/html"
    }
  ],
  "published": "Mon, 22 Jul 2024 00:00:00 GMT",
  "summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: SCIM group name disclosure via the ACL editor\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003eThe \u003ca href=\"https://tailscale.com/kb/1338/acl-edit\"\u003eACL editor\u003c/a\u003e in the admin console did not check \u003ca href=\"https://tailscale.com/kb/1290/user-group-provisioning\"\u003eSCIM\u003c/a\u003e\ngroup names in the ACL rules against the tailnet name. This allowed tailnet A\nto use SCIM groups from tailnet B in their ACL rules. A malicious user in\ntailnet A could not gain access to target tailnet B this way. However, they\ncould use the fact that ACLs get saved without warnings to learn about valid\nSCIM group names in other tailnets.\u003c/p\u003e\n\u003cp\u003eThis issue was fixed on July 19th, 2024. A user trying to save ACLs with SCIM\ngroup names from other tailnets will always receive a warning that these groups\ndo not exist, even if they do exist in other tailnets.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eNone of the existing tailnets\u0027 ACLs appear to use SCIM group names from other\ntailnets maliciously. A handful of customers used the wrong SCIM group names\nfrom their production tailnets in their test tailnets by accident.\u003c/p\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eA malicious user could learn about SCIM group names used in other tailnets.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eNo action is required.\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: SCIM group name disclosure via the ACL editor\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003eThe \u003ca href=\"https://tailscale.com/kb/1338/acl-edit\"\u003eACL editor\u003c/a\u003e in the admin console did not check \u003ca href=\"https://tailscale.com/kb/1290/user-group-provisioning\"\u003eSCIM\u003c/a\u003e\ngroup names in the ACL rules against the tailnet name. This allowed tailnet A\nto use SCIM groups from tailnet B in their ACL rules. A malicious user in\ntailnet A could not gain access to target tailnet B this way. However, they\ncould use the fact that ACLs get saved without warnings to learn about valid\nSCIM group names in other tailnets.\u003c/p\u003e\n\u003cp\u003eThis issue was fixed on July 19th, 2024. A user trying to save ACLs with SCIM\ngroup names from other tailnets will always receive a warning that these groups\ndo not exist, even if they do exist in other tailnets.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eNone of the existing tailnets\u0027 ACLs appear to use SCIM group names from other\ntailnets maliciously. A handful of customers used the wrong SCIM group names\nfrom their production tailnets in their test tailnets by accident.\u003c/p\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eA malicious user could learn about SCIM group names used in other tailnets.\u003c/p\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eNo action is required.\u003c/p\u003e"
  },
  "title": "TS-2024-011",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2024-011"
  }
}