Datasette 0.65.5 Released: Fixes Table Permission Bypass Security Vulnerability

Release Overview

Datasette has released version 0.65.5, a security-focused patch update. The core change addresses a permission bypass vulnerability that could lead to private data exposure. For anyone using Datasette to serve data externally, this is an update worth immediate attention and upgrade.

Datasette is an open-source tool developed by Simon Willison that publishes SQLite databases as explorable, queryable web interfaces and JSON APIs in read-only mode. Because it is commonly used to publish data externally, the reliability of its access control directly impacts data security.

Datasette's permission system supports access control policies configured at the instance, database, and table levels — typically declared via metadata.json or plugins to specify which users or API tokens can access particular resources. Table-level permissions allow different tables within the same database to be individually set as public or private, a feature widely used in multi-tenant data publishing, and scenarios where internal sensitive data and public data are hosted together. Because table-level permissions carry the core responsibility of isolating sensitive data, any vulnerability capable of bypassing this layer is directly equivalent to unauthorized access to private data.

Vulnerability Details: A Permission Bypass Caused by a Single Newline

The issue fixed in this release is that when the requested table name contains a trailing newline character, the table-level permission check can be bypassed, exposing private row data that should have been protected.

This type of vulnerability is not uncommon in web applications. Its essence is an inconsistency between input normalization and permission validation. The table name identifier used during permission checking differs subtly from the one used in the actual data query — a single invisible newline character is enough for the permission layer to "fail to recognize" the target table and allow through a request that should have been blocked.

The issue was reported by dpfkdlemtp and disclosed via GitHub Security Advisory GHSA-h547-rmjf-5m2m. Handling it responsibly through the security advisory mechanism also reflects the project's mature vulnerability response process.

From a technical implementation perspective, the root cause of this type of "normalization inconsistency" vulnerability typically lies in the permission check and data access layers each receiving and processing user input separately, without sanitizing or normalizing the input at a unified entry point. In web requests, newline characters in URL paths or query parameters (%0A or literal \n) are valid encoded characters that the HTTP layer does not automatically filter. If the permission check code uses exact string matching to look up the access policy for a table name, table and table\n are treated as two different keys — the latter finds no matching rule and is allowed through by default. Meanwhile, the underlying SQLite query, when actually executed, typically ignores or trims the trailing character and still hits the actual private table. This pattern — where "the identifier seen by the permission layer" differs from "the identifier operated on by the execution layer" — recurs in classic vulnerabilities like Path Traversal and IDOR (Insecure Direct Object Reference). It is a textbook counterexample to the secure coding principle: "validate before use, and ensure the input validated and the input used come from the same source."

Scope of Impact and Upgrade Recommendations

The primary affected targets are Datasette instances that have table-level permissions configured to isolate private data. If your deployment is entirely public data with no reliance on the permission system for access control, the practical risk is relatively low. However, any scenario involving "some tables being private" warrants an immediate upgrade to 0.65.5.

Security patches are characterized by minimal changes, low upgrade risk, and high benefit. Affected users are advised not to delay — update to the fixed version as soon as possible, and also review any custom logic in your deployment that relies on table names for permission checks, to avoid similar normalization inconsistency issues.

Summary

0.65.5 is just a patch release, but it serves as a reminder of a universal security lesson: permission checks must be built on normalized identifiers that are consistent with what is actually being operated on. Any approach that uses different forms of input in the permission check versus the data access layer creates an opportunity for attackers to exploit. For Datasette users, upgrading promptly is the most direct and effective response.