SQLite Injection in Local-First Apps [2026 Deep Dive]

As of April 17, 2026, the sharpest lesson in SQLite security is not that SQLite itself is uniquely dangerous. It is that local-first software keeps feeding semi-trusted input into a database engine that many teams still treat as a private implementation detail. CVE-2026-33545 in MobSF made that boundary visible: a crafted SQLite table name from an analyzed app was later interpolated back into SQL inside the analyst's own tool.

That pattern maps directly onto local-first products. Offline clients import backups, merge sync state, inspect attached databases, replay operation logs, and run migration or search code on-device. The SQLite project itself notes that most real-world SQLite exploits require one of two preconditions: an attacker can submit SQL, or an attacker can supply a crafted database file that the application opens and queries. Local-first systems satisfy the second precondition far more often than classic server apps do.

This deep dive uses MobSF as the anchor incident, then generalizes the hardening rules for any local-first app built on SQLite, whether the stack is Electron, Tauri, native mobile, Python, Rust, or a sync-heavy desktop client.

CVE Summary Card

• CVE: CVE-2026-33545
• Product: MobSF SQLite database viewer utilities
• Affected versions: <= 4.4.5
• Patched version: 4.4.6
• Weakness: CWE-89, SQL injection through unsafe string interpolation of table names
• Severity: GitHub CNA scored it 5.3 Medium; NVD later enriched it to 6.5 Medium on April 3, 2026
• What actually happened: MobSF read table names from sqlite_master, then inserted that metadata into PRAGMA and SELECT statements without safe identifier handling
• Why local-first teams should care: the exploit starts from a crafted local database artifact, not a central server compromise

The primary vendor advisory is GitHub's GHSA-hqjr-43r5-9q58. The important engineering nuance is that the confirmed impact in the shipping code path was denial of service in the DB viewer, while the injected SELECT path was shown to be exploitable in isolation. That matters because teams often dismiss these incidents as non-issues once a first guardrail blocks the full chain. In practice, the existence of the injectable statement is the real failure: one refactor, one reordered call, or one alternate view path can turn partial impact into full data exposure.

Vulnerable Code Anatomy

The bug class is boring in the worst possible way. MobSF queried schema metadata, stored it in a variable, and then treated that variable as trusted SQL syntax later. The vulnerable pattern looked roughly like this:

def readsqlite(sqlitefile):
    con = sqlite3.connect(sqlitefile)
    cur = con.cursor()
    cur.execute("SELECT name FROM sqlitemaster WHERE type='table'")
    tables = cur.fetchall()

    for table in tables:
        tablename = table[0]
        cur.execute("PRAGMA tableinfo('%s')" % tablename)
        cur.execute("SELECT * FROM '%s'" % tablename)

There are two subtle points senior engineers should keep front-of-mind.

• First, schema metadata is still attacker-controlled input when the database file came from outside the trust boundary.
• Second, value parameterization does not solve identifier safety. Placeholders like ? protect values, not table names, column names, sort directions, JSON paths, or SQL operators.

This is why local-first apps are exposed even when the team believes it is already using parameterized queries everywhere. The dangerous surface is often the small, dynamic layer around the query builder: file viewers, export tools, ad hoc admin panels, sync debuggers, search filters, and migration helpers.

The safer pattern is to split value handling from identifier handling explicitly:

ALLOWEDTABLES = {'notes', 'attachments', 'opslog'}

def quoteident(name: str) -> str:
    if name not in ALLOWEDTABLES:
        raise ValueError('unexpected identifier')
    return '"' + name.replace('"', '""') + '"'

def readrows(conn, tablename, ownerid):
    sql = f'SELECT * FROM {quoteident(tablename)} WHERE ownerid = ?'
    return conn.execute(sql, (owner_id,)).fetchall()

The hard rule is simple: values get bound parameters; identifiers get allowlists or dedicated quoting helpers. If your query API cannot express that distinction clearly, the abstraction is working against you.

Attack Timeline

1. March 21, 2026: GitHub published MobSF advisory GHSA-hqjr-43r5-9q58, marking versions through 4.4.5 as affected and 4.4.6 as patched.
2. March 24, 2026: The issue appeared in OSV, preserving the root-cause analysis and attack scenario.
3. March 26, 2026: NVD published CVE-2026-33545.
4. April 3, 2026: NVD enrichment added references and a distinct 6.5 Medium score, higher than the CNA's 5.3 Medium.

MobSF was not an isolated fluke. The same pattern showed up repeatedly across 2025 and 2026. CVE-2025-8709 hit LangGraph's SQLite store when filter operators were concatenated into SQL. CVE-2026-32714 hit SciTokens when user-controlled fields were dropped into DELETE, INSERT, and SELECT statements via str.format(). The common denominator was not SQLite internals. It was application code promoting untrusted strings into SQL structure.

Exploitation Walkthrough

This walkthrough stays conceptual. No payloads, no copy-paste exploit strings, no working proof-of-concept.

