.png)
Simon Willison released Datasette 1.0a38, and the same SQL injection fix was back-ported to Datasette 0.65.3. The bug affects instances that expose both public and private tables from the same SQLite database under Datasette’s permissions system.
The vulnerable setup is narrower than a generic “SQL injection in Datasette” headline suggests. It only matters when a single database contains a mix of public and private tables, and access to those tables is mediated by Datasette permissions.
That combination is unusual, which is why the release notes call it rare. But when it exists, the risk is real: a user who can reach any public table could potentially inject SQL in a way that bypasses the intended table restrictions and read data from private tables in that same database.
For operators, the immediate mitigation is straightforward: disable the execute-sql permission on databases that contain private tables. If users do not need raw SQL access, removing that capability closes off the attack path while you roll out the patched release.
This is not a write-path compromise. The reported issue would have allowed read-only access to private data, not modification of the underlying SQLite database.
That still matters a lot in a publishing workflow. Datasette is often used to expose internal, staged, or partially redacted datasets where table-level visibility is the control plane. In that model, SQL execution is effectively an escape hatch around declarative access rules. Any bug in how query text is handled becomes a permissions bug, not just an injection bug.
The operational lesson is that raw SQL permissions should be treated as privileged even in read-only systems. If a database mixes public and private content, the safest posture is to avoid granting execute-sql at all unless the boundary is completely trusted.
The fix is available in two branches:
For teams pinned to the pre-1.0 line, the backport is useful because it lets you patch without adopting the newer release train. If you maintain a Datasette deployment with custom permission logic or a plugin-based authorization setup, this is worth prioritizing in the same way you would handle any other authz bypass: verify which databases expose mixed visibility, remove execute-sql where it is not essential, then upgrade to the patched version.
