[FP]: CVE-2026-33117 reported against unrelated Azure libraries

[JackPGreen]

Package URl

pkg:maven/com.microsoft.azure/azure-data-lake-store-sdk@2.3.9

CPE

cpe:2.3:a:microsoft:azure_sdk_for_java:2.3.9:::::::*

CVE

CVE-2026-33117

ODC Integration

{"label" => "Maven Plugin"}

ODC Version

12.2.2

Description

On NVD's CPE is targeting azure_sdk_for_java, so matching azure-data-lake-store-sdk seems to be a false positive to me.

This also affects pkg:maven/com.microsoft.azure/azure-keyvault-core@1.0.0, and I would therefore assume any Azure client library.

Of note - I also think the NVD CPE may be too broad - the Microsoft docs suggests the problem/fix is in the com.azure:azure-security-keyvault-keys library. I will flag to NVD.

[github-actions]

Maven Coordinates

<dependency>
  <groupId>com.microsoft.azure</groupId>
  <artifactId>azure-data-lake-store-sdk</artifactId>
  <version>2.3.9</version>
</dependency>

Suppression rule:

<suppress base="true">
    <notes><![CDATA[
    FP per issue #8553
    ]]></notes>
    <packageUrl regex="true">^pkg:maven/com\.microsoft\.azure/azure-data-lake-store-sdk@.*$</packageUrl>
    <cpe regex="true">cpe:/a:microsoft:azure_sdk_for_java(:.*)?$</cpe>
</suppress>

Link to test results: https://github.com/dependency-check/DependencyCheck/actions/runs/26513996065

[chadlwilson]

NVD doesn’t really manage packages, it manages products. If you expect that kind of granularity of matching, it’s probably not fit for purpose.

Microsoft is the CNA here, and they say the below, so they are not exactly helping with specificity. Their own advisory does not report the problematic library version or its maven coordinates, only the wrapping SDK.

The Java Key Vault Keys library in the Azure SDK for Java

Given we cannot manage CVE-by-CVE suppressions (it’s not scalable), we are constrained by how vendors use Maven and group their libraries. We can suppress packages URLs against certain CPEs, and that’s about it, really.

Unfortunately this has a very generic CPE name, so you’re going to get a lot of false positives. The risk is probably that if we carve out a whole lot of package exemptions (to say they don’t match that CPE) there might be false negatives, either because NVD don’t match to finer grained libraries (e.g for a possible future azure data lake sdk issue) or because we excluded a package we shouldn’t.

It’s possible we might be able to craft a more specific CPE match, but i suspect it may not be possible due to the sheer number of libraries under the massively overloaded com.microsoft.azure group id, and likely impossibility of determining which of those comprise the core SDK (versioned with it) and which do not. https://mvnrepository.com/artifact/com.microsoft.azure