CVE-2026-11824,CVE-2026-11822 - Azure CLI bundles sqlite3.dll 3.50.4.0, below upstream security fix 3.53.2

Describe the bug

Our vulnerability scanner detected an outdated SQLite library installed with
Azure CLI for Windows:

Path:
C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll

Installed file version:
3.50.4.0

Scanner remediation threshold:
3.53.2

The finding appears to correspond to SQLite vulnerabilities fixed upstream in
SQLite 3.53.2, including CVE-2026-11822 and CVE-2026-11824, which affect the
FTS5 extension in builds compiled with SQLITE_ENABLE_FTS5.

Could the Azure CLI team please confirm if whether this is assessed as exploitable in Azure CLI and the planned Azure CLI version/ETA containing SQLite 3.53.2 or later. Thank you.

For info:

Scanner used: Nessus

PS C:\Users\> $cliDll = 'C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll'
PS C:\Users\> Write-Output '=== Azure CLI SQLite DLL ==='
=== Azure CLI SQLite DLL ===
PS C:\Users\> Get-Item $cliDll | Select-Object `
>>     FullName,
>>     Length,
>>     LastWriteTime,
>>     @{Name='FileVersion'; Expression = { $_.VersionInfo.FileVersion }},
>>     @{Name='ProductVersion'; Expression = { $_.VersionInfo.ProductVersion }}

FullName       : C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll
Length         : 1584864
LastWriteTime  : 6/10/2026 11:30:36 AM
FileVersion    : 3.50.4.0
ProductVersion : 3.50.4.0

PS C:\Users\>
PS C:\Users\> Write-Output "`n=== SQLite DLL SHA-256 ==="

=== SQLite DLL SHA-256 ===
PS C:\Users\> Get-FileHash $cliDll -Algorithm SHA256

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA256          2940BEE51C4A00C7E8F2A8A1BE857D4C4AD23B2657FBF7FDF18E3A3FD20066C6       C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll

PS C:\Users\>
PS C:\Users\> Write-Output "`n=== Azure CLI Version ==="

=== Azure CLI Version ===
PS C:\Users\> az version
{
  "azure-cli": "2.90.0",
  "azure-cli-core": "2.90.0",
  "azure-cli-telemetry": "1.1.0",
  "extensions": {
    "log-analytics": "1.0.0b1"
  }
}
PS C:\Users\> Write-Output "`n=== Windows OS ==="

=== Windows OS ===
PS C:\Users\> Get-CimInstance -ClassName Win32_OperatingSystem |
>>     Select-Object `
>>         Caption,
>>         Version,
>>         BuildNumber,
>>         OSArchitecture,
>>         LastBootUpTime

Caption        : Microsoft Windows Server 2022 Datacenter
Version        : 10.0.20348
BuildNumber    : 20348
OSArchitecture : 64-bit
LastBootUpTime : 8/13/2026 5:30:06 AM

PS C:\Users\> Write-Output "`n=== Windows Release Details ==="

