Datasette 修補公私表權限旁路，三款前沿模型參與完整安全稽核

Datasette 在 9 月 11 日同步發布穩定版 0.65.4 與 1.0 alpha 分支的 1.0a39，主要處理「同一公開服務同時包含公開表與受驗證保護的私有表」時，權限檢查沒有覆蓋所有資料存取路徑的問題。官方建議所有公開連網、並以外掛保護私有資料的執行個體立即升級；Datasette Cloud 已先行套用修補。[官方公告](https://datasette.io/blog/2026/september-security-releases/)列出的風險不是單一端點，而是權限模型在多種 SQLite 語意下的不一致。

新版讓表與 view 的授權判斷遵循 SQLite 不分大小寫的物件名稱；存取全文搜尋索引時會回查來源表權限，`?_through=` 篩選亦須取得中介表存取權。外鍵建議、反向關聯、schema 顯示、列端點及 `sqlite_stat1` 至 `sqlite_stat4` 等統計表也重新納入 `view-table` 檢查。其他修正包含更嚴格的 SQL 識別符與 HTML escaping、限制 `CREATE VIEW` 引用未授權資料，以及為個人化回應設定 `private, no-store`，避免共享快取形成另一條資料外洩路徑。[獨立技術整理](https://www.pyramidledger.com/blog/datasette-1-0a39-0-65-4-a-case-study-in-multi-tenant-permission-bugs)亦指出，這批問題集中於授權邊界的組合行為，而非核心查詢功能本身。

發現流程同樣值得注意。Sevban Dönmez 先提交 AI 輔助報告，維護者 Simon Willison 與 Alex Garcia 隨後使用 Claude Fable 5.1、GPT-5.6 Sol、GPT-6 Astra 反覆搜尋同類缺陷；多數問題由一人建立失敗測試、另一人實作修補，再由不同模型交叉檢查。這不是模型獨立完成安全審計的證據，而是一套人類負責驗證與合併的多模型工作流。部分重現測試仍被保留，讓營運者先取得修補，因此目前也無法由公開材料完整評估每條攻擊鏈。工程團隊除升級外，還應檢查 `execute-sql`、驗證外掛、反向代理快取規則及混合公私資料庫的整合測試。