2026年3月24日星期二,Linear 部署了一次代码变更,导致同一工作区内的其他成员(包括访客用户)能够访问私有团队的数据。从 UTC 时间凌晨12:07到1:10,约持续1小时,这些用户接触到了超出其正常团队权限的数据。

Linear 的授权层使用‘同步组’解析器为每个查询添加权限过滤器。一项性能优化设计为跳过对用户不匹配的解析器,并且仅限于在单个内部工作区中运行。但在其他工作区中禁用该优化的代码路径存在变量遮蔽错误:它没有回退到原始过滤器,而是丢弃了所有特定于用户的解析器,因此下游权限检查被完全跳过,查询悄然返回未过滤的结果。

此变更经过了同行评审和测试,但只覆盖了优化启用的路径;没有人测试过其他工作区中禁用该优化的路径。Linear 团队特别指出,该错误并非 AI 编写——而是人为的变量遮蔽回归,揭示了测试覆盖的缺口。

数据泄露通过通知摘要(一个成员可能获取整个工作区的摘要)、客户端同步引导、移动端会话以及广泛的 OAuth/API 查询传播。没有凭证或 API 密钥泄露,也没有恶意利用的证据。Linear 在一小时内回滚了变更,强制重载了 Web 和桌面客户端,注销了移动端活动会话,并在48小时内通知了受影响的工作区联系人。

2026年3月24日,约1小时内,私有团队数据对同一工作区内的其他成员和访客开放;约有7,000次同步和 API 调用可能拉取了这些数据。

优化禁用路径存在变量遮蔽错误,导致所有特定于用户的解析器被遗漏。

测试覆盖验证了优化启用时的行为,但没有测试优化关闭时的路径。

权限检查失败时采用开放模式:查询返回结果而不是抛出错误。

通知、同步、移动端和 API 层都信任了存在缺陷的权限层。

如果一个‘优化’跳过过滤器,只有当其禁用路径经过测试,或者快乐路径的评审通过却导致静默的权限扩大时,才安全。

Linear 扩展了跨部署环境、团队类型、角色、访客访问和认证方式的集成测试,限制了每份通知摘要的项目数量,并承诺加强部署前的安全审查和授权异常监控。它通知了受影响工作区的所有者,并为有要求的工作区提供了针对性泄露摘要。用户认为这是一次罕见且透明处理的 security incident,此事发生在一家刚刚突破1亿美元 ARR 的公司。

从这里,追溯依据

参考来源

  1. Post mortem on Linear security incident on March 24th, 2026 linear.app
  2. User-specific data accessible to the wrong users within the same workspace linearstatus.com
  3. Linear discloses a data exposure incident devbytes.co.in