LibreDB Studio 0.16.2 fixes a session-boundary failure in its database cache

LibreDB Studio has released 0.16.2 to fix a provider-cache flaw that could let any signed-in user reuse another user’s live database connection. The project’s security advisory says an attacker could supply the victim connection’s ID and receive the already-authenticated provider stored under that key, rather than creating a connection from the credentials in the new request.

That distinction matters for database-agent operators. LibreDB documents a read-only agent that drafts SQL, reads results and writes reports whose claims cite those results. Its README says agent statements run through an audited pipeline and engine-specific read-only execution profiles. But the advisory says the vulnerable cache lookup also existed on the agent path. In other words, read-only SQL controls did not establish whose connection the agent was using.

The cache confused identity with a label

Before the patch, LibreDB cached a live provider using a caller-supplied connection.id. A later request naming the same ID could receive that provider without proving that its endpoint and credentials matched the original. The advisory says the ordinary /api/db/query path required a session but not a privileged role; inline connection data could also claim a seed: ID and bypass the role filter normally applied to administrator-managed seed connections.

The impact was broader than unwanted reads. According to the advisory, the inherited provider carried the original user’s database rights, so a less-privileged Studio account could execute SQL with those credentials. Supplying a different timeout against the same cache entry could also disconnect and evict the victim’s provider.

What 0.16.2 changes

The 0.16.2 release incorporates pull request 1027. The new cache key combines the stored ID with a fingerprint of the database endpoint and a SHA-256 digest of the credentials, using length-prefixed components. The ID remains metadata on the entry for cleanup and lookup operations, while inline requests can no longer claim the reserved seed: namespace. LibreDB says it reproduced both vulnerable paths against the real SQLite driver and converted those reproductions into regression tests, including agent execution profiles.

This is a useful separation of controls for any multi-user database agent. A read-only transaction limits what a correctly selected connection may do. It does not prove that a cache, pool or tool router selected the correct user’s connection in the first place. That boundary needs its own tests: two accounts, the same public connection label, different endpoints or secrets, and assertions that no provider object, result or cleanup action crosses between them.

LibreDB’s advisory recommends upgrading to 0.16.2. It says the only mitigation before upgrading is to trust every account able to reach the instance—an unusually clear signal that this is an isolation fix, not merely cache hardening.