rules-sqlite

RISK: ATTACH DATABASE with interpolated paths enables path traversal and lets attackers attach malicious DB files (which can pivot via triggers if trusted_schema=ON). FIX: Allowlist filenames; pass them through bound parameters or hard-code paths.

RISK: better-sqlite3 db.exec(str) runs ALL semicolon-separated statements with no parameter binding — direct injection if str is user-derived. FIX: Use db.prepare(sql).run(params) and split DDL into separate prepared statements.

RISK: sqlite3_exec() with a non-literal SQL argument runs every semicolon-separated statement and is the classic C-API injection sink. FIX: Use sqlite3_prepare_v2() + sqlite3_bind_*() and step a single statement at a time.

RISK: fts3_tokenizer() lets SQL register a function-pointer tokenizer — a known RCE vector (CVE-2019-8457 family) when callable from untrusted SQL. FIX: Avoid the legacy two-arg fts3_tokenizer(); compile with -DSQLITE_ENABLE_FTS3_TOKENIZER off and use FTS5.

RISK: Loadable SQLite extensions allow arbitrary native code execution via .so/.dll (CVE-2019-8457 class). FIX: Keep sqlite3_enable_load_extension(db, 0); never call load_extension() on untrusted input.

RISK: SQLCipher PRAGMA key='...' embeds the encryption key in source/SQL logs/traces. FIX: Use sqlite3_key_v2() C API or your binding's keyed-open with secrets pulled from a secret manager.

RISK: cursor.executescript() runs multiple semicolon-separated statements with implicit commit — a direct SQL-injection sink (PEP 249). FIX: Call execute() per statement with bound ? parameters.

RISK: String-built SQL is the #1 SQLite injection vector. FIX: Use parameter placeholders (? or :name) and bind values; never concatenate user input into SQL.

RISK: Opening with uri=True and a user-controlled file: URI lets the caller select VFS, enable mode=memory, swap journal files, etc. FIX: Disable URI mode or strictly validate the path and strip query parameters.

RISK: check_same_thread=False without an explicit mutex causes race conditions and DB corruption — Python's sqlite3 connections are not thread-safe. FIX: Use one connection per thread, or wrap the connection in a Lock.

RISK: foreign_keys=OFF lets orphaned rows accumulate, breaking referential integrity assumptions in app code. FIX: Set PRAGMA foreign_keys=ON on every new connection (it is per-connection, not persistent).

RISK: better-sqlite3 < 11.10 bundles SQLite older than 3.50.2, which is vulnerable to CVE-2025-6965 / CVE-2025-29087 (integer overflows leading to memory corruption). FIX: Bump to better-sqlite3 ≥ 11.10.0 (SQLite 3.50.2+).

RISK: cell_size_check=OFF disables a defensive integrity check that mitigates malformed-DB exploits. FIX: Leave the default ON, especially when opening DB files from untrusted sources.

RISK: journal_mode=OFF / synchronous=OFF disables crash recovery — a single power loss corrupts the database. FIX: Use WAL + synchronous=NORMAL in production; only disable in throwaway test fixtures.

RISK: Placing a .db/.sqlite file in a web-served directory exposes the entire database for download. FIX: Store DB files outside the web root (e.g. /var/lib/app).

RISK: Shared-cache mode is officially discouraged by SQLite (concurrency/corruption pitfalls, see sqlite.org/sharedcache.html). FIX: Use WAL journal mode for concurrent readers/writers instead.

RISK: trusted_schema=ON lets malicious triggers/views/virtual-tables in attached DBs invoke unsafe functions. FIX: Keep PRAGMA trusted_schema=OFF (the default since 3.31).

RISK: PRAGMA writable_schema=ON allows arbitrary modification of sqlite_master enabling persisted RCE via crafted triggers. FIX: Remove the PRAGMA; use ALTER TABLE / migrations instead.