CVE-2025-6965

What it actually does

SQLite versions before 3.50.2 contain a memory corruption vulnerability in aggregate query handling: the number of aggregate terms can exceed the number of available result columns, causing SQLite to access or write memory incorrectly while compiling or executing a crafted SQL statement. Depending on how SQLite is embedded and compiled, exploitation can result in process crashes, corrupted application state, data integrity impact, or potentially attacker-controlled code execution within the privileges of the vulnerable process. The issue is most relevant where untrusted users can influence SQL text, query-building logic, database views/triggers, extensions, or imported database content processed by an application using vulnerable SQLite.

Why it matters to the business

Because SQLite is embedded in many applications, appliances, mobile apps, desktop software, agents, browsers, and backend services, vulnerable copies may exist even where SQLite is not installed as a standalone package. Successful exploitation can disrupt service availability through crashes, corrupt local application data, or compromise the application process that embeds SQLite. The vulnerability has a high EPSS score and public exploit availability, so organizations should prioritize discovery and upgrades despite the issue not currently appearing in the CISA KEV catalog or being marked as ransomware-associated.

How an attack unfolds

An attacker first identifies an application, service, API, plugin, file-processing workflow, or client-side feature that uses a vulnerable SQLite library and allows the attacker to influence SQL statements or SQLite database objects that will be parsed or executed. The attacker then supplies a specially crafted SQL query or database artifact involving aggregate expressions arranged so the aggregate term count exceeds the available column count. When the vulnerable SQLite engine processes the crafted input, its internal accounting becomes inconsistent and memory corruption occurs. In lower-impact cases this causes a denial-of-service crash of the embedding process; in higher-impact cases, especially where memory protections are weaker or the attacker can repeat attempts and shape memory layout, the flaw may be used to alter memory and potentially execute code with the privileges of the affected application. Exploitation is rated high complexity and requires specific preconditions, but exploit availability and the broad use of SQLite increase operational risk.

How to fix it

Upgrade all embedded and packaged SQLite instances to SQLite 3.50.2 or later. For source-based consumers, ensure the SQLite tree includes fix commit 9d7c5df7f0e42528bf514b5231d58273bea47e40 or a later upstream revision. Because SQLite is commonly vendored, do not rely only on operating system package checks; inspect application bundles, containers, static binaries, mobile apps, agents, appliances, language runtime packages, and third-party products that ship their own sqlite3 library or amalgamation source. Rebuild and redeploy applications that statically link SQLite. Where immediate upgrade is not possible, reduce exposure by preventing untrusted users from supplying raw SQL, disabling database import from untrusted sources, validating or constraining query-builder inputs, sandboxing file parsers and applications that process SQLite databases, and running affected processes with least privilege and modern exploit mitigations enabled.

How to confirm the fix worked

Confirm remediation by checking that every runtime SQLite library and statically linked copy reports version 3.50.2 or later, or that the source contains commit 9d7c5df7f0e42528bf514b5231d58273bea47e40 or later. Use software composition analysis, binary inventory, container image scanning, mobile/desktop application inspection, and dependency review to find vendored copies of sqlite3.c, sqlite3.h, libsqlite3.so, sqlite3.dll, libsqlite3.dylib, or statically linked SQLite symbols. Validate application behavior by running regression tests for features that use aggregate queries, report generation, search, filtering, local database import, and sync workflows. For high-risk software, perform negative testing with malformed aggregate-heavy SQL in a non-production environment and confirm no crashes or sanitizer findings occur after the upgrade.

Typical attack path

1. Find software that embeds SQLite before version 3.50.2 or a vulnerable source snapshot before commit 9d7c5df7f0e42528bf514b5231d58273bea47e40.
2. Identify an input path that reaches SQLite parsing or execution, such as user-controlled search/filter syntax, report builders, local database import, sync data, plugin content, or application features that construct SQL from user input.
3. Craft SQL or SQLite database content containing aggregate expressions that trigger the aggregate-term/column-count mismatch.
4. Deliver the crafted input through the exposed application workflow or by convincing the target application to open/process a malicious SQLite database file.
5. Cause memory corruption in the process embedding SQLite.
6. Use the resulting condition to crash the process, corrupt application data, or attempt further exploitation for code execution depending on process privileges and exploit reliability.

How to detect it

Look for evidence that applications embedding SQLite processed malformed aggregate-heavy SQL or untrusted SQLite database content shortly before crashes, restarts, memory exceptions, or data corruption. Relevant sources include application logs, API/request logs for query/report/filter features, database import logs, endpoint crash dumps, service manager restart logs, EDR telemetry, container crash events, Windows Event Logs, macOS crash reports, Linux systemd/journald logs, kernel OOM/segfault messages, sanitizer output, and core dumps. Investigate repeated faults in processes using libsqlite3, sqlite3.dll, libsqlite3.dylib, or statically linked sqlite3 symbols, especially where stack traces reference SQLite query compilation or aggregate processing. Correlate suspicious requests or files with crashes containing access violations, segmentation faults, heap corruption, AddressSanitizer findings, or stack traces in SQLite routines. Because no universal network signature or payload string is publicly derivable from the advisory alone, detection should focus on anomalous SQLite crashes and preceding attacker-controlled SQL or database import activity.

• SQLite version 3.50.1
• SQLite version 3.50.0
• SQLite version 3.49.
• SQLite version 3.48.
• libsqlite3.so
• sqlite3.dll
• libsqlite3.dylib
• sqlite3.c
• sqlite3.h
• Segmentation fault
• segfault
• SIGSEGV
• EXC_BAD_ACCESS
• Access violation
• heap-buffer-overflow
• heap-use-after-free
• AddressSanitizer
• UndefinedBehaviorSanitizer
• corrupted size vs. prev_size
• malloc(): corrupted top size
• double free or corruption
• sqlite3Select
• sqlite3ExprAnalyzeAggregates
• sqlite3VdbeExec
• sqlite3_prepare_v2
• sqlite3_prepare_v3

What your security team should do

• Treat this as a priority patching item because public exploit code is available and EPSS is high, even though it is not currently listed in CISA KEV.
• Inventory all SQLite usage, including vendored, statically linked, containerized, mobile, desktop, appliance, and third-party application copies.
• Upgrade or rebuild affected software to SQLite 3.50.2 or later, or to a source revision containing commit 9d7c5df7f0e42528bf514b5231d58273bea47e40.
• Prioritize internet-facing, multi-tenant, file-processing, plugin-capable, sync-enabled, and user-queryable applications that pass untrusted input into SQLite.
• Temporarily restrict raw SQL execution, untrusted database import, and advanced query/report-building features until affected components are upgraded.
• Enable crash monitoring and alert on repeated SQLite-related crashes or memory-safety exceptions in services that process untrusted input.
• Review vendor advisories for commercial products that embed SQLite and track fixes separately from operating system package updates.
• Run post-remediation SCA and binary scans to verify no vulnerable SQLite copies remain in deployed artifacts.