Small. Fast. Reliable.
Choose any three.
Vulnerabilities

1. Executive Summary

2. About CVEs

CVEs ("Common Vulnerabilities and Exposures") are reports of software bugs that might allow a system to be hacked. The idea behind CVEs is sound. They provide a common naming scheme whereby software bugs that might compromise information security can be easily tracked.

While the original idea being CVEs is sound, the current processes for creating and managing CVEs are inadequate. There are countless grey-hat hackers running fuzzers against a wide-variety of open-source software products (SQLite as well as many others) and writing up CVEs against any problems they find. The grey-hats are rewarded, sometimes with prestige and sometimes financially, by the number and severity of the CVEs they write. This incentive results in a proliferation of CVEs which are often not well-vetted and which can have exaggerated impact claims. The quality-control procedures for CVEs are unable to cope with this flood of inputs, making it difficult to correct exaggerated, misleading, omitted, or inaccurate claims.

This is not to say that CVEs are useless. CVEs do still (mostly) report actual bugs. But in most cases the bugs are not true vulnerabilities, in the sense that they do not contribute to data loss or compromise in and of themselves. It is good that bugs are reported and fixed. But not every bug is accessible from every application. In the case of SQLite, most of the bugs reported by CVEs are inaccessible in most applications. Upgrading to the latest version of SQLite is always a good plan, but it need not be an emergency just because an anonymous grey-hat on the internet wrote up a CVE.

2.1. A separate SQL injection vulnerability is usually required

Other C-libraries that process complex structured inputs will routinely be asked to deal with unvetted inputs from untrusted sources. Libraries like libjpeg, or libzip, or OpenSSL are handed input streams that come directly from potentially hostile agents.

But database engines like SQLite are usually not this way. The SQL scripts that are passed into SQLite come from the (trusted) application itself, not from an attacker. Sometimes applications contain bugs by which an external attacker can trick the application into sending SQL of the attackers design into the database engine. This is a separate bug in the application called an SQL Injection vulnerability. Since SQL text is executable code, an SQL Injection vulnerability is actually a special case of a Remote Code Execution (RCE) vulnerability. An SQL Injection is perhaps not quite as bad as other kinds of RCEs because, while SQL is a powerful language, it is not as convenient for crafting an exploit as Python or shell script or raw machine code. Nevertheless, an SQL Injection is a serious problem.

Most CVEs written about SQLite assume that the attacker is able to run arbitrary SQL scripts in SQLite. In most applications, this means that there must first be an SQL Injection vulnerability that allows the attacker to inject the malicious SQL.

A few applications do allow untrusted SQL scripts received from potentially hostile agents to be run direct in SQLite. The main example of this is the Chrome and Safari web browsers, which allow an anonymous web page to run SQL using the WebSQL feature of Javascript. This is done inside a sandbox with tightly controlled constraints on resources, lest the SQL script try to soak up all available memory or CPU cycles in a denial-of-service attack. Chrome and Safari have the infrastructure in place to allow a hostile agent to run code which does not harm or compromise the rest of the machine. They have to, as they also run Javascript which could, if not tightly controlled, do even more damage than unrestrained SQL. Apart from Chrome and Safari, no applications known to the SQLite developers deliberately allows an anonymous remote agent to run arbitrary SQL text.

However, most CVEs written against SQLite flippantly assume that an attacker is free to run any arbitrary SQL in the database engine. So to a good approximation, this means most CVEs written against SQLite really only apply to SQLite as it is used in Chrome and Safari. Or, in other words, most CVEs for SQLite do not apply to you unless you are one of the developers of Chrome or Safari.

2.2. Defense Against Dark Arts

Most applications can use SQLite without having to worry about bugs in obscure SQL inputs. If the application controls the SQL, and the application is not deliberately trying to break SQLite, then everything should just work. It is not necessary to have the latest patched version of SQLite. Any older version should work just fine.

However, there are some occasions where an application does need to be able to safely run untrusted SQL. The SQLite developers work hard to make SQLite safe for this purpose, though there are occasional slip-ups. It is good to keep up-to-date with the latest patches in this case. The separate defense against dark arts document contains additional suggestions that can help prevent zero-day attacks in cases where SQLite is given inputs that come directly from untrusted sources.

2.3. The SQLite Developer Policy Toward CVEs

SQLite developers fix all bugs in SQLite as soon as they are reported, usually within a few hours. The fixes are immediately available on the public SQLite source tree. If a bug seems like it might cause problems for existing applications, a new patch release for SQLite will be issued.

However, the SQLite developers do not track CVEs. There are various reasons for this:

  1. The developers often do not find out about CVEs until long after the bug is fixed. You can see this by the fact that many CVEs reference the bug fix in their initial report.

  2. CVEs are a low-quality source of information about bugs in SQLite that are likely to affect most applications.

  3. Almost all bugs reported by CVEs are just bugs and not true vulnerabilities. Claiming that they are vulnerabilities is stretching the meaning of the word "vulnerability" and the SQLite developers do not wish to participate in that deception.

  4. The developers have no editorial influence on the content of CVEs, and they do not like to be controlled by groups in which they have no voice.

3. Status Of Recent SQLite CVEs