=== Windows Release Details ===
PS C:\Users\> Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
>>     Select-Object `
>>         ProductName,
>>         DisplayVersion,
>>         CurrentBuildNumber,
>>         UBR,
>>         EditionID,
>>         InstallationType

ProductName        : Windows Server 2022 Datacenter
DisplayVersion     : 21H2
CurrentBuildNumber : 20348
UBR                : 5499
EditionID          : ServerDatacenter
InstallationType   : Server

Related command

No commands related to this

Errors

No errors on the commands as this is flagged on a security scanner

Issue script & Debug output

N/A

Expected behavior

Vulnerability should be addressed.

Environment Summary

azure-cli 2.90.0

core 2.90.0
telemetry 1.1.0

Extensions:
log-analytics 1.0.0b1

Dependencies:
msal 1.36.0
azure-mgmt-resource 24.0.0

Python location 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe'
Config directory 'C:\Users\.azure'
Extensions directory 'C:\Users\.azure\cliextensions'

Python (Windows) 3.14.6 (tags/v3.14.6:c63aec6, Jun 10 2026, 10:26:10) [MSC v.1944 64 bit (AMD64)]

Legal docs and information: aka.ms/AzureCliLegal

Your CLI is up-to-date.

Additional context

No response

Thank you for opening this issue, we will look into it.

Yong Zhang (@yonzhan)

Hi Yong Zhang (@yonzhan), thanks for the report. This looks like a packaging/dependency issue (the bundled sqlite3.dll shipped with the Windows MSI installer) rather than a specific az command bug, so before we can route it to the right owning component, could you help confirm:

Which Azure CLI installer/build pipeline produced this MSI (e.g. the version/architecture of the installer download), so we can identify the packaging component that vendors sqlite3.dll
Whether this same outdated sqlite3.dll version is also present in the latest Azure CLI MSI release (not just 2.90.0), so we can confirm whether it is still current
Any specific az command or code path where this is exploitable in practice (if known), versus being purely a bundled-binary version flag from a vulnerability scanner

I'll pick this up automatically once you reply.

Hi some additional context for your agent.

The affected Azure CLI installation was deployed through Chocolatey.

Chocolatey version: 2.7.4
Chocolatey package: azure-cli
Azure CLI version: 2.90.0
Registered product: Microsoft Azure CLI (64-bit)
Publisher: Microsoft Corporation
Architecture: 64-bit
Installation path: C:\Program Files\Microsoft SDKs\Azure\CLI2\

The affected bundled library is:

Path: C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll
File version: 3.50.4.0
Product version: 3.50.4.0

Azure CLI reports:

{
  "azure-cli": "2.90.0",
  "azure-cli-core": "2.90.0",
  "azure-cli-telemetry": "1.1.0",
  "extensions": {
    "log-analytics": "1.0.0b1"
  }
}

Azure CLI 2.90.0 is the current version available through the Chocolatey Community Repository package and is listed as the current Azure CLI version in Microsoft’s Windows installation documentation.

The affected installation is therefore not an older Azure CLI release. The current Chocolatey-delivered Azure CLI 2.90.0 package includes:

C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll
Version: 3.50.4.0

This is below the scanner’s stated remediation threshold of SQLite 3.53.2.

Path: C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll
Installed version: 3.50.4.0
Scanner fixed-version threshold: 3.53.2

We have not identified an az command or Azure CLI code path that accepts an attacker-controlled SQLite database, enables/uses FTS5, or processes an affected FTS5 query path.

We are therefore reporting this as a packaging/dependency assessment request, rather than claiming confirmed Azure CLI exploitability. Thank you

Bug Analysis

Observed vs. expected: A vulnerability scanner (Nessus) flagged sqlite3.dll version 3.50.4.0 bundled inside the Azure CLI 2.90.0 MSI installer (C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll) as below the remediation threshold of 3.53.2, corresponding to CVE-2026-11822 and CVE-2026-11824 in SQLite's FTS5 extension (builds compiled with SQLITE_ENABLE_FTS5). The reporter asks whether this is exploitable in Azure CLI and when a build with an updated SQLite will ship.

Affected surface/component: This is not a specific az command defect — sqlite3.dll is a transitive native dependency pulled in by the CPython interpreter that PyInstaller freezes into the Windows MSI build (Python's stdlib sqlite3 module links against a vendored SQLite). There is no single source module/extension whose code change would bump this version; it is controlled by the Python runtime version used for the release build pipeline.

Source inspected: Searched azure-cli/azure-cli-extensions source for a directly vendored sqlite3 dependency and found none — azure-cli's own use of SQLite (e.g. MSAL/local extension index caches) goes through Python's built-in sqlite3 module, not a project-owned binary. The installer's sqlite3.dll version therefore tracks the Python interpreter version pinned for the release build (packaged_releases/build pipeline configuration), which lives outside this repository's normal command-fix path and isn't resolvable by an automated code change here.

Likely cause / owning area: Build/release engineering — the fix is to bump the Python interpreter (and/or its bundled SQLite) used by the official Windows MSI build pipeline to a version that embeds SQLite >= 3.53.2, then republish the installer. This needs confirmation from the Azure CLI release/build owners on the exploitability assessment (FTS5 usage) and the targeted release version/ETA.

Suggested next action: Route to the release/build engineering owners to (1) confirm whether the CLI's SQLite usage exercises the vulnerable FTS5 code paths, and (2) schedule a Python interpreter bump for the next Windows MSI build with a regression check of az version packaging output pre/post bump. No source-level az command fix applies, so this is not eligible for the automated Copilot fix path.

Impact/workaround: No known safe workaround short of restricting network exposure of hosts running the flagged CLI build until a patched installer ships.

Reproduction quality: High — reporter supplied exact DLL path, file version, SHA-256 hash, az version output, and OS build details.

This has been triaged as a build/dependency security concern for the Azure CLI release engineering team rather than a command-level code bug.

Analysis

Classification: Dependency / packaging vulnerability report (not a command
functional bug), out of scope for a source-code fix in this repository.

Observed vs. expected: The reporter's vulnerability scanner (Nessus)
flagged sqlite3.dll bundled with the Windows Azure CLI MSI installer
(version 3.50.4.0, installed via Chocolatey/MSI at
C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll) as being below
the scanner's remediation threshold of 3.53.2, corresponding to
CVE-2026-11822 and CVE-2026-11824. Both CVEs are described as affecting
SQLite's FTS5 (full-text search) extension in builds compiled with
SQLITE_ENABLE_FTS5.

Affected surface: This sqlite3.dll is not a vendored artifact tracked in
the Azure/azure-cli source tree — a repository search for sqlite across
Python/spec/build files in this repo returns no matches. The DLL originates
from the CPython standard library's sqlite3 extension module, which is
statically/dynamically bundled into the Windows MSI installer by the
release/build pipeline that packages the Python runtime used for that
installer (a separate build system outside this repository's source).
Consequently there is no az <command> entry point or in-repo code path to
patch, and no PR against Azure/azure-cli source can change the bundled
DLL version — the fix requires bumping the Python interpreter/runtime used
by the Windows installer build pipeline (or its SQLite dependency) to a
version that ships SQLite >= 3.53.2.

Exploitability assessment: Per the reporter's own follow-up analysis
(which we concur with from a source-review perspective), the CVEs affect the
FTS5 extension specifically. We found no az command or Azure CLI code path
that opens attacker-controlled SQLite databases, enables/uses FTS5, or
executes FTS5 queries. Azure CLI's own use of sqlite3 (e.g. local
token/msal caches) does not exercise FTS5. This is therefore a
defense-in-depth / packaging hygiene item rather than a confirmed
exploitable vulnerability in Azure CLI functionality.

Recommended next action: Escalate to the team owning the Windows
MSI/installer build pipeline to bump the bundled Python runtime (or its
SQLite dependency) to pick up SQLite >= 3.53.2 in a future release, and note
the assessed non-exploitability (FTS5 unused) in the release/security
tracking notes. No source-code change or automated PR is applicable in this
repository for this report.

Verification: After a future installer build picks up an updated Python
runtime, Get-Item $cliDll | Select-Object -ExpandProperty VersionInfo (or
equivalent) on a fresh Windows install should report sqlite3.dll version

= 3.53.2.

Bug Analysis

Summary: This report flags an outdated bundled sqlite3.dll (v3.50.4.0) inside the
Azure CLI Windows MSI / Chocolatey installer package, below the security scanner's
remediation threshold of v3.53.2 (relevant to CVE-2026-11822 / CVE-2026-11824, which
affect the SQLite FTS5 extension).

Observed vs. expected: Installed sqlite3.dll version 3.50.4.0 vs. expected >= 3.53.2.
No az command failure or functional defect is reported — this is a dependency/version
finding from a vulnerability scanner (Nessus), confirmed by the reporter on the current
Chocolatey-distributed Azure CLI 2.90.0 package.

Affected surface: This is not an azure-cli source-code defect. sqlite3.dll is not
vendored or referenced anywhere in the azure-cli source tree (src/); it originates
from the Python interpreter distribution bundled by the MSI/installer build pipeline.
There is no az command or code path in this repository that opens an attacker-controlled
SQLite database or enables/queries the FTS5 extension, so no confirmed Azure CLI-level
exploit path has been identified.

Likely cause / owning area: The bundled SQLite version tracks whatever CPython build
is used by the installer/packaging pipeline (outside this repository's source tree).
Remediation requires bumping the Python interpreter (and its bundled SQLite) used to
build the Windows MSI/Chocolatey artifacts, which is a release/packaging-pipeline change,
not a src/ code fix a Copilot coding-agent PR against this repository can make.

Suggested next action: Route to the release/build-pipeline owners to upgrade the
Python distribution used for Windows packaging to one bundling SQLite >= 3.53.2, then
re-verify with Get-FileHash/FileVersion as the reporter did. No source change or
regression test is required in azure-cli itself.

Reproduction quality: Sufficient — reporter provided installed version, file hash,
Chocolatey package/version, and CLI version confirming this is the current shipping
package, not a stale/old install.

Classifying as upstream (owned by the packaging/release pipeline rather than this
repository's source code).

Bug Analysis

Observed vs expected: A vulnerability scanner (Nessus) flagged sqlite3.dll version 3.50.4.0 bundled with the Azure CLI Windows MSI/Chocolatey installer (reported on Azure CLI 2.90.0) as below the upstream SQLite security fix release 3.53.2, which addresses CVE-2026-11822 and CVE-2026-11824 (SQLite FTS5 extension, builds compiled with SQLITE_ENABLE_FTS5). The reporter confirms the same finding on the current Chocolatey-distributed azure-cli 2.90.0 package, so this is not simply an outdated local install.

Affected surface: This is not a Python command-module defect. The sqlite3.dll in C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll is part of the embedded Python runtime bundled by the Windows MSI/Chocolatey installer build pipeline, not a pip dependency declared in this repository's setup.py/src/azure-cli-core requirements. A search of this repository source finds no direct reference to sqlite3 as a project dependency — Azure CLI's own code only ever uses Python's standard-library sqlite3 module for local caches, and the vulnerable native .dll version tracks whatever CPython build was used to produce the installer.

Likely cause / owning area: The fix requires rebuilding the Windows installer against a CPython build that bundles SQLite ≥ 3.53.2 (or bumping SQLite in that packaging toolchain), which lives in the release/installer packaging pipeline rather than in any az command module in this source tree. There is no az <command> regression to reproduce and no module/extension code change that would close this — a standard azdev-style module fix and PR is not applicable here.

Suggested next action: Route to the Azure CLI release/packaging owners to confirm exploitability in the context of Azure CLI's usage of sqlite3 (local token/cache storage, not exposed to untrusted input) and to schedule a rebuild of the Windows installer/Chocolatey package against a Python runtime bundling SQLite ≥ 3.53.2. This is a supply-chain/packaging update, not a code fix suitable for automated Copilot PR generation in this repository.

Reproduction quality: High — reporter supplied file version, SHA-256 hash, az version output, OS build, and confirmed the finding persists on the current Chocolatey package.

Bug Analysis

Summary: This report flags that the sqlite3.dll bundled with the Windows
(MSI/Chocolatey) build of Azure CLI 2.90.0 is version 3.50.4.0, below the
3.53.2 threshold that resolves CVE-2026-11822 / CVE-2026-11824 in
SQLite's FTS5 extension.

Investigation:

A repository-wide search of Azure/azure-cli for sqlite3 (source, specs,
packaging scripts) returned zero matches. Azure CLI's own source does
not reference, vendor, or pin a sqlite3.dll/SQLite library.
sqlite3.dll is part of the CPython standard library and is bundled
automatically with whatever CPython interpreter is embedded by the Windows
installer/build pipeline (MSI and Chocolatey package) that produces the
CLI2 distribution. Upgrading it is a build-pipeline / interpreter
version change, not a change to any file in this repository, so there is
no source PR that a code-fix agent can open here to remediate it.
As the reporter (@rax1795) independently confirmed, no az command or
code path in Azure CLI accepts an attacker-controlled SQLite database or
enables/exercises the FTS5 extension, so there is no evidence of an
Azure-CLI-reachable exploitation path for these CVEs today.

Recommendation: This should be tracked as a build/release-engineering
action item to bump the embedded CPython (and therefore its bundled
sqlite3.dll) to a version linked against SQLite >= 3.53.2 for the next
Windows MSI/Chocolatey release, rather than as an azure-cli source-code bug.
Routing to the release engineering / packaging owners for scheduling.

Assessment: Not confirmed exploitable via any az command; recommend
tracking as a lower-priority packaging update rather than an urgent security
fix, pending release engineering scheduling.

Bug Analysis

Observed vs. expected: A vulnerability scanner (Nessus) flags the sqlite3.dll bundled with the Windows Azure CLI installer (Chocolatey/MSI, azure-cli 2.90.0) as file version 3.50.4.0, below the scanner's remediation threshold of 3.53.2. That version gap corresponds to upstream SQLite fixes tracked as CVE-2026-11822 and CVE-2026-11824 in the FTS5 extension. The reporter expects the bundled library to be brought up to a non-flagged version.

Affected surface: This is not an az command code path — it is the Windows installer/packaging artifact (C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll). A repository code search for sqlite/sqlite3.dll across Azure/azure-cli returned no matches, confirming this DLL is not vendored or pinned directly in this repository's source, setup.py, or dependency manifests. It ships as part of the embedded CPython runtime used to build the Windows MSI, so its version tracks whichever Python build/interpreter the installer pipeline packages, not an azure-cli-side dependency.

Evidence: Reporter (rax1795) independently confirmed the finding via Get-Item/Get-FileHash on a Chocolatey-installed 2.90.0 CLI, and confirmed 2.90.0 is the current Chocolatey/Windows-documented release — i.e., not an old/unpatched install. No az command in this repo enables or exercises the FTS5 extension, and no attacker-controlled SQLite database is accepted by any command surface, so there is no known exploitable path through Azure CLI itself; this remains a scanner-level packaging finding rather than a confirmed exploitable Azure CLI vulnerability.

Likely cause / owning area: Release engineering / Windows installer build pipeline (the component that packages the CPython interpreter and its bundled sqlite3.dll into the MSI), not the azure-cli command source tree.

Suggested fix: Bump the Python build/runtime used to produce the Windows MSI so the embedded sqlite3.dll incorporates SQLite ≥ 3.53.2, or re-vendor an updated sqlite3.dll in the installer pipeline if it is supplied independently of the interpreter build. This change lives in installer/release infrastructure, not in this repository's Python source, so it is not addressable via a standard command-level PR here.

Regression coverage: N/A for this repo — verification is at the installer level (confirm sqlite3.dll file version ≥ 3.53.2 in the next Windows MSI/Chocolatey build), not via azdev test.

Impact / workaround: No confirmed exploitable path in az commands today; impact is limited to the scanner finding itself. No user-facing workaround needed pending the installer rebuild.

Reproduction quality: High — reporter supplied exact file version, SHA-256, CLI version, and OS context, and a maintainer independently corroborated it is the current Chocolatey-distributed build.

Recommended next action: Hand off to the Azure CLI release-engineering/security team to schedule a Windows MSI rebuild against a patched Python/SQLite baseline. This is intentionally not routed to the automated code-fix pipeline because the remediation is a packaging/build-pipeline change, not an azure-cli source change.

Analysis

Thanks for the detailed follow-up, including the Chocolatey package metadata, exact bundled sqlite3.dll version (3.50.4.0), and the confirmation that no az command or code path in this repository accepts an attacker-controlled SQLite database, enables FTS5, or processes an affected FTS5 query. That additional context is enough to close out triage on the automation side.

Assessment

This is not a bug in Azure CLI's own Python source or in any specific az command; it is a report that the Windows installer/build (MSI and the Chocolatey-distributed package) bundles a Python runtime whose native sqlite3.dll is older than the version containing the fixes for CVE-2026-11822 / CVE-2026-11824 (SQLite FTS5 extension).
The bundled SQLite version is determined by the embedded Python build used to produce the Windows installer/Chocolatey artifacts, which is release/build infrastructure outside the scope this fix pipeline can modify with a source-only PR (there is no az <command> regression to reproduce or patch in the CLI source tree).
No confirmed exploitable code path has been identified in Azure CLI itself; this is a packaging/dependency version-currency issue best owned by the release/build and security teams, who control the Python build used to produce the Windows/Chocolatey artifacts.

Recommended next action: the Azure CLI release engineering team should evaluate bumping the embedded Python build to one linked against SQLite >= 3.53.2 for the next Windows MSI/Chocolatey release, and confirm whether earlier released installers should be reissued. This is being triaged as a packaging/dependency item rather than routed to automated code-fix, since there is no reproducible az command defect to patch in source.

Bug Analysis

Thanks for the detailed follow-up, including the Chocolatey deployment details and confirmation that Azure CLI 2.90.0 (the current Chocolatey package) ships sqlite3.dll 3.50.4.0.

Assessment

sqlite3.dll bundled with the Windows MSI/Chocolatey Azure CLI package is not a Python package pinned in this repository's source (e.g. setup.py / requirements). It is embedded transitively through the Python interpreter used by the release pipeline to build the Windows installer, and that build pipeline lives outside this source repository (it is not present in Azure/azure-cli).

Because of that, this cannot be resolved with a normal source-code pull request against an az command or module in this repo — there is no command, module, or file here that pins the SQLite version. A fix requires the release/packaging pipeline to embed a newer Python build (or a build step that patches SQLite) that ships SQLite ≥ 3.53.2.

Per the reporter's own analysis, no az command path was identified that accepts attacker-controlled SQLite input, enables/uses FTS5, or otherwise exercises the vulnerable FTS5 code path referenced by CVE-2026-11822 / CVE-2026-11824, so this does not currently look like a confirmed exploitable path through the CLI itself — it is a supply-chain/packaging hygiene item.

Recommendation

Escalating to the Azure CLI release/packaging owners to track bumping the embedded Python/SQLite version used by the next Windows MSI/Chocolatey build. No source-level module fix is being generated for this issue since there is no in-repo command/code path to change.

Analysis

Thanks for the additional detail confirming this is the current Chocolatey-distributed Azure CLI 2.90.0 package, not a stale install.

Assessment: The bundled sqlite3.dll (3.50.4.0) inside the Windows installer's embedded Python runtime is below the version containing the SQLite 3.53.2 FTS5 fixes (CVE-2026-11822, CVE-2026-11824). This is a packaging/dependency finding, not a code-level vulnerability in an az command: sqlite3.dll ships as part of the embedded CPython distribution used to build the Windows MSI, it is not vendored or referenced anywhere in this source repository, and there is no az command path in this codebase that accepts an attacker-controlled SQLite database, enables FTS5, or executes an FTS5 query against external input. That matches the reporter's own conclusion that no exploitable command path was identified.

Recommended action: This needs to be tracked as a build/release task to bump the embedded Python interpreter (and its bundled SQLite) used by the Windows installer pipeline to a version built against SQLite >= 3.53.2, rather than a source-code change to a specific command module. There is no az module/extension target for a normal code-fix PR here, so this is out of scope for automated command-level remediation and is being routed to the release/build owners as a dependency-bump request.

Impact/workaround: No confirmed exploitable path via Azure CLI commands today; risk is limited to the bundled library version itself being flagged by vulnerability scanners.

Marking triaged as a packaging dependency-bump request for the Windows installer build pipeline.

Analysis

Thanks for the detailed follow-up and reproduction data.

Root cause: the sqlite3.dll reported by the scanner is not vendored as source or a binary artifact anywhere in the Azure/azure-cli repository. It ships as part of the embedded Python runtime bundled by the Windows MSI build/installer pipeline (the Chocolatey package and the MSI both embed a standalone Python distribution, whose sqlite3 extension module links against a vendored sqlite3.dll). There is no az command, code path, or dependency pin inside this source repository that selects the SQLite version, so this cannot be remediated with a source change here.

Exploitability: consistent with the reporter's own assessment, we did not find any Azure CLI code path that opens an attacker-controlled SQLite database, enables the FTS5 extension, or evaluates untrusted FTS5 queries. Azure CLI only uses sqlite3 internally for its local token/msal cache, which is not attacker-influenced input, so the reported CVEs (CVE-2026-11822, CVE-2026-11824) do not appear directly exploitable through Azure CLI's own command surface today.

Recommended next action: this needs to be routed to the team that owns the Windows MSI/Chocolatey packaging pipeline so they can refresh the embedded Python build to a version that ships SQLite >= 3.53.2. That pipeline lives outside this repository, so no PR can be raised against Azure/azure-cli for it; flagging for manual escalation to the release/packaging owners instead of assigning an automated code fix here.

Rajiv Abraham Xavier (@rax1795)

Analysis

Observed vs expected: A vulnerability scanner (Nessus) flagged
C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll (file/product
version 3.50.4.0) bundled with the Chocolatey-distributed Azure CLI
2.90.0 MSI installer as below the scanner's remediation threshold of
SQLite 3.53.2, corresponding to CVE-2026-11822 and CVE-2026-11824 (SQLite
FTS5 extension issues in builds compiled with SQLITE_ENABLE_FTS5).

Affected surface: This sqlite3.dll is not azure-cli source code — it
ships as part of the embedded Python interpreter bundled into the Windows
MSI installer build (the interpreter's standard-library sqlite3 module
links against a vendored SQLite). It is not a module/extension command
implemented in this repository, so there is no az <command> source change
that resolves the reported version.

Evidence inspected: The reporter (Rajiv Abraham Xavier (@rax1795)) independently confirmed
that 2.90.0 is the current Chocolatey-delivered release, that the
installed sqlite3.dll is 3.50.4.0, and that no az command path was
identified that accepts an attacker-controlled SQLite database, or enables
or exercises the FTS5 extension query path affected by these CVEs. That
assessment is consistent with azure-cli's use of sqlite3 purely for local
cache/state (e.g. MSAL token cache, CLI config) rather than for
untrusted-input FTS5 querying.

Likely cause / owning area: The fix is a build/release-pipeline
concern — bumping the Python distribution (and its bundled SQLite) used to
produce the Windows MSI installer, then republishing a new azure-cli
release. This falls to the release engineering / installer-build owners
rather than a source-code PR in Azure/azure-cli.

Suggested next action: Route to the release/installer build owners to
confirm the Python version pinned for the next Windows MSI build bundles
SQLite >= 3.53.2, and confirm the planned azure-cli release version/ETA
for that update. No confirmed exploitable az command path was found, so
this is not release-blocking based on current evidence, but should be
tracked for the next installer refresh.

Reproduction quality: High — exact installed DLL version, hash,
az version output, and OS/environment details were provided by both the
original reporter and a follow-up confirmation from another user on the
same Chocolatey-distributed release.

Bug Analysis

Summary: The reporter's follow-up confirms the finding: the Windows MSI/Chocolatey-distributed Azure CLI 2.90.0 package bundles a Python interpreter whose built-in sqlite3 extension is backed by sqlite3.dll version 3.50.4.0. This is below the version (3.53.2) that fixes the upstream SQLite FTS5 vulnerabilities CVE-2026-11822 and CVE-2026-11824.

Investigation:

sqlite3.dll is not vendored or referenced anywhere in the Azure/azure-cli source tree (no sqlite3 references in .py/.txt/.cfg/.spec files across the repo). It ships as part of the embeddable Python runtime used to build the Windows MSI/Chocolatey installer.
infer_target could not resolve this to any azure-cli module or extension — there is no az <command> affected and no in-repo source file that pins or vendors this DLL.
This is therefore not fixable via a source-code pull request in this repository. The remediation is to rebuild the Windows installer against an updated embeddable Python (or otherwise refresh the bundled Python/SQLite runtime) with SQLite >= 3.53.2, which happens in the separate release/packaging pipeline that produces the MSI and Chocolatey artifacts.

Recommendation: Route this to the Azure CLI release/packaging owners so the next Windows installer build picks up an updated Python runtime with a patched SQLite. No automated code fix will be opened for this issue since there is no affected module/extension/command to change in this repository.

Severity/impact: The CVEs affect SQLite's FTS5 extension; Azure CLI does not use FTS5-backed functionality directly, but the bundled DLL should still be refreshed as part of routine dependency hygiene and to satisfy vulnerability scanners (e.g., Nessus) run against Azure CLI installations.

Bug Analysis

Summary: This is a packaging/dependency vulnerability report, not a functional az command bug.

Observed vs expected: A vulnerability scanner (Nessus) flagged sqlite3.dll version 3.50.4.0 bundled inside the Windows Azure CLI installer (MSI/Chocolatey package, Azure CLI 2.90.0, path C:\Program Files\Microsoft SDKs\Azure\CLI2\sqlite3.dll) as below the fixed version 3.53.2 for CVE-2026-11822 and CVE-2026-11824, both affecting the SQLite FTS5 extension.

Affected surface/component: The bundled sqlite3.dll is part of the embedded Python runtime packaged with the Windows installer build, not a dependency declared in azure-cli/azure-cli-core's Python package metadata or setup.py/requirements*.txt.

Source inspected: A repository code search for sqlite3.dll and sqlite3 packaging references in Azure/azure-cli (including scripts/) returned no matches, confirming the DLL version is inherited from the Python interpreter build used by the installer pipeline, not something controlled by source files in this repository.

Reporter's own assessment (from the follow-up comment): They have not identified an az command or code path in Azure CLI that accepts an attacker-controlled SQLite database, enables/uses FTS5, or otherwise exercises the affected FTS5 query path. They are explicitly reporting this as a packaging/dependency assessment request rather than a confirmed exploitable vulnerability in Azure CLI itself.

Likely cause / owning area: The fix requires bumping the embedded Python build (and its statically/dynamically linked SQLite) used to produce the Windows MSI/Chocolatey installer artifact — this is a release/build-pipeline concern, not a source-code change addressable via a standard az command PR in this repository.

Recommended next action: Route to the Azure CLI release/build engineering owners to confirm the Python build version used for the Windows installer and schedule a rebuild against a Python version bundling SQLite >= 3.53.2 (or bump sqlite3.dll directly in the installer packaging step). No source code change in this repository can resolve the underlying binary version, so no automated code fix will be generated for this issue.

Impact/workaround: No confirmed exploitable az command path was identified; impact is limited to the presence of the outdated library version itself as flagged by static vulnerability scanning.

Bug Analysis

Summary: This is a packaging/dependency-version report, not a reproducible
Azure CLI command defect. A vulnerability scanner (Nessus) flagged the SQLite
library (sqlite3.dll v3.50.4.0) bundled with the Windows Azure CLI installer
(MSI / Chocolatey package, azure-cli 2.90.0) as older than the upstream
SQLite security fix release (3.53.2), which addresses CVE-2026-11822 and
CVE-2026-11824 in the FTS5 extension.

What was checked:

The reporter confirmed 2.90.0 is the current Chocolatey-distributed release,
so this is not simply a case of running an old Azure CLI version.
No az command or Azure CLI code path was identified that accepts an
attacker-controlled SQLite database, enables SQLITE_ENABLE_FTS5, or
otherwise exercises the affected FTS5 query path, so there is no confirmed
exploitable command flow in Azure CLI itself.
There is no reproducible az <command> failure, error message, or code
defect to fix — azure-cli's Python source does not directly control which
SQLite build gets bundled into the Windows installer image.

Why this does not fit the automated code-fix pipeline: The affected
artifact (sqlite3.dll) is a transitive native dependency pulled in by the
Windows embeddable Python distribution used to build the MSI/Chocolatey
installer, not a module or extension command implemented in this repository.
Resolving it requires bumping the embedded Python (or its bundled SQLite
runtime) in the Windows installer build pipeline/release tooling — a build and
release engineering change rather than a [Component] Fix #N: az ... command
patch, so infer_target correctly resolves no module/extension target here.

Recommendation: Route this to the Azure CLI release/build engineering
owners to confirm exploitability assessment and schedule a bundled SQLite
(or embedded Python) version bump in the next Windows installer build, and
respond to the reporter with the assessed exploitability and target release.

Assessment: Legitimate security-scanner finding on a bundled dependency,
but no confirmed exploitable Azure CLI command path has been identified, so
this is not an active security incident requiring emergency handling.

Bug Analysis

Summary: A vulnerability scanner (Nessus) flagged the bundled sqlite3.dll (v3.50.4.0) shipped inside the Windows Azure CLI installer (MSI and Chocolatey package) as older than the upstream SQLite security fix version 3.53.2, which addresses CVE-2026-11822 and CVE-2026-11824 (FTS5 extension issues).

Investigation:

This is a native dependency version finding, not a functional bug reproducible with an az command. The reporter confirmed via a Nessus scan and provided the DLL path, file version, and hash, plus install context (Chocolatey azure-cli 2.7.4 package, CLI 2.90.0) in a follow-up comment.
infer_target resolves no CLI module or extension from this report (there is no failing command, error, or expected/actual command behavior) — this cannot enter the automated Copilot code-fix pipeline, which targets az command/module source changes.
The affected artifact (sqlite3.dll) is a bundled native library baked into the Windows installer build (MSI/Chocolatey packaging), not Python source under a azure-cli/azure-cli-extensions command module. Bumping it requires updating the installer build pipeline/toolchain (e.g., the pinned SQLite version used when building the Windows installer), which is outside the scope of a source-level command fix.

Recommendation: Route this to the Azure CLI build/release engineering owners to confirm exploitability in the CLI's usage of SQLite (no FTS5-driven user-controlled query surface is known in az) and to schedule a bundled-dependency bump to SQLite ≥ 3.53.2 in the next Windows installer build. This is a supply-chain/dependency-hygiene item, not an automated code-fix candidate.

No further automated action will be taken by this pipeline; leaving for manual build/release triage.

Bug Analysis

Observed: A vulnerability scanner (Nessus) flagged the bundled sqlite3.dll (version 3.50.4.0) inside the Windows Azure CLI 2.90.0 installation (both the MSI/Microsoft SDKs path and the Chocolatey-distributed package) as below the upstream SQLite security-fix version 3.53.2, corresponding to CVE-2026-11822 and CVE-2026-11824 (SQLite FTS5 extension, builds compiled with SQLITE_ENABLE_FTS5).

Expected: The bundled sqlite3.dll dependency version should be updated to 3.53.2 or later in a future Azure CLI Windows installer/package release.

Reproduction quality: No az command, error, or CLI code path is reported or reproducible — the reporter explicitly confirms "No commands related to this" and a follow-up comment states no az command or code path was identified that accepts an attacker-controlled SQLite database, enables/uses FTS5, or exercises an affected FTS5 query path. This is a static/dependency scanner finding against a bundled native binary, not a reproducible CLI behavior defect.

Affected surface: Windows installer packaging (MSI / Chocolatey azure-cli package), specifically the bundled Python's sqlite3.dll native dependency. There is no azure-cli module or extension command associated with this report, so infer_target resolves nothing actionable for an automated code fix.

Assessment: This is a packaging/build dependency-version concern, not a code-level bug fixable through a az <command> change, unit test, or PR against the azure-cli/azure-cli-extensions Python source. Addressing it requires the Windows installer/build pipeline to bump the bundled SQLite (or the Python build it embeds) to a version ≥ 3.53.2, which is release-engineering work outside this automated code-fix pipeline's scope (no reproducible command, no source module to patch, no test to add).

Recommended next action: Route to the Azure CLI release/build engineering owners to evaluate updating the bundled SQLite version in the next Windows installer build cycle (MSI and Chocolatey package). No automated Copilot code fix will be created for this issue since there is no reproducible command or patchable module.

CVE

Thanks for the report. Our assessment and plan follow.

Where the DLL comes from.

Azure CLI does not build, vendor, or independently version SQLite. sqlite3.dll is a component of the official embedded CPython runtime we ship in the Windows MSI/ZIP (currently CPython 3.14.6 from python.org). The 3.50.4 you see is precisely the SQLite that upstream CPython compiles into that build — its version is entirely governed by the CPython release we ship.

Exploitability in Azure CLI

We assess this as not exploitable through Azure CLI. The referenced CVEs are in the FTS5 extension and require processing attacker-controlled FTS5 queries/data. We checked both the core CLI and the extensions:

No sqlite3 usage and no FTS5 usage anywhere in the codebase, and no runtime dependency opens a SQLite database.

Remediation plan & ETA

Because the SQLite version is determined by the embedded CPython we ship, remediation is tied to CPython bundling a fixed SQLite:

CPython 3.14.x — through 3.14.7 and the current 3.14 maintenance branch — still bundles SQLite 3.50.4. Upstream has not backported the newer SQLite to the 3.14 line, so no 3.14 patch release will clear this finding.
The fix first appears in the CPython 3.15 line, which bundles SQLite ≥ 3.53.2 (3.15 currently pins 3.53.2; later 3.15.x is expected to track 3.53.4).
CPython 3.15.0 has not been finally released yet — as of today it is at release-candidate stage (rc2), with the final expected in roughly October 2026.

Our plan is to pick up SQLite ≥ 3.53.2 by moving the Windows build to the official CPython 3.15 embedded distribution once 3.15.0 is finally released. This is a Python feature-version upgrade (3.14 → 3.15), so it will go through our normal dependency and regression validation before shipping. We will target the first Azure CLI release that follows CPython 3.15.0's GA and completes that validation. We are intentionally not substituting a third-party/independently downloaded SQLite binary, to keep the runtime a single, coherent, upstream-signed CPython distribution.

We'll update this thread once the 3.15.0-based build is scheduled. Thanks again for flagging it.

Navigation Menu

Repository navigation

CVE-2026-11824,CVE-2026-11822 - Azure CLI bundles sqlite3.dll 3.50.4.0, below upstream security fix 3.53.2 #34041

Describe the bug

Related command

Errors

Issue script & Debug output

Expected behavior

Environment Summary

Additional context

Bug Analysis

Analysis

Bug Analysis

Bug Analysis

Bug Analysis

Bug Analysis

Analysis

Bug Analysis

2 remaining items

Analysis

Analysis

Analysis

Bug Analysis

Bug Analysis

Bug Analysis

Bug Analysis

Bug Analysis

Where the DLL comes from.

Exploitability in Azure CLI

Remediation plan & ETA

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

CVE-2026-11824,CVE-2026-11822 - Azure CLI bundles sqlite3.dll 3.50.4.0, below upstream security fix 3.53.2 #34041

Description

Describe the bug

Related command

Errors

Issue script & Debug output

Expected behavior

Environment Summary

Additional context

Activity

yonzhan commented on Sep 7, 2026

x-engineering-agent commented on Sep 7, 2026

rax1795 commented on Sep 7, 2026

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

x-engineering-agent commented on Sep 7, 2026

Analysis

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

x-engineering-agent commented on Sep 7, 2026

Analysis

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

2 remaining items

x-engineering-agent commented on Sep 7, 2026

Analysis

x-engineering-agent commented on Sep 7, 2026

Analysis

x-engineering-agent commented on Sep 7, 2026

Analysis

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

x-engineering-agent commented on Sep 7, 2026

Bug Analysis

yonzhan commented on Sep 7, 2026

msarfraz commented on Sep 8, 2026

Where the DLL comes from.

Exploitability in Azure CLI

Remediation plan & ETA

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions