Microsoft’s terse advisory and the NVD entry for CVE‑2025‑37804 together tell a short, important story: the CVE identifier was later marked “Rejected” by the responsible authorities, yet Microsoft’s product‑level attestation naming Azure Linux as a carrier of the implicated open‑source component remains a valid, actionable inventory statement — and those two facts together create a practical disruption for defenders who must reconcile machine‑readable attestations, rescinded CVE metadata, and artifact‑level reality.
Microsoft’s Security Response Center (MSRC) has begun publishing machine‑readable CSAF/VEX attestations to clarify which Microsoft products include which third‑party components and whether those products are known affected, not affected, or fixed. That program formally launched in October 2025 and began with a phased rollout that prioritized the Azure Linux distribution. The intent is to reduce noise for customers and security vendors by providing precise, automated signals about a vulnerability’s applicability to specific Microsoft artifacts.
Separately, the CVE identifier CVE‑2025‑37804 was later marked Rejected (the NVD shows the entry with the rejection reason: “This CVE ID has been rejected or withdrawn by its CVE Numbering Authority”), meaning the CNA concluded the entry was not appropriate as a distinct CVE record. Rejection can have multiple causes — a duplicate, an issue judged not to meet CVE criteria, or a misfiled report — but in practice it means the CVE number no longer maps cleanly to an active advisory record in public CVE feeds.
The combination of these two facts — Microsoft’s product‑level VEX attestation for Azure Linux and the broader CVE rejection — is what produced the question you asked: “Is Azure Linux the only Microsoft product that includes this open‑source library and is therefore potentially affected by this vulnerability?” The short answer is: No, Azure Linux is not necessarily the only Microsoft product that could include the same upstream code; it is the only Microsoft product Microsoft has publicly attested (so far) as including the component. That attestation is authoritative for the product it names, but absence of attestations for other Microsoft artifacts is not evidence those artifacts are unaffected.
However, Microsoft’s attestation stops short of making any exclusivity claim. The company has stated publicly that its VEX rollout started with Azure Linux as a prioritized product and that Microsoft will update CVE/VEX mappings as inventory checks for additional product families complete. That language — “we will update the CVE to reflect [additional affected products] if they are identified” — is process‑oriented: Microsoft is describing what it has checked so far and promising to expand coverage, not asserting that other Microsoft artifacts can never include the same library.
Note: the exact symbol, filename, and commit ID to search for depend on the specific upstream fix; consult the upstream kernel commit and the MSRC/CSAF product tree to extract the right search tokens.
At the same time, the later Rejected status for CVE‑2025‑37804 in public CVE feeds is a metadata outcome that changes only the identifier’s lifecycle; it does not negate the upstream code changes or the need to verify artifacts that may still contain the original code. Do not use CVE absence as proof of absence. Instead, map to commits, package versions, SBOMs, and VEX product entries to reach a defensible, verifiable remediation decision.
Finally, treat Microsoft’s phased VEX rollout as a significant improvement in vendor transparency — but not as a one‑and‑done cure. Until Microsoft publishes product attestations broadly across its artifact landscape, defenders must combine vendor VEX inputs with local artifact verification to fully close the inventory gap and remove ambiguity from their exposure calculations.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
Microsoft’s Security Response Center (MSRC) has begun publishing machine‑readable CSAF/VEX attestations to clarify which Microsoft products include which third‑party components and whether those products are known affected, not affected, or fixed. That program formally launched in October 2025 and began with a phased rollout that prioritized the Azure Linux distribution. The intent is to reduce noise for customers and security vendors by providing precise, automated signals about a vulnerability’s applicability to specific Microsoft artifacts.Separately, the CVE identifier CVE‑2025‑37804 was later marked Rejected (the NVD shows the entry with the rejection reason: “This CVE ID has been rejected or withdrawn by its CVE Numbering Authority”), meaning the CNA concluded the entry was not appropriate as a distinct CVE record. Rejection can have multiple causes — a duplicate, an issue judged not to meet CVE criteria, or a misfiled report — but in practice it means the CVE number no longer maps cleanly to an active advisory record in public CVE feeds.
The combination of these two facts — Microsoft’s product‑level VEX attestation for Azure Linux and the broader CVE rejection — is what produced the question you asked: “Is Azure Linux the only Microsoft product that includes this open‑source library and is therefore potentially affected by this vulnerability?” The short answer is: No, Azure Linux is not necessarily the only Microsoft product that could include the same upstream code; it is the only Microsoft product Microsoft has publicly attested (so far) as including the component. That attestation is authoritative for the product it names, but absence of attestations for other Microsoft artifacts is not evidence those artifacts are unaffected.
What “Rejected” CVE actually means — and what it doesn’t
Rejected is a metadata action, not a source‑code rollback
When a CVE ID is marked REJECTED by its CNA, that change is a metadata decision about the identifier — not a technical undoing of upstream commits or vendor patches. In other words, the underlying code changes in the upstream project (for example, the Linux kernel commits that corrected behavior) remain present in the source control history and in vendor patches. A rejected CVE typically indicates:- The issue was a duplicate of another CVE or otherwise misallocated.
- The reporter or CNA determined the reported behavior did not meet the CVE criteria.
- The identifier was withdrawn for administrative reasons.
Operational consequences of a rejection
- Automated scanners may continue to flag the original CVE entry or show inconsistent statuses across feeds; reconciliation is necessary.
- Patch orchestration that uses CVE identifiers as triggers must instead map to the actual upstream patch / package version to be confident remediation is complete.
- Vendors (including Microsoft) can still publish product‑specific attestations (VEX/CSAF) that document whether their inventory includes the implicated component even if the CVE label was withdrawn.
Microsoft’s attestation: what the Azure Linux statement actually declares
Microsoft’s MSRC and CSAF/VEX outputs use precise, product‑scoped language. When Microsoft’s advisory states that “Azure Linux includes this open‑source library and is therefore potentially affected,” that is a deliberate inventory attestation: Microsoft has inspected the Azure Linux distribution and found the implicated upstream component present in one or more Azure Linux builds, and thus Azure Linux is a confirmed carrier (or “Known Affected” in VEX terms) until Microsoft marks it as fixed. That Apple‑to‑Apple mapping is useful and actionable: organizations that run Azure Linux images can and should treat Microsoft’s attestation as a high‑priority signal to apply vendor‑supplied fixes or follow the MSRC guidance.However, Microsoft’s attestation stops short of making any exclusivity claim. The company has stated publicly that its VEX rollout started with Azure Linux as a prioritized product and that Microsoft will update CVE/VEX mappings as inventory checks for additional product families complete. That language — “we will update the CVE to reflect [additional affected products] if they are identified” — is process‑oriented: Microsoft is describing what it has checked so far and promising to expand coverage, not asserting that other Microsoft artifacts can never include the same library.
Why Azure Linux being named does not imply other Microsoft artifacts are safe
Several technical realities make the presence of an upstream component an artifact‑specific property:- Kernel version, upstream commit range, and applied backports differ between artifacts. A Linux device driver or subsystem can be included in one kernel build and omitted in another depending on the exact commit range and kernel CONFIG_* options used during build.
- Microsoft maintains multiple Linux‑derived artifacts that may be built in different pipelines: Azure Linux itself, WSL2 kernels shipped with Windows, linux‑azure kernels used in some VM SKUs, marketplace images, and partner appliance images. Each is an independent artifact that must be inventoried to determine whether it includes a given upstream file.
- Packaging and backporting: downstream distributors often backport fixes to older package versions. A rejected CVE label does not erase the fact that a backport may or may not have been applied in a specific product snapshot.
Cross‑checking the record: independent verification steps
Key claims to verify and where to check them:- Claim: The CVE ID CVE‑2025‑37804 was rejected. Verification: Check the NVD and other CVE mirrors — NVD shows CVE‑2025‑37804 marked REJECTED with the stated reason.
- Claim: Microsoft published VEX/CSAF starting October 2025 and began with Azure Linux. Verification: MSRC blog post announcing the VEX rollout and the October 22, 2025 debut.
- Claim: Microsoft’s product‑scope attestation names Azure Linux as including the implicated open‑source library. Verification: Microsoft’s CSAF/VEX payloads and MSRC advisory entries explicitly list Azure Linux product entries as “Known Affected” in the product tree. Third‑party aggregators and community analyses mirror that fact.
- Claim: Multiple downstream trackers may show inconsistent states following a rejected CVE. Verification: Snyk and other vulnerability feeds document when a CVE was revoked or marked “not applicable” for given package builds; mirrors like cve.circl.lu capture rejected metadata for other related entries.
Practical, verifiable steps for defenders (what to do now)
If Microsoft has attested Azure Linux as a known carrier but the CVE was rejected, follow these recommended steps to remove ambiguity from your risk posture:- Identify which Microsoft artifacts you run.
- List Azure Marketplace images, WSL2 kernel versions, linux‑azure kernels used in VM SKUs, and any Microsoft‑published container images or VM images in your environment.
- For each artifact, extract the kernel and package versions.
- On a running Linux image: uname -a; rpm -qa | grep kernel or dpkg -l | grep linux-image.
- For container images: inspect the image layer and installed packages using container scanning tools (e.g., package managers or sbom extraction).
- Map versions to upstream commit IDs or patch numbers.
- Use distribution changelogs and the upstream kernel commit references; do not rely only on CVE IDs. The MSRC VEX/CSAF payloads often list product build identifiers you can match.
- If the artifact matches the product entry Microsoft attested as known_affected, apply Microsoft’s recommended update or the patched kernel package immediately.
- If an artifact is not listed in Microsoft’s VEX payloads, treat it as unverified:
- Either request an attestation from Microsoft for that artifact or perform binary/tracing checks to determine whether the implicated code is present (search for specific driver filenames, symbols, or commit diffs).
- Tune your scanning and orchestration systems to consume VEX/CSAF outputs where available and to resolve rejected/withdrawn CVE metadata by looking up upstream commit IDs and distribution advisories.
Sample verification commands and approaches
Use these short, practical checks to determine whether a particular image or kernel includes the affected code path:- On a running Linux VM or container:
- uname -r && rpm -q kernel || dpkg-query -W linux-image-$(uname -r)
- grep -R "driver_or_symbol_name" /lib/modules/$(uname -r) || strings /boot/vmlinuz-$(uname -r) | grep "symbol"
- For offline image inspection:
- Pull the image locally and run a package listing: rpm -qa --root /path/to/mounted/image or dpkg‑query --admindir=/path/to/image/var/lib/dpkg -l.
- Use SBOMs if available: check the image’s SBOM or the vendor‑published CSAF file to match package names and versions.
- For kernel source mapping:
- Compare the distribution’s kernel package changelog to the upstream commit IDs referenced in the kernel.org commit that fixed the defect.
Note: the exact symbol, filename, and commit ID to search for depend on the specific upstream fix; consult the upstream kernel commit and the MSRC/CSAF product tree to extract the right search tokens.
Strengths and risks of Microsoft’s CSAF/VEX approach — critical analysis
Strengths
- Operational clarity for named products. Microsoft’s VEX attestations give defenders machine‑readable, authoritative mappings for products Microsoft has inventory‑checked. When present, these mappings enable automation to prioritize and remediate quickly. This is especially useful for cloud customers that run the exact Microsoft‑published images.
- Phased rollout reduces early‑stage errors. By starting with Azure Linux and expanding gradually, Microsoft can validate the VEX pipeline and reduce the chance of incorrect attestations.
- Traceability to product artifacts. CSAF/VEX payloads commonly include product identifiers and build metadata, which enables exact matching to deployed artifacts if defenders ingest the files.
Risks and friction points
- Partial coverage creates false comfort. An attestation that names Azure Linux but omits other artifacts can lull organizations into thinking all Microsoft artifacts are safe when they are not. Absence of mention ≠ absence of risk.
- Vulnerability metadata churn complicates automation. Rejected CVE labels create noisy signals across feeds. Organizations that rely on CVE presence/absence for gating must adapt and map to upstream commits and vendor package updates.
- Vendor trust and timing. A phased VEX rollout means a window of time during which critical Microsoft artifacts may be un‑attested. That timing gap requires defenders either to trust Microsoft’s pipeline and wait for attestations or to perform artifact verification themselves — a nontrivial operational burden at scale.
Recommended policy and automation changes for defenders
- Ingest MSRC’s CSAF/VEX payloads into your vulnerability orchestration pipeline and use them as high‑confidence inputs for the named products they list.
- Add an upstream‑commit mapping step to your automation: where possible, map CVE entries to upstream commit IDs and package versions to avoid dependency on CVE lifecycles alone.
- Treat VEX/CSAF absence as “unverified” rather than “not affected”; require an explicit not_affected attestation or a local artifact scan before de‑prioritizing remediation.
- Maintain a local SBOM inventory for your images and VMs. SBOMs paired with VEX provide deterministic answers.
- Build a reconciliation job that flags CVE entries that shift to REJECTED and surfaces any matching artifact records; this prevents CVE churn from auto‑clearing items that still require patching.
Unverifiable claims and caveats
- It is impossible, using only public data, to assert with absolute certainty whether every Microsoft artifact other than Azure Linux ever included the exact upstream source file in question without either: (a) Microsoft publishing a product‑scoped VEX/CSAF attestation for each product, or (b) performing binary or source inspections across each artifact. Any blanket statement that “no other Microsoft product is affected” is therefore speculative unless backed by explicit attestations or artifact scans.
- The rejection of CVE‑2025‑37804 removes the CVE label as a tracking token, but it does not retroactively change the upstream patches. Defenders must therefore use commit IDs and package changelogs as their remediation anchors rather than CVE status alone.
Conclusion — a pragmatic stance for operations teams
Microsoft’s statement that “Azure Linux includes this open‑source library and is therefore potentially affected” is an authoritative, product‑scoped attestation for the Azure Linux images Microsoft has checked. That attestation is actionable and should be treated as such by customers who run Azure Linux: verify your Azure Linux image builds, apply Microsoft’s patches or package updates, and automate the consume‑and‑remediate flow using the VEX/CSAF payloads when available.At the same time, the later Rejected status for CVE‑2025‑37804 in public CVE feeds is a metadata outcome that changes only the identifier’s lifecycle; it does not negate the upstream code changes or the need to verify artifacts that may still contain the original code. Do not use CVE absence as proof of absence. Instead, map to commits, package versions, SBOMs, and VEX product entries to reach a defensible, verifiable remediation decision.
Finally, treat Microsoft’s phased VEX rollout as a significant improvement in vendor transparency — but not as a one‑and‑done cure. Until Microsoft publishes product attestations broadly across its artifact landscape, defenders must combine vendor VEX inputs with local artifact verification to fully close the inventory gap and remove ambiguity from their exposure calculations.
Source: MSRC Security Update Guide - Microsoft Security Response Center
