AI 安全與開發工具
Datasette Patches Public-Private Table Authorization Bypasses Following Comprehensive Security Audit Involving Three Frontier Models
Datasette 1.0a39 and 0.65.4 patch multiple paths that could leak private data, involving case-variant table names, full-text indexes, relationship queries, and caching. The vulnerabilities were discovered with help from an external researcher and three frontier models, but the maintainers have deliberately withheld some tests for now, so operators should still treat upgrading as a priority.
Datasette simultaneously released stable version 0.65.4 and version 1.0a39 from the 1.0 alpha branch on September 11. The releases primarily address authorization checks that did not cover every data-access path when the same public service contained both public tables and private tables protected by authentication. The project recommends that all internet-facing instances using plugins to protect private data upgrade immediately; Datasette Cloud has already applied the patches. The risks listed in the [official announcement](https://datasette.io/blog/2026/september-security-releases/) are not confined to a single endpoint but reflect inconsistencies in the authorization model across various SQLite semantics.
The new releases make authorization decisions for tables and views follow SQLite’s case-insensitive object naming rules. Access to a full-text search index now triggers a permission check against its source table, while `?_through=` filters also require permission to access the intermediary table. Foreign-key suggestions, reverse relationships, schema displays, row endpoints, and statistics tables from `sqlite_stat1` through `sqlite_stat4` have also been brought back under `view-table` checks. Other fixes include stricter escaping of SQL identifiers and HTML, restrictions preventing `CREATE VIEW` from referencing unauthorized data, and the use of `private, no-store` for personalized responses to prevent shared caches from becoming another data-leak path. An [independent technical analysis](https://www.pyramidledger.com/blog/datasette-1-0a39-0-65-4-a-case-study-in-multi-tenant-permission-bugs) likewise notes that these issues were concentrated in the compositional behavior of authorization boundaries rather than in the core query functionality itself.
The discovery process is also noteworthy. Sevban Dönmez first submitted an AI-assisted report, after which maintainers Simon Willison and Alex Garcia repeatedly searched for similar flaws using Claude Fable 5.1, GPT-5.6 Sol, and GPT-6 Astra. For most issues, one person created a failing test, another implemented the patch, and a different model performed a cross-check. This is not evidence that models independently completed a security audit, but rather an example of a multi-model workflow in which humans remained responsible for verification and merging. Some reproduction tests are still being withheld to give operators time to apply the patches, so the publicly available material does not yet permit a complete assessment of every attack chain. In addition to upgrading, engineering teams should review `execute-sql`, authentication plugins, reverse-proxy caching rules, and integration tests for databases containing a mix of public and private data.