CVE-2026-39113: 
SQLite vulnerability analysis and mitigation

CVE-2026-39113 is a heap-based buffer overflow (CWE-122) in SQLite's optional SQLAR extension (ext/misc/sqlar.c), specifically in the sqlarUncompressFunc() / sqlar_uncompress() functions. The vulnerability was introduced on 2026-03-11 by Git commit 169f68e (Fossil check-in 8bdc0d485e3a...) and corrected on 2026-04-01 by commit 34e139d. Only source snapshots and custom builds within that window are affected; no official SQLite release is confirmed vulnerable — SQLite 3.52.0 predates the flaw and SQLite 3.53.0 contains the fix. The CVE has a CVSS v3.1 base score of 4.0 (Medium) with a local attack vector and low availability impact (Feedly, PoC Repo).

The root cause is a type-width mismatch introduced when sqlite3_value_int() (32-bit) was replaced with sqlite3_value_int64() (64-bit) in sqlarUncompressFunc() without updating the corresponding heap allocation call. On LP64 systems, the attacker-controlled SZ value (e.g., 4294967328 / 0x100000020) is stored as a 64-bit sqlite3_int64, but passed to sqlite3_malloc(int), which silently truncates it to 32 bits — allocating only 32 bytes. Meanwhile, zlib's uncompress() receives the full 64-bit value as the output buffer size, allowing it to write far beyond the small heap allocation. The fix in commit 34e139d replaces sqlite3_malloc(sz) with sqlite3_malloc64(sz) to keep allocation width consistent with the 64-bit size (SQLite Commit, PoC Repo).

Successful exploitation causes an out-of-bounds heap write within the host process, leading to process crash and denial of service, as confirmed by AddressSanitizer output showing a heap-buffer-overflow immediately after a 40-byte allocation. Code execution was not demonstrated and would require additional conditions such as favorable allocator layout and absence of memory-safety mitigations. The vulnerability is limited in scope: it requires the optional SQLAR extension to be loaded and an attacker-controlled call to sqlar_uncompress() with a crafted blob and size argument — it is not reachable in default SQLite deployments (PoC Repo, Feedly).

A public proof-of-concept is available on GitHub, consisting of poc/verify_sqlar_poc.c and poc/reproduce.sh, which build SQLite and zlib with AddressSanitizer and reliably trigger the heap-buffer-overflow (PoC Repo). The PoC was re-run on 2026-08-21 on Ubuntu 24.04 under WSL2 and produced the same AddressSanitizer finding. There is no evidence of in-the-wild exploitation, no threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.0028 (low probability of exploitation), and NVD's SSVC assessment classifies exploitation as "none" with partial technical impact (Feedly).

1. Identify target: Confirm the target application loads SQLite's optional SQLAR extension (sqlar.so or equivalent) and allows SQL function invocation, including sqlar_uncompress().
2. Prepare compressed payload: Create a small compressed blob (e.g., 42 bytes representing 4096 bytes of decompressed data using zlib compress()).
3. Craft malicious SZ value: Select a 64-bit integer whose low 32 bits are small (e.g., 4294967328 = 0x100000020, which truncates to 32 when cast to int).
4. Invoke the vulnerable function: Execute the SQL query SELECT sqlar_uncompress(?, ?) supplying the crafted compressed blob as argument 1 and the malicious SZ value as argument 2.
5. Trigger overflow: sqlarUncompressFunc() allocates only 32 bytes via sqlite3_malloc(int) but passes the full 64-bit value to zlib's uncompress(), which writes beyond the heap allocation boundary, causing a crash (DoS) (PoC Repo).

• Process: Unexpected crash or abort of the SQLite-hosting process, particularly with AddressSanitizer output referencing inflate_fast, uncompress, or sqlarUncompressFunc in the stack trace.
• Logs: Application error logs showing heap-buffer-overflow WRITE or ABORTING messages from AddressSanitizer; error messages from sqlar_uncompress() such as error in uncompress().
• File System: Presence of sqlar.so loaded by an application that does not require SQLAR archive functionality.
• Network/Input: SQL queries or application inputs supplying a compressed blob alongside an unusually large integer (e.g., values exceeding INT_MAX such as 4294967296+) to sqlar_uncompress() (PoC Repo).

The upstream fix is present in the official SQLite 3.53.0 release (commit 34e139d), which changes the allocation from sqlite3_malloc(sz) to sqlite3_malloc64(sz) in sqlarUncompressFunc(). Users of source snapshots or custom builds from the affected window (commits 169f68e through the parent of 34e139d) should update to commit 34e139d or later, or upgrade to official SQLite 3.53.0. As a workaround, applications that do not require SQLAR functionality should avoid loading the extension, and applications that do use it should prevent untrusted callers from supplying arbitrary arguments to sqlar_uncompress() (PoC Repo, SQLite Commit).

The vulnerability was noted by DarkWebInformer on social media shortly after disclosure. The PoC repository received attention on Vulners and Sploitus aggregators. No major vendor statements or significant researcher commentary beyond the PoC author's detailed advisory have been identified (Feedly).