小巧。快速。可靠。
三选二。
三选二。
关于 SQLite 的 CVE 可能不适用于您使用 SQLite 的方式。
所有针对 SQLite 报告的历史漏洞都需要至少一个以下先决条件
攻击者可以提交并运行任意 SQL 语句。
攻击者可以向应用程序提交恶意制作的数据库文件，该应用程序将打开并查询该文件。
很少有实际应用程序满足这两个先决条件中的任何一个，因此很少有实际应用程序存在漏洞，即使它们使用的是旧版和未修补的 SQLite 版本。
SQLite 开发团队会及时修复错误，通常在发现后数小时内修复。如果错误似乎有可能影响实际应用程序，则会发布新的 SQLite 版本。
灰帽黑客根据他们编写的 CVE 的数量和严重程度获得奖励。这导致了大量 CVE 的出现，这些 CVE 的影响很小，或者根本没有影响，但却夸大了影响的声明。
关于 SQLite 编写的 CVE 很少是真正的漏洞，因为它们不会为攻击者提供任何新功能。考虑
几乎所有针对 SQLite 编写的 CVE 都需要能够注入和运行任意 SQL。
大多数 CVE 的宣传结果是“拒绝服务”，通常是通过导致崩溃（通过空指针解引用或零除或类似操作）来实现。
但是，如果攻击者已经可以运行任意 SQL，那么他们就不需要漏洞来造成拒绝服务。有很多完全合法有效的 SQL 语句会消耗无限的 CPU、内存和磁盘 I/O 来创建拒绝服务，而无需漏洞的帮助。
因此，攻击者能够注入和运行任意 SQL 本身就是一个拒绝服务攻击。任意 SQL 也可能触及 SQLite 中的漏洞并导致崩溃，这不是一个新的漏洞。
SQLite 开发人员不编写 CVE。您在 SQLite 上找到的任何 CVE 都是由第三方生成的，通常没有核心开发人员的任何输入。一个常见的情况是，有人会报告 SQLite 中的错误，然后会立即修复该错误，然后几周后，就会出现该错误的 CVE，而开发人员对此一无所知。
您不应该假设关于 SQLite 的 CVE 包含权威信息。CVE 通常包含不准确的信息。SQLite 开发人员已尝试为关于 SQLite 的 CVE 添加说明和更正。
CVE（“常见漏洞和披露”）是关于可能允许系统被黑客攻击的软件错误的报告。CVE 背后的想法是合理的。它们提供了一个通用命名方案，通过该方案可以轻松跟踪可能损害信息安全的软件错误。
虽然 CVE 背后的最初想法是合理的，但目前创建和管理 CVE 的流程还不够完善。无数灰帽黑客正在对各种开源软件产品（包括 SQLite 和许多其他产品）运行模糊测试器，并针对他们发现的任何问题编写 CVE。灰帽黑客会根据他们编写的 CVE 的数量和严重程度获得奖励，有时是声望，有时是经济利益。这种激励机制导致了大量 CVE 的出现，这些 CVE 通常没有经过严格审查，并且可能会夸大影响的声明。CVE 的质量控制程序无法应对大量输入，因此难以纠正夸大、误导、遗漏或不准确的声明。
这并不是说 CVE 毫无用处。CVE 仍然（大多）报告实际存在的错误。但在大多数情况下，这些错误不是真正的漏洞，因为它们本身不会导致数据丢失或损害。报告和修复错误是件好事。但并非每个错误都可以在每个应用程序中访问。在 SQLite 的情况下，大多数由 CVE 报告的错误在大多数应用程序中是无法访问的。升级到最新版本的 SQLite 始终是一个好主意，但如果只是因为互联网上一个匿名灰帽黑客编写了 CVE，就不需要紧急升级。
其他处理复杂结构化输入的 C 库通常会被要求处理来自不受信任来源的未经验证的输入。像 libjpeg、libzip 或 OpenSSL 这样的库会处理来自潜在敌对代理的输入流。
但像 SQLite 这样的数据库引擎通常不是这样的。传递到 SQLite 的 SQL 脚本来自（受信任的）应用程序本身，而不是来自攻击者。有时应用程序包含错误，攻击者可以通过这些错误欺骗应用程序将攻击者设计的 SQL 发送到数据库引擎。这是应用程序中一个单独的错误，称为SQL 注入漏洞。由于 SQL 文本是可执行代码，因此 SQL 注入漏洞实际上是远程代码执行 (RCE) 漏洞 的特例。SQL 注入可能不像其他类型的 RCE 那样糟糕，因为虽然 SQL 是一种强大的语言，但它在制作利用程序方面不如 Python、shell 脚本或原始机器代码方便。然而，SQL 注入是一个严重的问题。
关于 SQLite 编写的 CVE 大部分都假设攻击者能够在 SQLite 中运行任意 SQL 脚本。在大多数应用程序中，这意味着首先必须存在一个 SQL 注入漏洞，允许攻击者注入恶意 SQL。
一些应用程序确实允许将从潜在敌对代理接收的不可信 SQL 脚本直接运行在 SQLite 中。最主要的例子是 Chrome 和 Safari 浏览器，它们允许匿名网页使用 Javascript 的 WebSQL 功能运行 SQL。这在沙盒内完成，对资源进行严格控制，以免 SQL 脚本试图在拒绝服务攻击中吸收所有可用的内存或 CPU 周期。Chrome 和 Safari 具有允许敌对代理运行不会损害或破坏机器其他部分的代码的基础设施。它们必须这样做，因为它们还运行 Javascript，如果不受严格控制，Javascript 会比不受约束的 SQL 造成更大的破坏。除了 Chrome 和 Safari 之外，没有已知 SQLite 开发人员的应用程序故意允许匿名远程代理运行任意 SQL 文本。
然而，大多数针对 SQLite 编写的 CVE 轻率地假设攻击者可以随意在数据库引擎中运行任何任意 SQL。因此，换句话说，这意味着大多数针对 SQLite 编写的 CVE 实际上只适用于 Chrome 和 Safari 中使用的 SQLite。或者，换句话说，大多数 SQLite 的 CVE 并不适用于您，除非您是 Chrome 或 Safari 的开发人员之一。
大多数应用程序可以使用 SQLite，而无需担心晦涩的 SQL 输入中的错误。如果应用程序控制着 SQL，并且应用程序没有故意试图破坏 SQLite，那么一切应该正常工作。没有必要拥有最新修补的 SQLite 版本。任何旧版本都应该可以正常工作。
然而，在某些情况下，应用程序确实需要能够安全地运行不可信的 SQL。SQLite 开发人员努力使 SQLite 对此目的安全，尽管偶尔也会出现疏忽。在这种情况下，最好了解最新的补丁。单独的防御黑魔法 文档包含其他建议，可以帮助防止在 SQLite 被赋予直接来自不受信任来源的输入的情况下发生零日攻击。
SQLite 开发人员会在报告错误后立即修复 SQLite 中的所有错误，通常在几小时内修复。修复程序立即在公共 SQLite 源代码树 上可用。如果错误似乎可能导致现有应用程序出现问题，则会发布 SQLite 的新补丁版本。
然而，SQLite 开发人员不跟踪 CVE。原因如下
开发人员通常直到错误修复很久之后才知道 CVE。您可以在许多 CVE 的初始报告中引用错误修复的事实中看到这一点。
CVE 是关于可能影响大多数应用程序的 SQLite 错误的信息来源，其质量很低。
几乎所有由 CVE 报告的错误都只是错误，而不是真正的漏洞。声称它们是漏洞是在夸大“漏洞”一词的含义，SQLite 开发人员不希望参与这种欺骗行为。
开发人员对 CVE 内容没有编辑权，他们不喜欢被他们没有发言权的团体控制。
虽然 SQLite 开发人员认为 CVE 不是关于 SQLite 错误信息的可靠来源，但他们意识到许多群体（尤其是处于高层官僚机构底层的团队）有时需要跟踪 CVE，无论它们是否有用。为了帮助完成这项任务，下面提供了最近影响 SQLite 的 CVE 表格。
如果您注意到与 SQLite 相关的新的 CVE，而这些 CVE 不在下面的表格中，请在SQLite 论坛 上告知开发人员，以便他们可以添加。
| CVE 编号 | 修复 | 评论 |
|---|---|---|
| CVE-2024-0232 | 3.43.2 (2023-10-10) |
能够向应用程序注入任意 SQL 语句的攻击者可能会在 SQLite 的 JSON 解析器中引发使用后释放错误，这可能（理论上）会导致应用程序崩溃和拒绝服务。有关错误报告，请参见论坛线程 b25edc1d4662。 |
| CVE-2023-32697 | SQLite 中没有错误 | 这是 SQLite JDBC 库中的错误，该库是一个包装库，提供从 Java 访问 SQLite 的功能。SQLite JDBC 是独立于 SQLite 创建和维护的。尽管名称中使用了“SQLite”，但 SQLite JDBC 库与 SQLite 项目没有任何关联。此 CVE 确定的漏洞存在于单独的 SQLite JDBC 包装库中，不会影响 SQLite 本身。 |
| CVE-2023-39939 | SQLite 中没有错误 | 这不是 SQLite 中的错误。这是一个SQL 注入错误，存在于与 SQLite 链接的应用程序（LuxCal Web 日历）中。即使此 CVE 与 SQLite 无关，但“SQLite”也出现在说明中，因此我们在此列出。 |
| CVE-2023-39543 | SQLite 中没有错误 | 这不是 SQLite 中的错误。这是一个跨站点脚本 (XSS) 漏洞，存在于与 SQLite 链接的另一个应用程序（LuxCal Web 日历）中。错误存在于应用程序中，而不是在 SQLite 中。但是，说明中提到了“SQLite”，因此我们在此列出。 |
| CVE-2023-7104 | 3.43.1 (2023-09-11) |
这是 SQLite 的会话扩展 中的错误，而不是 SQLite 核心中的错误。此错误只能通过使用-DSQLITE_ENABLE_SESSION 编译时选项重新编译 SQLite，然后使用 Session C 语言 API 处理变更集 的应用程序访问，该变更集已被对手微妙地破坏。因此，此错误可能不适用于您。有关更多信息，请参见论坛帖子 f935c4708dd528d9。 |
| CVE-2022-46908 | 核心 SQLite 库中没有错误 | 这是 命令行 shell 程序中 --safe 命令行选项的一个 bug，该程序可用于访问 SQLite 数据库文件。该 bug 不存在于 SQLite 库中。只要用户不依赖 --safe 选项，它对 CLI 也不构成问题。它并不严重。是否将其视为安全问题尚存争议。 |
| CVE-2022-38627 | SQLite 中没有错误 | 这不是 SQLite 的 bug。这是一个 SQL 注入漏洞，存在于特定 PHP 应用程序中。换句话说，该漏洞存在于 PHP 应用程序代码中，而不是 SQLite 中。即使此 CVE 与 SQLite 无关，"SQLite" 在有关该漏洞的宣传中也有提及，因此我们将其列在这里。 |
| CVE-2022-35737 | 3.39.2 (2022-07-21) |
此 bug 是一个数组越界错误。该 bug 仅在使用 SQLite 提供的一些 C 语言 API 时才可访问。该 bug 无法通过 SQL 访问，也无法通过向 SQLite 提供损坏的数据库文件访问。该 bug 仅在将非常长的字符串输入（长度超过 20 亿字节）作为参数提供给一些特定的 C 语言接口时才会出现，即使这样也只有在特殊情况下才会出现。 |
| CVE-2022-24854 | SQLite 中没有错误 | 此 CVE 描述的是使用 SQLite 的应用程序中的一个漏洞，而不是 SQLite 本身。SQLite 的行为完全正确。该应用程序允许用户使用 SQLite 运行 SQL 语句，这些语句可以泄露或更改用户通常无法访问的信息。这纯粹是一个应用程序漏洞。它不描述 SQLite 的故障或漏洞。 |
| CVE-2022-21227 | SQLite 中没有错误 | 此 CVE 描述的是第三方软件包中的一个漏洞，该软件包为 Node.js 提供了 SQLite 的绑定。所报告的漏洞存在于第三方 Node.js 绑定中，而不是 SQLite 本身。不要被 CVE 描述中含糊其辞的 "SQLite" 一词所迷惑。 |
| CVE-2021-45346 | SQLite 中没有错误 | 此 CVE 是错误信息。请参阅围绕 SQLite 论坛帖子 53de8864ba114bf 的讨论。 |
| CVE-2021-42169 | SQLite 中没有错误 | 此 CVE 与 SQLite 无关。它是一个应用程序中的一个漏洞，碰巧使用了 SQLite。由于 SQLite 在 CVE 描述中有所提及，因此我们将其列在这里，以强调这不是 SQLite 的漏洞。 |
| CVE-2021-36690 | 核心 SQLite 库中没有错误 | 此漏洞不在 SQLite 核心库中，而是在 实验性扩展 中，该扩展用于在 CLI 中实现 .expert 命令。包含此漏洞的代码不会出现在 标准 SQLite 版本 中，但它包含在 sqlite3.exe 命令行工具 中。应用程序必须链接到实现该扩展的额外源代码文件，并采取其他有意行动来激活该扩展，才能运行有问题的代码。对于使用有问题的扩展的罕见应用程序，此漏洞的后果是恶意 SQL 可能导致空指针解引用和拒绝服务。 (详细信息) |
| CVE-2021-28305 | SQLite 中没有错误 | 这不是 SQLite 的漏洞。该漏洞存在于使用 SQLite 的第三方应用程序中。虽然 SQLite 在 CVE 描述中被明确提及，但我们还是将其列入了列表。 |
| CVE-2021-23404 | SQLite 中没有错误 | 这不是 SQLite 的漏洞。该漏洞存在于使用 SQLite 并包含 "sqlite" 的第三方应用程序中。此 CVE 被列入列表，因为它提到了 SQLite，即使该漏洞与 SQLite 无关。 |
| CVE-2021-20227 | 3.34.1 (2021-01-20) |
恶意 SQL 语句导致释放后使用。据我们所知，此特定释放后使用实例不会造成任何危害。在没有内存消毒器的情况下，该漏洞是无法检测到的。CVE 声称此漏洞是 RCE（远程代码执行漏洞），但该说法不正确。RCE 说法是错误信息。 (详细信息) |
| CVE-2021-20223 | 3.34.0 (2020-12-01) |
此 CVE 所识别的问题不是漏洞。它是一个故障。编码错误导致 FTS5 在某些情况下有时会返回不一致和不正确的结果，但不会出现内存错误。 (详细信息) |
| CVE-2020-15358 | 3.32.3 (2020-06-18) |
恶意 SQL 语句会导致超出堆缓冲区末尾的读取。 (详细信息) |
| CVE-2020-13871 | 3.32.3 (2020-06-18) |
恶意 SQL 语句会导致只读释放后使用内存错误。 (详细信息) |
| CVE-2020-13632 | 3.32.0 (2020-05-22) |
恶意 SQL 语句会导致在 FTS3 扩展的 matchinfo() SQL 函数中读取空指针，从而导致拒绝服务。 (详细信息) |
| CVE-2020-13631 | 3.32.0 (2020-05-22) |
恶意 SQL 语句（试图将 虚拟表 重命名为其自己的 影子表 之一的 ALTER TABLE）会导致无限循环和拒绝服务。 (详细信息) |
| CVE-2020-13630 | 3.32.0 (2020-05-22) |
恶意 SQL 语句会导致只读释放后使用，可能导致 FTS3 扩展的 snippet() SQL 函数输出不正确。目前还没有已知的方法可以使用此漏洞来泄露数据或使应用程序崩溃。 (详细信息) |
| CVE-2020-13435 | 3.32.1 (2020-05-25) |
恶意 SQL 语句会导致对空指针的读取访问并导致拒绝服务。 (详细信息) |
| CVE-2020-13434 | 3.32.1 (2020-05-25) |
涉及 printf() SQL 函数的恶意 SQL 语句会导致整数溢出，从而可以将堆栈覆盖 20 亿字节以上的 0x30 或 0x20（ASCII '0' 或 ' '）。即使这是一个堆栈覆盖，但目前还没有已知的方法来重定向控制或进一步升级危害程度。这仅仅是一个拒绝服务攻击。 (详细信息) |
| CVE-2020-11656 | 3.32.0 (2020-05-22) |
如果 SQLite 使用 -DSQLITE_DEBUG 编译，恶意 SQL 语句会导致对内存分配的只读释放后使用。不会影响发行版本。 (详细信息) |
| CVE-2020-11655 | 3.32.0 (2020-05-22) |
恶意 SQL 语句会导致使用未初始化的指针进行读取并导致拒绝服务。 (详细信息) |
| CVE-2020-9327 | 3.32.0 (2020-05-22) |
恶意 SQL 语句会导致使用未初始化的指针进行读取并导致拒绝服务 (详细信息) |
| CVE-2020-6405 | 3.31.0 (2020-01-22) |
恶意 SQL 语句会导致空指针解引用并导致拒绝服务 (详细信息) |
| CVE-2019-20218 | 3.31.0 (2020-01-22) |
恶意 SQL 语句会导致未初始化的指针读取并导致拒绝服务。 (详细信息) |
| CVE-2019-19959 | 3.31.0 (2020-01-22) |
恶意 SQL 语句会导致 Zipfile 虚拟表 扩展中的空指针解引用和拒绝服务。这只有在可选的 Zipfile 虚拟表 扩展部署时才有可能，这在默认版本中并非如此。 (详细信息) |
| CVE-2019-19926 | 3.31.0 (2020-01-22) |
恶意 SQL 语句会导致未初始化的指针读取并导致拒绝服务。 (详细信息) |
| CVE-2019-19925 | 3.31.0 (2020-01-22) |
恶意 SQL 语句会导致 Zipfile 虚拟表 扩展中的空指针解引用和拒绝服务。这只有在可选的 Zipfile 虚拟表 扩展部署时才有可能，这在默认版本中并非如此。 (详细信息) |
| CVE-2019-19924 | 3.31.0 (2020-01-22) |
恶意 SQL 语句会导致未初始化的指针引用并导致拒绝服务。 (详细信息) |
| CVE-2019-19923 | 3.31.0 (2020-01-22) |
恶意 SQL 语句会导致空指针解引用并导致拒绝服务。 (详细信息) |
| CVE-2019-19646 | 3.31.0 (2020-01-22) |
PRAGMA integrity_check 命令可能会导致已准备语句的字节码无限循环。这可能会导致拒绝服务，如果应用程序没有采取适当的谨慎措施来限制 SQL 语句的运行时间。这不是漏洞，因为有无数完全有效的 SQL 查询，尤其是涉及 递归公用表表达式 的查询，也会基本无限运行。 (详细信息) |
| CVE-2019-19317 | 3.31.0 (2020-01-22) |
此 CVE 识别了 SQLite 开发签入中的一个漏洞。该漏洞从未出现在任何官方 SQLite 版本中。 (详细信息) |