Simon Willison 在 9 月 11 日贴出了两个版本号:1.0a39 和 0.65.4。听起来是再普通不过的补丁公告,但公告里有一句话值得停下来看:这次修复的场景,是"公开表和私有表混在同一个 SQLite 数据库里"——而这不是 Datasette 第一次栽在这个场景上。
发生了什么
Datasette 是 Willison 做的开源工具,能把一个 SQLite 文件秒变成可浏览、可查询的网页和 API,记者做数据新闻、机构发开放数据,很多都在用。它的权限系统允许你在同一个库里,一部分表公开、一部分表限制访问。
这次的补丁,修的正是这道"墙"上的漏洞:未授权用户可能通过精心构造的查询,绕过表级权限去碰不该碰的数据。问题由 Sevban Dönmez 和 Alex Garcia 报告后,团队用 Claude Fable 5.1、GPT-5.6、GPT-6 Astra 三个模型做了一轮审计,又花了近一周时间人工复核修复方案。
官方原文没有披露具体的注入路径、有没有分配 CVE、CVSS 打了多少分。这和此前一次已经公开记录在案的漏洞(修复于 0.65.3 / 1.0a38,CVSS 评为 7.5、走的是表过滤器对列名转义不当的路子)版本号并不一致——这轮 1.0a39/0.65.4 到底是那次漏洞的变种,还是全新的问题,目前官方没写清楚,不宜直接划等号。
为什么这个场景总出事
一个库里既要公开一部分数据、又要锁住另一部分,权限判断就必须精确覆盖每一条可能的查询路径:表名、列名、过滤条件、排序参数,任何一处转义或权限校验漏一环,私有表就可能被侧漏出去。
上一次公开记录的漏洞里,官方给的临时缓解方案是"禁用 execute-sql 权限",但安全公告特别澄清:光禁用这一项并不够,因为出问题的表过滤操作本身根本不需要这个权限。也就是说,运维如果以为关掉一个开关就安全了,可能只是关错了灯。
这不是 Datasette 独有的毛病。任何"一份存储、多套权限"的架构——BI 工具、内部数据门户、共享数据库的多租户系统——都天然要面对同样的题:数据物理上不分家,权限只能靠逻辑层严防死守,逻辑层出一次错,墙就塌一次。
- 风险.如果你的 Datasette 实例在公网上、又混了公私表,现在没升级到 1.0a39 或 0.65.4,私有数据处于暴露状态。
AI 审计+人工分工,新在哪
这次真正值得记一笔的,不是补丁本身,是团队怎么找出漏洞。Alex Garcia 提出的分工方式很直接:两人在私有仓库协作,针对大多数问题,一人先写出能复现漏洞的自动化测试,另一人再动手实现修复——保证每个问题至少经过两个人的眼睛,再加上三个不同模型跑出来的审计结果交叉验证。
Willison 的判断是,这几个模型帮他们找到了"非常隐蔽的 bug",隐蔽到值得把 AI 审计正式写进以后的开发流程里。这话可信,但也只能到这里:原文没有给出模型具体发现了哪类问题、有没有误报、审计成本能不能被小项目复制。对一个只有一两个核心维护者的开源项目,三模型审计加一周人工复核,已经算得上重投入。
- 结论.AI 审计降低了发现隐蔽漏洞的门槛,但没有降低人工复核和责任兜底的成本——这条流程目前更像"有资源的项目才能常态化"。
现在该做什么
对运维者而言,这事没什么复杂的操作:升级到 1.0a39 或 0.65.4,尤其是公网实例混了公私表的,不要拖。已经禁用了 execute-sql 权限也别掉以轻心,上一轮教训摆在那——那个开关挡不住这类问题。
补丁堵了这次的洞,没堵住这类架构反复漏水的体质
对整个开源生态来说,这次的分工方法——测试和修复分离、多模型交叉审计——是一个可以观察的样本。但值得记住的是,这套流程能跑起来,前提是有 Willison 和 Alex Garcia 这样愿意花一周时间死磕的核心贡献者。大多数小型开源项目,连这个"愿意"都凑不齐。