sqlite-fts5-securedel

Class: Crash Reach: Local

SQLite 3.53.4 (b09c88c14082339b66c7b7158d609a771e64ca69) - Hwaci

fts5DoSecureDelete rebuilds an FTS5 leaf footer with sqlite3Fts5PutVarint after nPg = iPgIdx. Footer-decoded key offsets are not capped against the original blob, so the PutVarint cursor walks off nn + FTS5_DATA_PADDING (20). Typical extra SQLITE_ENABLE_FTS5. The attack database already used secure-delete.

This is a leftover of later trunk Fossil 9cd4f9e920 / Git d9de6eedbe91 / branch-3.53 34171bee08 (2026-08-11, YEONBA). That check-in is after this GA. It is not CVE-2026-11824: fts5LeafRead already rejects szLeaf<4 on this pin.


ID	no CVE yet
Class	Crash (ASan WRITE of size 1; not demonstrated RCE)
Reach	Local (open a crafted FTS5 database, then DELETE/flush)
CWE	CWE-787
CVSS	High: 7.5 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`
Product	SQLite (GitHub mirror sqlite/sqlite)
Affected	3.53.4 SOURCE_ID `2026-07-24 19:02:57 bf7c7f30031888f4e796e429ab3978879485813aaca6f641c7b33e4e09459bcc`
Auth	none (untrusted index file)
License	GNU Affero GPL v3.0
Lab	`127.0.0.1:18860` only. ASan heap write. No RCE payload.

What an attacker can do

Open a crafted FTS5 database that already used secure-delete, then DELETE (or any write that flushes a secure-delete) so fts5DoSecureDelete writes footer varints past Fts5Data. Crash / ASan heap write of size 1. Not demonstrated RCE. Not CVE-2026-11824.

MATCH-only is not this sink. The trigger is DELETE/flush. Crafted file does not need SQLITE_DBCONFIG_DEFENSIVE off.

How I found it

Twenty source hunts of SQLite 3.53.4 after other database and HTTP-server pins. CVE-2026-11822 / CVE-2026-11824 is closed on this tree (fts5LeafRead szLeaf<4). YEONBA's later trunk bound is not. The 3.53.4 fts5corruptB.test file still ends at test 3.2; trunk test 4.0 is the hexdb plus DELETE FROM t WHERE rowid = 1.

iPgIdx -= nShift;
nPg = iPgIdx;
fts5PutU16(&aPg[2], iPgIdx);

for(iIdx=0; iIdx<nIdx; /* no-op */){
  u32 iVal = 0;
  iIdx += fts5GetVarint32(&aIdx[iIdx], iVal);
  iKeyIn += iVal;
  if( iKeyIn!=iDelKeyOff ){
    int iKeyOut = (iKeyIn - (iKeyIn>iOff ? nShift : 0));
    nPg += sqlite3Fts5PutVarint(&aPg[nPg], iKeyOut - iPrevKeyOut);
    iPrevKeyOut = iKeyOut;
  }
}

ext/fts5/fts5_index.c:5514-5544. iKeyIn is a 32-bit int. Later trunk keeps original nPg, uses i64 iKeyIn, and rejects iKeyIn>nPg before PutVarint.

Wrong turns: treating CVE-2026-11824 as this bug; MATCH instead of DELETE; a live CREATE/INSERT plant that kept szLeaf in range and did not overflow; calling Winter's WAL-plus-FTS5 chain RCE without a payload.

Lab

cd lab
./run.sh

ASan amalgamation from official sqlite-src-3530400 zip, -DSQLITE_ENABLE_FTS5. Hexdb lab/yeonba-fts5corruptB-4.hexdb (trunk fts5corruptB.test 4.0) is required. Bind loopback 127.0.0.1:18860. Compose project sqlite-fts5-securedel.

SUCCESS sqlite-fts5-securedel how=asan-heap-buffer-overflow-write-1-fts5DoSecureDelete db=yeonba-hexdb bytes=5120 SQLITE-FTS5-SECUREDEL-WITNESS

ASan frames: fts5PutVarint64 -> sqlite3Fts5PutVarint -> fts5DoSecureDelete / fts5FlushSecureDelete.

The fix

Keep original nPg. Widen iKeyIn to i64. Reject iKeyIn>nPg before sqlite3Fts5PutVarint. That is Fossil 9cd4f9e920 / branch-3.53 34171bee08. Cherry-pick it onto 3.53.

References

https://sqlite.org/src tag version-3.53.4 Git b09c88c14082339b66c7b7158d609a771e64ca69
ext/fts5/fts5_index.c fts5DoSecureDelete, fts5FlushSecureDelete, fts5LeafRead
ext/fts5/fts5_varint.c sqlite3Fts5PutVarint
Trunk fix Fossil 9cd4f9e920 / Git d9de6eedbe91 / branch-3.53 34171bee08 (2026-08-11, YEONBA)
CVE-2026-11824 is the closed szLeaf<4 parent, not this leftover

sqlite-fts5-securedel

Most Popular

sqlite-fts5-securedel

What an attacker can do

How I found it

Lab

The fix

References