Linear 发布 2026 年 3 月 24 日安全事件复盘

3 月 24 日（周二），我们部署的一项代码变更导致私有团队的数据可被同一工作区内的其他成员访问。在约一小时的时间窗口内（UTC 00:07 至 01:10），工作区成员（包括访客用户）可能访问到了超出其正常团队权限的数据。我们在发现后数小时内定位了问题、回滚了代码变更，并清除了受影响的客户端会话。

3 月 26 日（周四），我们通过电子邮件通知了受影响工作区的所有者/管理员。

很抱歉发生了这件事。私有团队和访客角色的存在，就是为了让敏感工作内容只对授权成员可见，而我们没能守住这条边界。

以下是本次事件的时间线、关于原因的更多细节，以及我们已经采取和计划采取的措施。

事件时间线

所有时间均为协调世界时（UTC）

3 月 24 日

00:07：代码变更部署到生产环境。
01:10：确认了最初一批受影响范围，回滚代码变更并完成部署。
01:30：重置服务端缓存并递增数据库版本，强制客户端缓存失效。
01:40：客户反馈收到内容过多的通知邮件。
01:45：开启事件处理频道。
03:13：强制在时间窗口内活跃的移动端客户端登出，以清除缓存。
03:23：强制 Web 和桌面客户端重新加载以清除缓存。
04:02：发布状态页事件公告。
05:04：作为预防措施，删除了时间窗口内自动生成的 Pulse 动态帖子。

3 月 25 日

继续收集和分析数据，以了解各工作区的受影响情况。

23:45：向所有受影响工作区的联系人发送邮件通知。
23:47：状态页事件标记为已解决。

3 月 27 日

继续分析各工作区的受影响情况。

21:30：开始向请求更多细节的客户发送各工作区的受影响情况摘要。

发生了什么

Linear 的访问控制层使用内部的“同步组”（sync group）机制来确定每个工作区成员可以访问哪些数据。当执行查询时——无论是通过 Web 客户端、移动应用还是 API——同步组解析器会附加权限过滤条件，确保用户只能看到其所属团队的数据。

一项性能优化尝试跳过那些不可能匹配特定用户权限的同步组解析器。该优化被限定为仅在生产环境中的一个内部工作区运行，目的是在更大范围推广前进行验证。然而，为其他所有工作区禁用该优化的代码存在变量遮蔽（variable shadowing）缺陷：它没有回退到原本未过滤的解析器，而是省略了所有用户特定的解析器。

这导致下游的权限检查被完全跳过；查询没有报错，而是静默返回了未经团队级过滤的结果。

该变更经过了测试和同行评审。我们现有的测试覆盖验证了优化在启用时工作正常，但没有覆盖它在非目标工作区被禁用时的代码路径。正是这一缺口让回归问题进入了生产环境。

该变更由工程师在无 AI 辅助的情况下编写和评审。虽然我们在开发流程中大量使用 AI，但这里的根本原因是经过同行评审和测试的代码路径中的变量遮蔽缺陷。问题出在测试覆盖，而非编写过程。

受影响范围

没有任何数据泄露给各工作区之外的人，也没有凭据、API 密钥或身份验证令牌泄露。

在这段时间内，私有团队的数据可能已暴露给其他工作区成员，包括：

问题、评论和附件
项目、文档及相关实体

私有团队并未直接出现在 Linear 网页端或桌面应用界面中。

泄露主要通过以下途径发生：

通知邮件：在这段时间内发送给工作区成员的摘要邮件，可能包含虚高的未读计数以及私有团队的活动详情。通知系统在权限失效的状态下运行，生成的跨团队通知。在某些工作区中，单个成员收到的摘要包含了整个工作区的通知。

网页端和桌面客户端数据同步：在这段时间内，大约发生了 7,000 次完整的客户端初始化。进行同步的用户，其本地客户端数据库中可能暂时存有私有团队的数据，但这些数据并未在应用界面中显示。在修复过程中，所有客户端都被强制重新加载，以清除缓存数据。

移动应用：在这段时间内活跃的移动会话，可能通过应用内功能访问到私有团队的数据。所有在这段时间内活跃的移动会话均已被登出。可能包含跨边界数据的 Pulse 信息流内容已被删除。

API 和第三方集成：OAuth 应用和 API 密钥在这段时间内发出的请求，可能收到包含私有团队数据的响应，具体取决于各集成查询的范围。只查询其已有权限访问的特定问题或团队的集成不会受到影响，而进行更广泛查询的集成则可能收到超出其正常权限的数据。代码变更回滚后，API 访问权限已恢复正常。

后台任务：若干在用户上下文中运行的服务器端任务受到影响。通知清理任务错误地在工作区层级而非按用户归档通知，信息流摘要生成器则生成了包含跨边界数据的帖子。错误归档的通知已恢复，受影响的信息流帖子已删除。

我们对所有受影响工作区中的敏感变更——团队成员变更、角色变更和工作区邀请——进行了事后审计，未发现恶意滥用的证据。

我们的应对措施

在发现问题后，我们完成了一系列初步修复措施：

在部署后一小时内回滚了代码变更
强制重新加载所有桌面和网页客户端，以清除缓存数据
登出了在这段时间内活跃的所有移动会话
对受影响工作区的访问和修改日志进行了审计

我们在事件发生后 48 小时内通知了受影响的工作区联系人。对于要求提供更多细节的客户，我们提供了按工作区划分的暴露摘要，涵盖这段时间内与各暴露途径相关的活动。

后续步骤与改进

此次事件暴露出我们在验证和部署访问控制层变更方面存在不足。我们已做出以下改进：

扩大了集成测试覆盖范围，以验证跨部署环境、团队类型、用户角色、访客访问和身份验证方法的权限边界。
已实施限制，控制单封摘要邮件中渲染的通知条目数量。

我们将优先推进的后续任务包括：

加强部署前安全审查的执行力度，由人工和智能体共同对涉及授权相关代码路径的任何变更进行审查。
改进针对授权层异常行为和权限边界违规的运维监控。
扩展内部日志系统，提高工作区相关事件的可观测性。
允许工作区管理员/所有者配置特定的安全联系人，用于接收后续通知。
记录事件数据收集流程，以便在未来事件中更快开展分析。

我们认真对待客户给予的信任，并承诺落实上述行动，在事件响应中持续保持透明。