CVE-2025-7458 is a critical severity integer overflow (CWE-190, CVSS 9.1) in SQLite versions 3.39.2 through 3.41.1. The attacker must be able to run SQL statements. Move to a current SQLite release, and check the advisory for the exact fixed version.
What's affected
The record says SQLite versions 3.39.2 through 3.41.1 are affected, in the function sqlite3KeyInfoFromExprList. It describes an integer overflow that can lead to denial of service or disclosure of process memory, triggered by a crafted SELECT statement with a very large number of expressions in the ORDER BY clause.
The CVSS 3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H, a base score of 9.1. The vector marks the issue as network reachable with no privileges. The description itself, however, says the attacker needs the ability to execute arbitrary SQL statements. In practice that is a strong precondition. It matters most where an application passes untrusted SQL to SQLite, or exposes a SQL console. In an app that only runs its own fixed queries, the exposure is much narrower than the score alone implies.
The record does not give a fixed version. The two references I fetched are a SQLite forum thread from March 2023 and a SQLite check-in. The forum thread is a fuzzing report from a researcher, and the check-in, dated 16 March 2023 and applied to trunk and the 3.41 branch, describes a fix to SELECT DISTINCT with ORDER BY. Neither page uses the exact wording of the record about an integer overflow, so I cannot confirm from them which release closed this specific CVE. The SQLite 3.41.2 release notes (22 March 2023) do not name this CVE either. Check the advisory and the SQLite release history before you rely on any single version number. The safest course is to run a current release.
The record says the CVE is not on the CISA Known Exploited Vulnerabilities list, and neither page I fetched says it is exploited in the wild.
How to check if you're exposed
SQLite is usually a dependency, so check three places: the system library, language packages that bundle SQLite, and applications that statically link it.
sqlite3 --version
python3 -c "import sqlite3; print(sqlite3.sqlite_version)"
On Linux, ask the package manager which version is installed.
dpkg -l | grep -i sqlite
rpm -qa | grep -i sqlite
Bundled copies are the ones teams miss. Mobile apps, desktop apps, containers and language wheels often ship their own SQLite. Scan images and repositories for it. A free scan at gold.safeguard.sh/scan reads your dependency manifests and reports known CVEs for the SQLite versions it finds. Container images can be checked the same way.
Then ask the question that decides the real risk: can untrusted input become SQL text that reaches SQLite? If your app only uses fixed, parameterized statements, the attack in the description is hard to reach.
What to do now
- Inventory every place SQLite is present, including bundled copies in containers, mobile builds and language packages.
- Compare each version with the range 3.39.2 through 3.41.1 from the record.
- Upgrade to a current SQLite release, rebuild any application that statically links it, and rebuild container images.
- Check the SQLite advisory and release history for the exact fixed version, since the pages I fetched do not state it for this CVE.
- Find code paths where user input can become SQL text, and replace them with parameterized queries or remove them. Do not expose raw SQL consoles to untrusted users.
- Where an upgrade must wait, cap the size of queries and the number of ORDER BY terms your app accepts from outside.
- Rescan after the change and keep the dependency on a recurring check.
Why it matters
Integer overflow is a counting mistake. A number grows past what its type can hold and wraps around, and later code that trusts the number allocates or reads the wrong amount of memory. The record maps this to CWE-190. A wrong size in memory code can lead to a crash, or to reading memory that was not meant to be shown.
SQLite runs inside a huge number of programs, so the useful question is not "do we run SQLite" but "which copy, and can anyone outside reach it with SQL". That second question is what reachability analysis answers. A vulnerable library that your code never feeds untrusted SQL is a lower priority than one behind a public query endpoint.
Quick check
Does every app using SQLite 3.39.2 to 3.41.1 face critical risk?
No. The description says the attacker must be able to execute arbitrary SQL statements. Apps that run only their own fixed queries have a much smaller exposure than the score of 9.1 suggests, but upgrading is still the right fix.
Which SQLite release fixes this?
The record does not state one, and the pages I fetched do not name one for this CVE. Check the SQLite advisory and release history, and run a current release.
Sources
- NVD record for CVE-2025-7458
- Gold vulnerability page
- SQLite forum thread referenced by the record
- SQLite check-in referenced by the record
- SQLite 3.41.2 release notes
This post gives no attack steps.
Last reviewed: 18 October 2026.
