All known security issues are fixed in SQLite 3.31.1. We do not track CVEs. The information content of CVEs is very low, to the point of being non-useful. CVEs were originally a great idea. But they have evolved into a kind of badge-of-honor for armies of gray-hat hackers. The companies that employ these hackers evaluate employee performance in part on the number of CVEs they have generated. When people's performance evaluation depends on how many CVEs they write, you can probably guess what happens to the quantity and quality of the resulting CVEs. Pretty much every CVE that has ever been written against SQLite assumes that the attacker has the ability to inject arbitrary SQL into SQLite. In other words, there has to be an SQL-injection bug in the application in order for any of these CVEs to come into play. There are some applications that do legitimately allow untrusted remote agents to inject arbitrary SQL, and SQLite should be (and is - with the latest patches) proof against exploits from arbitrary SQL injection. (See the "[Defense Against Dark Arts][dada]" page for further information.) The vast majority of applications, however, do not allow a remote attacker to inject arbitrary SQL, and so even in older unpatched versions of SQLite, the vast majority of applications are not vulnerable. [CVS-2019-19317][cve19317] is an excellent example of a bogus CVE. This CVE describes a bug in an unreleased development version of SQLite. We were working on the new generated columns feature of SQLite, and a third-party hacker found an error in the code under active development, and then wrote a CVE against it. The error was fixed before the problem was ever released, and yet still there is this CVE sitting out there, unresolved, and as far as I can tell unresolveable. [dada]: https://www.sqlite.org/security.html [cve19317]: https://nvd.nist.gov/vuln/detail/CVE-2019-19317