# Will sqlite3 be updated in the standard library to address fixed CVSS vulnerabilities?

**URL:** <https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629>\
**Category:** Core Development\
**Tags:** stdlib\
**Created:** [March 15, 2024, 5:46pm UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629 "2024-03-15T17:46:23Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![merler1](https://avatars.discourse-cdn.com/v4/letter/m/ac91a4/32.png) [@merler1](https://discuss.python.org/u/merler1)\
**Post date:** [March 15, 2024, 5:46pm UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629/1 "2024-03-15T17:46:23Z")

</div>

Python 3.12.2 has SQLite version 3.40.1 in the standard library. sqlite3 3.43.2 fixes CVE-2023-7104 (high) and CVE-2024-0232 (medium). Is there any chance that SQLite version 3.43.2 will be updated in the standard library and made part of an upcoming Python version?

---

<div class="post-metadata">

**Author:** ![zware](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/zware/32/58_2.png) [@zware](https://discuss.python.org/u/zware)\
**Post date:** [March 15, 2024, 6:24pm UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629/2 "2024-03-15T18:24:07Z")

</div>

Python 3.12.2 used sqlite 3.43.1 [on Windows](https://github.com/python/cpython/blob/v3.12.2/PCbuild/get_externals.bat#L57) and 3.45.1 [on macOS](https://github.com/python/cpython/blob/v3.12.2/Mac/BuildScript/build-installer.py#L362-L363). If you’re on any other platform, sqlite will be provided by your system, not by Python.

Python 3.12.3 will (as of right now) use sqlite 3.45.1 on both Windows and macOS, currently planned for [April 9th](https://peps.python.org/pep-0693/#bugfix-releases).

---

<div class="post-metadata">

**Author:** ![nad](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nad/32/51_2.png) [@nad](https://discuss.python.org/u/nad)\
**Post date:** [March 15, 2024, 8:06pm UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629/3 "2024-03-15T20:06:12Z")

</div>

Note that, for macOS, the link above only applies to Python 3.12’s installed from [python.org macOS installers](https://www.python.org/downloads/macos/). Other distributors of Python for macOS (like **Homebrew** , **MacPorts** , **Conda** , etc) either supply their own version of **SQLite** or default to using the Apple-supplied version in macOS.

You can check what version is in use with your Python (on any platform) with something like:

`python3 -c 'import sqlite3;print(sqlite3.sqlite_version)'`

or, more easily, starting with Python 3.12:

`python3.12 -m sqlite3 -v`

---

<div class="post-metadata">

**Author:** ![merler1](https://avatars.discourse-cdn.com/v4/letter/m/ac91a4/32.png) [@merler1](https://discuss.python.org/u/merler1)\
**Post date:** [March 21, 2024, 3:00pm UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629/4 "2024-03-21T15:00:32Z")

</div>

Additional context for my original question is that Python 3.12.2 is running in a Docker container with python:3.12.2-slim-bookworm (Debian) as the base image. Sqlite3 is, apparently, not installed in slim but the command **python3.12 -m sqlite3 -v** returns ‘SQLite version 3.40.1’. Should I expect sqlite 3.45.1 to be available in python:3.12.3-slim-bookworm when it’s eventually available?

---

<div class="post-metadata">

**Author:** ![notatallshaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/notatallshaw/32/10861_2.png) [@notatallshaw](https://discuss.python.org/u/notatallshaw)\
**Post date:** [March 21, 2024, 3:13pm UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629/5 "2024-03-21T15:13:31Z")

</div>

That’s a community maintained docker image: [Docker](https://hub.docker.com/_/python)

I don’t think there’s much expertise on this forum about that distribution, you should reach out through their discussion channels.

---

<div class="post-metadata">

**Author:** ![Stefan2](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stefan2/32/18492_2.png) [@Stefan2](https://discuss.python.org/u/Stefan2)\
**Post date:** [March 21, 2024, 8:41pm UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629/6 "2024-03-21T20:41:34Z")

</div>

> [@merler1](#):
>
> sqlite3 3.43.2 fixes CVE-2023-7104

[This](https://www.sqlite.org/cves.html#status_of_recent_sqlite_cves) says 3.43.1 did.

---

<div class="post-metadata">

**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\
**Post date:** [March 21, 2024, 10:40pm UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629/7 "2024-03-21T22:40:01Z")

</div>

The sqlite built and shipped with python (on platforms where it is built and bundled) is unaffected by CVE-2023-7104, as it isn’t even built with the affected extension

a way of encountering CVE-2024-0232 exists in theory but requires allowing untrusted user input to be used to craft a query (which is itself problematic without that CVE) or developers having pathological uses of the json extension.

It’s great that both will be fixed, but I wouldn’t worry about using sqlite through python as a result of these.

---

<div class="post-metadata">

**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\
**Post date:** [March 21, 2024, 11:06pm UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629/8 "2024-03-21T23:06:11Z")

</div>

Try explaining that to a security team that’s trying to keep a large collection of deployments of thousands of software products to millions of machines safe. Their attitude is “If the app depends on X and X depends on Y and Y has a CVE against it, delete the app until X and Y have been upgraded to a version of Y that fixes the CVE.”

---

<div class="post-metadata">

**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\
**Post date:** [March 22, 2024, 12:30am UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629/9 "2024-03-22T00:30:26Z")

</div>

I guess I can count myself lucky since I was able to do just that with both of these vulnerabilities. One thing that can probably done going forward to make it easier for those with security teams without plans in place for that, now that python intends to have a SBOM is to use [VEX](https://spdx.dev/deciphering-vex-and-spdx-a-deep-dive-into-software-vulnerability-analysis-and-reporting/) to label that python is unaffected by a CVE from a dependency with justification. (VEX are intended to be issuable without new releases, and considered to attach to a SBOM), but that probably needs to go into another thread.

---

<div class="post-metadata">

**Author:** ![kenny.knecht](https://avatars.discourse-cdn.com/v4/letter/k/90db22/32.png) [@kenny.knecht](https://discuss.python.org/u/kenny.knecht)\
**Post date:** [November 13, 2024, 1:39pm UTC](https://discuss.python.org/t/will-sqlite3-be-updated-in-the-standard-library-to-address-fixed-cvss-vulnerabilities/48629/10 "2024-11-13T13:39:54Z")

</div>

For future reference: this is fixed in the docker image for 3.12.7
