Two release lines close the same permission gap
Datasette maintainer Simon Willison released 0.65.5 and 1.0a40 on 16 September to fix a table-permission bypass. The disclosed trigger is a requested table name with a trailing newline: Datasette could authorise the request against one resource name while the database resolved it in a way that exposed rows from a table the actor was not meant to read.
The fix applies to both the stable 0.65.x line and the current 1.0 alpha line. Willison credits the report to GitHub user dpfkdlemtp and links the public advisory GHSA-h547-rmjf-5m2m from the release notes.
The affected boundary is table-level authorisation
The material risk is specific: deployments that rely on Datasette table permissions to keep some rows or tables private could have that boundary bypassed under the vulnerable name-resolution case. The release note does not describe a general database compromise, and exploitability depends on the tables and permissions present in a particular deployment.
Administrators running either affected release family should therefore update rather than infer safety from whether a public instance appears to expose only ordinary read routes. Permission-boundary bugs matter most on mixed public and private datasets, where a request that is accepted under the wrong resource identity can cross an otherwise deliberate access rule.
The project exposes the fix through an inspectable release trail
Datasette is Apache-2.0 licensed, and the project publishes its source, changelog, security advisory and both patched release lines openly. That gives operators a direct path to inspect the relevant changes, update a pinned deployment and exercise their own permission tests against the patched version.
The 1.0a40 release contains other work, including background tasks and an httpx2 migration, but those additions are separate from the security fix. For security-sensitive production deployments, the relevant comparison is the behaviour of protected-table requests before and after the patch rather than the additional alpha features.
What the disclosure does not establish
The public material establishes the vulnerability and the availability of patched versions. It does not establish that the flaw was exploited against a real Datasette deployment, how many public instances were vulnerable, or whether any private data was actually taken.
That distinction should remain visible in operational reporting. The practical response is to upgrade, review table-permission configurations and rerun access-control tests. Broader claims about exploitation or incident scope would require evidence beyond the maintainer disclosure and release record.