1. An attacker finds a path to influence a database artifact or query-shaping field. In local-first products that can be an imported backup, a shared workspace database, a sync delta, a plugin cache, a replicated operation log, or even a user-visible filter object.
2. The app later reads data from that artifact and treats part of it as SQL structure rather than plain data. The risky fields are predictable: table names, column names, sort keys, JSON paths, operators, PRAGMA targets, and ATTACH paths.
3. When the app composes the query, the attacker-controlled fragment escapes the intended SQL context. At that point SQLite is no longer evaluating trusted application SQL. It is evaluating attacker-shaped SQL.
4. Impact depends on the code path. In MobSF the immediate effect was crashing or blinding the viewer. In an app with write access, the same class can become row disclosure, filter bypass, cache poisoning, destructive updates, or persistence tricks inside local state.
5. The local-first twist is operational, not magical: the attacker does not need shell access to the device. They only need influence over the data the client will eventually open and query.

That last point is why teams routinely underestimate the issue. They ask whether an attacker can send raw SQL to the app. The better question is whether an attacker can influence anything that the app later promotes into SQL syntax. If the answer is yes, the exploit surface exists even when every database lives on the user's machine.

Hardening Guide

1. Separate values from identifiers in code review

Make this a first-class review check. Bound parameters are mandatory for values. Identifiers require allowlists, schema maps, or deliberate quoting helpers. Never pass user-controlled table names, field names, operator names, or sort directions through a generic string formatter.

2. Turn off schema trust when reading untrusted databases

SQLite's SQLITEDBCONFIGTRUSTED_SCHEMA and PRAGMA trusted_schema exist for a reason. SQLite's own documentation says trusted schema defaults to on for legacy compatibility, but applications are advised to turn it off if possible. For local-first viewers, importers, or recovery tools, that should be your default posture.

3. Enable defensive mode on hostile inputs

SQLITEDBCONFIGDEFENSIVE disables language features that can deliberately corrupt the database file, including PRAGMA writable_schema=ON and direct writes to shadow tables. It is not a substitute for safe query construction, but it narrows post-injection blast radius.

4. Install an authorizer for inspection workflows

SQLite's sqlite3setauthorizer() and Python's Connection.set_authorizer() let you deny categories of operations at statement-compile time. For any feature that opens semi-trusted databases, deny schema mutation, attachment, and unnecessary write operations by policy, not by convention.

con.execute('PRAGMA trustedschema=OFF')
con.setauthorizer(authorizer)

# authorizer should deny writes and schema-changing actions
# for inspection-only code paths

5. Isolate import and preview paths

Do not open untrusted databases on the same long-lived connection pool that serves the user's primary workspace. Spin up a separate process or worker, use read-only access where possible, keep strict time and size budgets, and discard the connection after inspection. Local-first apps often get this backward by treating import code as a convenience feature rather than a hostile parsing pipeline.

6. Constrain sync semantics before they reach SQL

Your sync layer should replicate data, not query grammar. If the wire format allows arbitrary operators, field paths, or sorting fragments, you are importing a SQL abstraction problem into every client. Prefer enumerated filters and compile them from a fixed internal grammar.

7. Add regression tests around metadata, not just rows

Fuzz table names, column aliases, migration names, search keys, JSON path fragments, and sort fields. Most teams test row values because that is what users edit. Attackers target metadata because that is what developers splice into query text.

8. Sanitize artifacts before incident sharing

When you reproduce a database-driven incident, the sample often contains real workspace data, tokens, emails, or message bodies. Before sending traces or trimmed database extracts to vendors or customers, scrub them with TechBytes' Data Masking Tool. Security response gets slower when legal and privacy review become blockers.

Architectural Lessons

Local-first does not mean local trust

Engineers still casually equate on-device state with trusted state. That is the wrong model for modern collaboration software. If state can arrive through sync, import, workspace sharing, extensions, or mobile-to-desktop handoff, it is external input wearing a local costume.

SQLite metadata is executable context

Rows are not the whole attack surface. Table names, triggers, views, generated columns, virtual tables, and query-builder knobs all shape execution. The MobSF incident is memorable precisely because the dangerous value came from schema metadata, not from a text field an engineer would instinctively label untrusted.

Connection policy matters as much as query style

Many teams stop at placeholder binding. That is necessary but incomplete. SQLite offers connection-level defenses such as trusted_schema, defensive, authorizers, and resource limits. Use them to encode a least-privilege runtime for every risky workflow.

Patch the ecosystem, not just the engine

The 2025-2026 incident trail shows the same bug class recurring in viewers, caches, and query builders. Your patch program needs to watch wrappers and app code, not only upstream SQLite releases. When SQLite developers say many CVEs only matter if an attacker can submit SQL or a crafted database file, local-first teams should hear a warning: your product may satisfy those preconditions by design.

The durable lesson from CVE-2026-33545 is straightforward. The dangerous move was not using SQLite. The dangerous move was letting untrusted database state re-enter the system as executable SQL structure. If you fix that boundary, most SQLite injection stories collapse back into ordinary parser bugs. If you ignore it, your offline-first architecture becomes a delivery system for client-side SQL exploitation.