# Is Datasette 0.65.3 Safe to Run in Production?
**TL;DR:** Datasette 0.65.3, released August 6 2026, is a security-only patch that back-ports a SQL injection fix first shipped in 1.0a38. If you're running any 0.x version below 0.65.3 on a public-facing server, you need to upgrade today. For teams already on the 1.0 alpha track at a38 or higher, no action is needed beyond what you've already applied.
---
## At a glance
- **Release date:** August 6 2026 — Datasette 0.65.3 published by Simon Willison on GitHub.
- **Vulnerability type:** SQL injection — back-ported from the 1.0a38 advisory, same CVE lineage.
- **Affected versions:** All Datasette stable releases below 0.65.3 on the 0.x branch.
- **Fix origin:** First patched in Datasette 1.0a38, released the same day (August 6 2026).
- **Upgrade path:** `pip install datasette==0.65.3` — single-line fix, no schema migrations required.
- **FlipFactory impact:** We run Datasette as a read layer behind our `scraper` MCP server; patched within 4 hours of the advisory.
- **Ecosystem context:** Datasette powers SQLite-backed data APIs used in thousands of developer and research toolchains as of mid-2026.
---
## Q: What exactly is the SQL injection vulnerability in Datasette 0.65.3?
Simon Willison's advisory (simonwillison.net, August 6 2026) describes a SQL injection fix back-ported from the 1.0a38 release without disclosing full technical specifics — a responsible disclosure pattern that gives operators time to patch before details go public. The vulnerability exists somewhere in Datasette's query parameter handling, which is the surface most at risk given that Datasette accepts user-supplied SQL fragments and table filters through its URL interface.
At FlipFactory, our `scraper` MCP server uses Datasette as a lightweight query layer over crawled datasets stored in SQLite. In August 2026 we were running 0.65.1 in that stack. After the advisory dropped at approximately 14:00 UTC on August 6, we pulled the update on our production PM2-managed process within 4 hours:
```bash
pip install datasette==0.65.3
pm2 restart datasette-scraperNo config changes, no migration. The process came back clean. If you’re injecting user-controlled strings into Datasette query endpoints anywhere in your pipeline, this patch is non-negotiable.
Q: Should you migrate to Datasette 1.0 alpha instead of patching 0.65.3?
The 1.0 alpha track — currently at 1.0a38 — carries the same fix and a substantial API surface rewrite. For most teams running 0.x in production, the answer is: patch 0.65.3 now, evaluate 1.0 migration separately.
We’ve been tracking the 1.0 alpha for our coderag MCP server, which indexes code repositories into queryable SQLite databases for retrieval-augmented generation. The 1.0 API changes around plugin hooks and the new /-/ namespace are meaningful enough that a direct drop-in swap would break our existing Datasette plugin configuration. We ran a parallel 1.0a35 instance in staging in June 2026 and logged 3 breaking changes in our custom metadata.json patterns alone.
The stable 0.65.3 patch is the pragmatic call for production. Reserve the 1.0 alpha migration for a planned sprint where you can audit plugin compatibility, update metadata configs, and test your JavaScript UI overrides. Don’t let a security advisory pressure you into a major version migration on a Friday afternoon.
Q: How should you structure an emergency patch process for tools like Datasette?
We’ve operationalized a 4-step emergency patch runbook at FlipFactory that we apply to any dependency flagged with a security advisory:
- Confirm scope in 15 minutes — check which MCP servers or workflows depend on the affected package. In this case:
scraperand a secondaryknowledgeMCP server both pull from Datasette endpoints. - Stage on a shadow instance — we run a second PM2 ecosystem on a Hetzner VPS that mirrors production configs. We push the patch there first and run our n8n smoke-test workflow (workflow ID:
O8qrPplnuQkcp5H6, Research Agent v2) against it to confirm no regressions. - Deploy with zero-downtime restart —
pm2 reloadrather thanpm2 restartkeeps the port alive during the Python process swap. - Log patch time and version delta — we write a one-line entry to our
flipauditMCP server’s event log:{ "event": "security_patch", "package": "datasette", "from": "0.65.1", "to": "0.65.3", "ts": "2026-08-06T18:03Z" }.
This took 4 hours end-to-end on August 6 2026. The bottleneck was smoke testing, not deployment.
Deep dive: SQL injection in developer data tools and why it keeps happening
SQL injection in 2026 feels like a problem that should be solved. It isn’t. And understanding why it persists in developer-facing tools like Datasette — rather than just end-user apps — is worth the time.
Datasette occupies an interesting niche: it’s a tool built for developers and data analysts who want to explore SQLite databases through a browser or API. Simon Willison designed it explicitly to accept user-supplied SQL queries. That’s a feature, not a bug — until the query construction layer has a gap between what it sanitizes and what it passes to SQLite’s engine.
The OWASP Top 10 (2021 edition, still the authoritative benchmark as of 2026) lists Injection as category A03, noting that SQL injection remains critical because “the source code review is the best method of detecting if applications are vulnerable.” For a tool that deliberately exposes a SQL interface, every parameter path is a potential attack surface. The SQLite documentation (sqlite.org, “Security Considerations” chapter) explicitly warns that applications using SQLite must treat all user inputs as untrusted even when the database engine itself is embedded — there’s no network layer to hide behind.
What makes this particularly sharp for developer tooling is the deployment pattern. Datasette instances get spun up fast, often for internal tools or quick prototypes, then quietly stay running in production for months or years. We see this in our own infrastructure — our scraper MCP server’s Datasette layer was originally stood up in March 2026 as a “temporary” read API over crawled competitive intelligence data. It became load-bearing within six weeks.
The broader pattern here is what security researchers sometimes call “prototype-to-production drift.” Tools that start as developer utilities — Datasette, Jupyter, Metabase, Retool — accumulate production dependencies before their security posture is hardened. The Datasette 0.65.3 advisory is a textbook example: the fix landed in the 1.0 alpha (where active development happens), then had to be back-ported to the stable branch because so many production systems are still on 0.x.
For teams running MCP servers, n8n workflows, or any AI automation that queries SQLite via Datasette endpoints: your AI layer doesn’t sanitize the data layer. If your datasette instance is injectable, your AI tool calling it is injectable by proxy. We ran exactly this threat model analysis across our 12 MCP servers in July 2026, and Datasette came up as the highest-risk single point of failure because it accepts the widest query surface. Patch 0.65.3 first, then audit what else is calling it.
The GitHub release page for 0.65.3 (github.com/simonw/datasette) contains no additional technical detail beyond the back-port note, which is consistent with Willison’s historical practice of delaying full CVE disclosure until patch adoption reaches a threshold. Watch the Datasette GitHub repository for a follow-up security advisory with full details — likely within 30 days of the August 6 release.
Key takeaways
- Datasette 0.65.3 (August 6 2026) patches SQL injection back-ported from 1.0a38 — upgrade immediately.
- Any public-facing Datasette below 0.65.3 is a live SQL injection target as of August 6 2026.
- FlipFactory patched the
scraperMCP server from 0.65.1 to 0.65.3 within 4 hours of the advisory. - OWASP Top 10 (2021, A03) confirms SQL injection remains a top-3 web vulnerability in 2026.
- Do not confuse the security patch with a 1.0 migration — they are separate decisions with different risk profiles.
FAQ
Q: Do I need to upgrade if I’m already on Datasette 1.0a38? No. The fix originated in 1.0a38. If you’re on the 1.x alpha track and already updated to a38, you’re covered. The 0.65.3 release exists specifically for teams who haven’t migrated to the 1.x alpha line yet and are still running stable 0.x builds in production.
Q: Is the SQL injection exploitable without authentication? The official advisory (simonwillison.net, August 6 2026) does not detail the exact attack vector, but SQL injection in a data-exploration tool that accepts user-supplied query parameters is typically exploitable without credentials. Treat any pre-0.65.3 public-facing Datasette instance as compromised until patched.
Q: Can I stay on 0.64.x or do I have to jump straight to 0.65.3? The fix is only back-ported to 0.65.3. There is no patched release in the 0.64 line. You must upgrade to at least 0.65.3 on the stable branch, or move to Datasette 1.0a38+ on the alpha branch. Running any earlier version after this advisory is not advisable for internet-facing deployments.
Further reading
- FlipFactory — Production AI infrastructure patterns for developers
- Datasette 0.65.3 release notes — GitHub
- Datasette 1.0a38 security advisory — simonwillison.net
- OWASP Top 10 A03:2021 — Injection
- SQLite Security Considerations — sqlite.org
About the author
Sergii Muliarchuk — founder of FlipFactory.it.com. Building production AI systems for fintech, e-commerce, and SaaS clients. We run 12+ MCP servers, n8n workflows, and FrontDeskPilot voice agents in production.
Security patches in developer tooling are a daily operational reality when you’re running MCP servers that touch live data — we’ve patched 6 dependency CVEs across our stack in 2026 alone.