CVE-2026-51302: Technical Inconsistencies

sorry for the clickbait repo name but this CVE is complete and utter LLM hallucinated slop, honestly sad to see a CNA accept this with how inconsistent the claims are 💔

Conclusion

CVE-2026-51302 is not real 😱

The published SQL does not reproduce a use-after-free in any SQLite 3.41 release under AddressSanitizer. More importantly, the stated root cause is entirely incompatible with the affected source:

• exprComputeOperands() does not exist in SQLite 3.41.0, 3.41.1 or 3.41.2;
• that function was introduced on 30 June 2025, more than two years after SQLite 3.41;
• regFree1 is an integer virtual-machine register identifier, not a pointer to heap storage;
• sqlite3ReleaseTempReg() makes a register available for reuse and does not leave a dangling C pointer in regFree1;
• in source versions which contain exprComputeOperands(), operands are computed before the temporary registers are released, contrary to the advisory's stated sequence; and
• the published SQL contains no subquery operand and therefore does not exercise the optimisation for which exprComputeOperands() was introduced.

This CVE record should be rejected and I will be raising a CNA dispute with MITRE 😉

Advisories Claim

The advisory identifies the affected version as “SQLite 3.41” and supplies this query:

SELECT CASE WHEN (1+3) THEN (5*8) ELSE (2/0) END FROM test;

It claims that:

1. sqlite3ReleaseTempReg() frees heap memory associated with regFree1;
2. regFree1 remains as a dangling reference;
3. exprComputeOperands() subsequently accesses the freed memory; and
4. running the query against an ASan build produces a clear heap-use-after-free trace.

Source Analysis

sqlite3ReleaseTempReg() in SQLite 3.41

The SQLite 3.41.0 amalgamation defines the function as follows:

SQLITE_PRIVATE void sqlite3ReleaseTempReg(Parse *pParse, int iReg){
  if( iReg ){
    sqlite3VdbeReleaseRegisters(pParse, iReg, 1, 0, 0);
    if( pParse->nTempReg<ArraySize(pParse->aTempReg) ){
      pParse->aTempReg[pParse->nTempReg++] = iReg;
    }
  }
}

The function receives iReg as an int. It records that integer in pParse->aTempReg so the register number may be allocated again:

SQLITE_PRIVATE int sqlite3GetTempReg(Parse *pParse){
  if( pParse->nTempReg==0 ){
    return ++pParse->nMem;
  }
  return pParse->aTempReg[--pParse->nTempReg];
}

This is register-lifetime management during VDBE program generation. The advisory describes regFree1 as though it were a surviving pointer to freed heap storage. It is not:

int regFree1 = 0, regFree2 = 0;
int r1, r2;

r1 = exprVectorRegister(pParse, pLeft, i, regLeft, &pL, &regFree1);
r2 = exprVectorRegister(pParse, pRight, i, regRight, &pR, &regFree2);
codeCompare(pParse, pL, pR, opx, r1, r2, addrDone, p5, isCommuted);
sqlite3ReleaseTempReg(pParse, regFree1);
sqlite3ReleaseTempReg(pParse, regFree2);

The generated comparison consumes the register identifiers before they are released for reuse.

exprComputeOperands() did not exist

A blame search of the Git mirror found that exprComputeOperands() was introduced by:

e24f20a4f5a6d26cdaece58eff77619a4ee757b9
2025-06-30T10:30:47Z
Factor out the code that tries to avoid evaluating subquery operands if the other operand is NULL into a subroutine, so that it can be more easily reused by other parts of the code generator.

The function is absent from all three official SQLite 3.41 amalgamations. A vulnerability in SQLite 3.41 cannot follow an execution path through a function which was introduced in 2025, come on MITRE really? 🥲

The claimed operation order is backwards

In modern SQLite source, the abridged call order in sqlite3ExprIfTrue() is:

addrIsNull = exprComputeOperands(
    pParse, pExpr, &r1, &r2, &regFree1, &regFree2);

codeCompare(
    pParse, pExpr->pLeft, pExpr->pRight, op,
    r1, r2, dest, jumpIfNull, ExprHasProperty(pExpr, EP_Commuted));

/* Other switch cases and generated-bytecode handling occur here. */

sqlite3ReleaseTempReg(pParse, regFree1);
sqlite3ReleaseTempReg(pParse, regFree2);

exprComputeOperands() produces the register identifiers. The caller consumes them then releases them. The advisory instead claims that sqlite3ReleaseTempReg() runs first and exprComputeOperands() later accesses the released object.

The published query does not match the modern function

exprComputeOperands() was introduced to avoid evaluating an expensive subquery operand when the other operand is NULL. The published expression:

CASE WHEN (1+3) THEN (5*8) ELSE (2/0) END

contains arithmetic operations and a CASE expression but no subquery operand. The rationale given for this query does not correspond to the functions call conditions.

Extras

Environment

vm btw

Debian GNU/Linux 13 (trixie)
Clang 19.1.7
AddressSanitizer enabled
Optimisation level: -O1
Frame pointers retained
Sanitizer recovery disabled

Amalgamation SHAs:

3.41.0  146ce189b67fdbefbf2d72cdc81e198d07ff643614cc9102e9bf063255e8e7e1
3.41.1  df0d54bf246521360c8148f64e7e5ad07a4665b4f902339e844f4c493d535ff5
3.41.2  01df06a84803c1ab4d62c64e995b151b2dbcf5dbc93bbc5eee213cb18225d987
3.53.3  646421e12aac110282ef8cc68f1a62d4bb15fc7b8f09da0b53e29ee690500431

Link dump 😁

• Public advisory: https://github.com/programmervuln/cveadvisory-/blob/main/CVE-2026-51302
• CVE Record: https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/51xxx/CVE-2026-51302.json
• SQLite release history: https://www.sqlite.org/changes.html
• SQLite 3.41.0 release: https://www.sqlite.org/releaselog/3_41_0.html
• SQLite 3.41.1 release: https://www.sqlite.org/releaselog/3_41_1.html
• SQLite 3.41.2 release: https://www.sqlite.org/releaselog/3_41_2.html
• Function introduction: https://github.com/sqlite/sqlite/commit/e24f20a4f5a6d26cdaece58eff77619a4ee757b9