Though the SQLite developers do not consider CVEs to be a reliable source of information about bugs in SQLite, they recognize that many groups, and especially small teams working at the bottom of tall bureaucracies, sometimes need to track CVEs, whether they are useful or not. To aid in this chore, the following table of recent CVEs affecting SQLite is provided.

If you notice new CVEs associated with SQLite that are not in the table below, please bring them to the attention of the developers on the SQLite Forum so they can be added.

CVE Number Fix Comments
CVE-2021-36690 Bug not in the SQLite library This bug is not in the SQLite core library, but rather in an experimental extension that is used to implement the .expert command in the CLI. The code that contains the bug does not appear in standard SQLite builds, though it is included in the sqlite3.exe command-line tool. Applications must link against the extra source code files that implement the extension and take other deliberate actions to activate the extension before the troublesome code can be run. For the rare application that uses the troublesome extension, the consequence of this bug is that malicious SQL can cause a NULL pointer deference and denial of service. (details)
CVE-2021-28305 Not a bug This is not a bug in SQLite. The bug is in a third-party application that uses SQLite. SQLite is mentioned by name in the CVE description, however, so we have included the CVE in the list.
CVE-2021-23404 Not a bug This is not a bug in SQLite. The bug is in a third-party application that uses SQLite and includes "sqlite" in its name. This CVE is included on the list because it mentions SQLite even though the bug has nothing to do with SQLite.
CVE-2021-20227 3.34.1
(2021-01-20)
Malicious SQL statement causes read-after-free. No harm can come of this particular read-after-free instance, as far as anyone knows. The bug is undetectable without a memory sanitizer. The CVE claims that this bug is an RCE - a Remote Code Execution vulnerability, but that claim is incorrect. The RCE claim is misinformation. (details)
CVE-2020-15358 3.32.3
(2020-06-18)
Malicious SQL statement causes an read past the end of a heap buffer. (details)
CVE-2020-13871 3.32.3
(2020-06-18)
Malicious SQL statement causes a read-only use-after-free memory error. (details)
CVE-2020-13632 3.32.0
(2020-05-22)
Malicious SQL statement causes a read of a NULL pointer in the matchinfo() SQL function of the FTS3 extension, resulting in denial of service. (details)
CVE-2020-13631 3.32.0
(2020-05-22)
Malicious SQL statement (an ALTER TABLE that tries to rename a virtual table into one of its own shadow tables) causes an infinite loop and denial of service. (details)
CVE-2020-13630 3.32.0
(2020-05-22)
Malicious SQL statement causes a read-only use-after-free, possibly resulting in a incorrect output from the snippet() SQL function of the FTS3 extension. There is no known way to exfiltrate data or crash the application using this bug. (details)
CVE-2020-13435 3.32.1
(2020-05-25)
Malicious SQL statement causes a read access to a NULL pointer and denial of service. (details)
CVE-2020-13434 3.32.1
(2020-05-25)
Malicious SQL statement involving the printf() SQL function results in an integer overflow which can overwrite the stack with over 2 billion bytes of 0x30 or 0x20 (ASCII '0' or ' '). Even though this is a stack overwrite, there is no known way to redirect control or otherwise escalate the level of harm. This is a denial-of-service attack only. (details)
CVE-2020-11656 3.32.0
(2020-05-22)
Malicious SQL statement causes read-only use-after-free of memory allocation if SQLite is compile with -DSQLITE_DEBUG. Does not affect release builds. (details)
CVE-2020-11655 3.32.0
(2020-05-22)
Malicious SQL statement causes a read using an uninitialized pointer and denial-of-service. (details)
CVE-2020-9327 3.32.0
(2020-05-22)
Malicious SQL statement causes a read using an uninitialized pointer and denial-of-service (details)
CVE-2020-6405 3.31.0
(2020-01-22)
Malicious SQL statement causes a NULL pointer dereference and denial-of-service (details)
CVE-2019-20218 3.31.0
(2020-01-22)
Malicious SQL statement causes an uninitialized pointer read and denial-of-service. (details)
CVE-2019-19959 3.31.0
(2020-01-22)
Malicious SQL statement causes a NULL pointer dereference in the Zipfile virtual table extension and denial-of-service. This is only possible when the optional Zipfile virtual table extension is deployed, which is not the case in default builds. (details)
CVE-2019-19926 3.31.0
(2020-01-22)
Malicious SQL statement causes an uninitialized pointer read and denial-of-service. (details)
CVE-2019-19925 3.31.0
(2020-01-22)
Malicious SQL statement causes a NULL pointer dereference and in the Zipfile virtual table extension and denial-of-service. This is only possible when the optional Zipfile virtual table extension is deployed, which is not the case in default builds. (details)
CVE-2019-19924 3.31.0
(2020-01-22)
Malicious SQL statement causes a uninitialized pointer reference and denial-of-service. (details)
CVE-2019-19923 3.31.0
(2020-01-22)
Malicious SQL statement causes a NULL pointer dereference and denial-of-service. (details)
CVE-2019-19317 3.31.0
(2020-01-22)
This CVE identifies a bug in a development check-in of SQLite. The bug never appeared in any official SQLite release. (details)