事件經過
2026 年 3 月 24 日(星期二),Linear 部署了一項程式碼變更,導致私人團隊的資料外洩給同一工作區內的其他成員。在大約一小時內,即 UTC 時間 12:07 至 1:10,工作區成員(包括訪客使用者)得以存取超出其正常團隊權限的資料。
Linear 的授權層使用「同步群組」解析器,為每次查詢加上權限篩選。一項效能最佳化原本設計用來跳過永遠不可能符合某位使用者的解析器,且僅限在單一內部工作區執行。但停用該最佳化功能的其他路徑程式碼存在變數遮蔽錯誤:它並未退回原始篩選條件,反而捨棄了所有使用者專屬的解析器,導致下游的權限檢查完全被跳過,查詢便默默回傳未經篩選的結果。
這項變更經過同儕審查與測試,但只涵蓋了最佳化功能啟用時的路徑;沒有人測試過在其他工作區停用該功能的路徑。Linear 團隊特別指出,這個錯誤並非 AI 撰寫,而是人類造成的變數遮蔽回歸問題,暴露出測試涵蓋率的缺口。
外洩途徑包括通知摘要(單一成員可能收到涵蓋整個工作區的摘要)、用戶端同步初始化、行動裝置工作階段,以及範圍廣泛的 OAuth/API 查詢。沒有任何憑證或 API 金鑰外洩,也沒有證據顯示遭到惡意濫用。Linear 在一小時內回退了該變更,強制重新載入網頁與桌面用戶端,登出使用中的行動裝置工作階段,並在 48 小時內通知受影響工作區的聯絡人。
代價為何
2026 年 3 月 24 日約 1 小時內,私人團隊資料可被同一工作區的其他成員與訪客存取;約 7,000 次同步與 API 呼叫可能已取得這些資料。
發生原因
該最佳化功能的停用路徑存在變數遮蔽錯誤,遺漏了所有使用者專屬的解析器。
測試涵蓋率驗證了最佳化功能啟用時的情況,卻未涵蓋功能關閉時的路徑。
權限檢查以失敗開放(fail open)的方式運作:查詢回傳了結果,而非引發錯誤。
通知、同步、行動裝置與 API 各層全都信任了這個損壞的權限層。
教訓
跳過篩選條件的存取控制「最佳化」,唯有在其停用路徑也經過測試時才安全;否則,一次只涵蓋正常路徑的審查,就會讓權限默默被放寬。
後續處理
Linear 擴大了整合測試範圍,涵蓋各部署環境、團隊類型、角色、訪客存取與驗證方式;限制每份通知摘要的項目數量;並承諾加強部署前的安全審查,以及針對授權異常進行監控。該公司通知了受影響工作區的擁有者,並為提出要求者提供各工作區的外洩摘要。使用者將此事記述為一家剛突破 1 億美元 ARR 的公司,罕見且透明處理的安全事件。
追溯依據
參考來源
- Post mortem on Linear security incident on March 24th, 2026 Linear · linear.app ·
- User-specific data accessible to the wrong users within the same workspace Linear Status · linearstatus.com ·
- Linear discloses a data exposure incident Devbytes · devbytes.co.in ·