Release Incident Playbook

Permission escalation via role change: symptoms, cause, and the test that catches it

A role or policy change grants users access to resources they should not see.

Permission escalation via role change is documented by 4 accepted public reports from 4 organisations, 3 of them published in the last 5 years.

  • Likelihood: medium (3 public reports in 5 years)
  • Impact: high (4 of 4 reports: data)

4 public reports · verified 2026-10-21

Symptoms

User-visible

  • Digest emails show inflated unread counts and activity from private teams, and some members receive a digest covering the entire workspace.[1]
  • API and OAuth integrations that run broad queries receive data from private teams.[1]
  • Users open Spaces in their own tenant without being members, and only tenants with multiple Spaces are affected.[3]
  • A user without the admin role opens the user provisioning settings page by URL even though the sidebar hides it.[2]
  • External users and guest accounts see every project, including internal ones.[4]

Monitoring-visible

  • Queries return rows without team-level filtering instead of raising an error.[1]
  • Admin endpoints that should return 403 Forbidden to non-admin users return normal responses.[2]
  • A customer reports a notification email with far more content than expected shortly after the first internal finding.[1]
  • External users file bug reports about the visible internal projects at the same time the operations team detects the change.[4]

Root causes

  1. stage: code A performance optimization gated to one internal workspace had a variable shadowing bug in its disabled path, which dropped the user-specific sync group resolvers and skipped the team permission check for every other workspace.[1]
  2. stage: code A new user provisioning page replaced an older settings page, and its endpoints shipped without the admin authorization policy attribute.[2]
  3. stage: code An application update changed the authorization logic used when fetching Space data, so membership was no longer checked.[3]
  4. stage: config An administration failure during a permission synchronization run granted all external and guest accounts access to every project.[4]

Public examples

  1. [1]Linear, 2026-04-06. A deployed change to the access control layer skipped team-level permission filtering for all but one workspace, so for about one hour members and guests could access data from private teams in their own workspace. primary Post mortem on Linear security incident on March 24th, 2026
  2. [2]Workspace 365, 2026-02-20. Release 3.51.0 replaced a settings page with a new User provisioning page whose endpoints lacked the admin authorization policy, so environment users without the admin role could reach them by URL until a hotfix in July 2023. primary Post Mortem - Security misconfiguration - 3.63.1
  3. [3]Templafy, 2025-10-21. A Library App update changed the authorization logic used when fetching Space data, so users could view Spaces in their own tenant without being members until the change was rolled back across all production clusters. primary Service degradation - A subset of users could encounter access issues to Spaces
  4. [4]JetBrains, 2015-08-10. An administration failure during a permission synchronization process gave all external users and guest accounts permissions to every project on the company's production YouTrack instance, including internal ones, for about an hour. primary JetBrains YouTrack Instance Security Issue Post Mortem

Test classes that catch it

Test classStageLimitationBasis
Integration testspre-deployAn integration test that covers the optimization only while it is switched on misses the disabled code path, which is the path every workspace but one ran.cited in [1]
Security testspre-deployA security test covers only the access scenarios it lists, and guest and external accounts gaining every internal project after a synchronization run sat outside the scenarios that existed before the follow-up.cited in [4]

Risk

  • Likelihood: medium (3 public reports in 5 years)
  • Impact: high (4 of 4 reports: data)
Counts behind the grades
Accepted public reports4
Published in the last 5 years3
Impact stated: data4

How the grades are computed

Pre-release checklist

  • PR-01
  • PR-02
  • PR-03
  • PR-04
  • PR-05
  • PR-06
  • PR-07

First 30 minutes

  • FM-01
  • FM-02
  • FM-03
  • FM-04
  • FM-05
  • FM-06
  • FM-07

Download the checklist

What catches this: catalogue entries

Listed because their own documentation or site names integration tests, security tests on the verification date. Alphabetical. Not a recommendation.

Tools whose documentation names these test classes

Providers whose site names these test classes

Only on this page

Permission escalation via role change has one public report with a measured time to detect: 63 minutes passed between the deploy and the first identified subset of private-team exposure [1]. A customer report of an oversized notification email followed shortly after.

In that report the faulty path was the disabled branch of an optimization switched on for one internal workspace, so the internal workspace kept its permission check while every customer workspace lost it [1]. Internal use of the product could not surface the exposure, because the only workspace running the optimized path was unaffected.

Questions

What causes permission escalation via role change?

Three of the 4 primary reports name a code change in authorization logic, and one names an administration failure during permission synchronization [4]. The code causes include a skipped team permission check [1] and endpoints shipped without an admin policy attribute [2].

What are the symptoms of permission escalation via role change?

Users see private-team activity in digest emails, Spaces they are not members of, or internal projects as guests. Monitoring shows admin endpoints returning normal responses where 403 Forbidden is expected [2].

Why did tests not catch permission escalation via role change?

One report states that tests covered an optimization when active but not its disabled code path [1]. Another states that a hidden page was not on the testing checklist, so code review and QA missed the missing policy [2].

Which test class catches permission escalation via role change, and what does it miss?

Integration tests carry a cited basis from one report [1], and security tests carry a cited basis from another [4]. Report [4] added security tests covering more access scenarios after guest and external accounts could see internal projects.

How long did it take to detect permission escalation via role change in the public reports?

One report measures 63 minutes from deploy to the first identified exposure [1]. Another found the missing admin policy about ten months after the release, during QA testing [2].

Should a team roll back or fix forward when permission escalation via role change happens?

Two reports reverted or rolled back the change [1] [3], one shipped a hotfix that added the missing policy attribute [2], and one fixed the grants within an hour [4]. Checklist item FM-01 reverts first and investigates after.

Release Incident Playbook (2026). Permission escalation via role change: symptoms, cause, and the test that catches it, content version 1.0.0. https://releasefailures.com/incidents/permission-escalation-via-role-change/. Accessed 2026-10-21.