Microsoft’s brief product attestation — “Azure Linux includes this open‑source library and is therefore potentially affected” — is accurate for the product it names, but it is a scoped inventory statement, not proof that no other Microsoft product can contain the same vulnerable OpenSSL code. s://www.microsoft.com/en-us/msrc/blog/2025/10/toward-greater-transparency-machine-readable-vulnerability-exploitability-xchange-for-azure-linux)
In January 2024 the OpenSSL project published an advisory for CVE‑2023‑6237, described as “Excessive time spent checking invalid RSA public keys.” The core of the issue is that the OpenSSL function EVP_PKEY_public_check() performs a compositeness check on the RSA modulus n; when presented with an unusually large prime modulus (or other crafted input), the check can take a very long time, allowing an attacker who can supply such a modulus to induce excessive CPU consumption and potentially a denial‑of‑service. The OpenSSL project fixed the defect in the 3.x line (fixed in 3.0.13, 3.1.5 and 3.2.1).
Major Linux distributions and downstream packages have incorporated the OpenSSL fixes and published advisories and updates (for example, SUSE and multiple RHEL‑family advisories list CVE‑2023‑6237 as a fixed OpenSSL issue). This CVE has therefore been widely tracked and patched at the distribution level.
Microsoft’s Security Response Center (MSRC) published product‑scoped attestation language for a range of third‑party CVEs as part of the company’s rollout of machine‑readable CSAF/VEX attestations. Microsoft began publishing VEX attestations in October 2025 and has used that program to state, in per‑CVE pages and FAQ text, that Azure Linux (the Microsoft‑branded Linux distribution) includes an implicated open‑source library and is therefore potentially affected — and that Microsoft will update CVE/VEX records if additional Microsoft products are later identified as carriers of the same upstream code.
However, Microsoft’s attestation is not a universal exclusivity guarantee. Any Microsoft artifact that bundles a vulnerable OpenSSL build could, in principle, be affected until that artifact is inventory‑checked and declared Not Affected or Fixed in MSRC’s CSAF/VEX feed. Organizations must therefore combine three actions: (1) apply the OpenSSL patches (or vendor updates) where available, (2) perform per‑artifact inventory checks for Microsoft and other vendor artifacts, and (3) harden parsing/validation code paths against resource exhaustion by adding input bounds, timeouts, and isolation.
In short: Azure Linux is the Microsoft product Microsoft has confirmed so far; it is not — and should not be read as — definitive proof that no other Microsoft product can contain the vulnerable OpenSSL code. Act on the Azure Linux attestation immediately if you run it, and treat other Microsoft artifacts with caution and verification until they appear in the VEX/CSAF inventory or you have performed an independent package-level inspection.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
In January 2024 the OpenSSL project published an advisory for CVE‑2023‑6237, described as “Excessive time spent checking invalid RSA public keys.” The core of the issue is that the OpenSSL function EVP_PKEY_public_check() performs a compositeness check on the RSA modulus n; when presented with an unusually large prime modulus (or other crafted input), the check can take a very long time, allowing an attacker who can supply such a modulus to induce excessive CPU consumption and potentially a denial‑of‑service. The OpenSSL project fixed the defect in the 3.x line (fixed in 3.0.13, 3.1.5 and 3.2.1).Major Linux distributions and downstream packages have incorporated the OpenSSL fixes and published advisories and updates (for example, SUSE and multiple RHEL‑family advisories list CVE‑2023‑6237 as a fixed OpenSSL issue). This CVE has therefore been widely tracked and patched at the distribution level.
Microsoft’s Security Response Center (MSRC) published product‑scoped attestation language for a range of third‑party CVEs as part of the company’s rollout of machine‑readable CSAF/VEX attestations. Microsoft began publishing VEX attestations in October 2025 and has used that program to state, in per‑CVE pages and FAQ text, that Azure Linux (the Microsoft‑branded Linux distribution) includes an implicated open‑source library and is therefore potentially affected — and that Microsoft will update CVE/VEX records if additional Microsoft products are later identified as carriers of the same upstream code.
What CVE‑2023‑6237 actually is (technical summary)
The vulnerable code path
- The vulnerability is rooted in OpenSSL’s key validation helpers: EVP_PKEY_public_check() invoked on RSA public keys performs checks intended to validate the structure of the key, including a check that the modulus n is composite (the typical RSA modulus is the product of two large primes).
- If an attacker supplies a modulus value that is an extremely large prime (or otherwise crafted to make the compositeness test slow), the compositeness test can take an impractically long time to finish. That CPU work occurs synchronously inside the OpenSSL call, so the calling application can be tied up, leading to resource exhaustion or denial‑of‑service.
Scope and real‑world impact
- The OpenSSL project notes that the function at issue (EVP_PKEY_public_check()) is not widely invoked by the core TLS/SSL implementation; it is used by the OpenSSL pkey command‑line tool and is available to applications that explicitly call it. That limits the immediate attack surface compared to flaws in core TLS verification, but applications that call key‑validation APIs on untrusted inputs are at risk.
- The OpenSSL advisory classifies the issue as low severity in terms of the library’s scoring, but it can yield a reliable denial‑of‑service wheployment constraints (for example, a public API that accepts arbitrary key material for validation).
Microsoft’s statement and what it means in practice
The literal MSRC wording
Microsoft’s public FAQ text that appears on multiple MSRC per‑CVE pages reads in essence: “Azure Linux includes this open‑source library and is therefore potentially affected… Microsoft began publishing CSAF/VEX in October 2025. If impact to additional products is identified, we will update the CVE to reflect this.” That is the source of the wording you quoted.How to interpret that wording
- Product‑scoped attestation, not exclusivity guarantee. Microsoft is saying: for the named CVE, we have inventory‑checked and confirm that Azure Linux images (the Microsoft‑published Linux distro and related CBL‑Mariner artifacts) include the affected upstream component. That confirmation is authoritative for Azure Linux artifacts, but it is not an assertion that no other Microsoft product ever ships the same code. Treat Microsoft’s attestation as a definitive “yes” for Azure Linux and as “not yet attested” for other Microsoft SKUs until Microsoft (or independent inspection) confirms otherwise.
- Why Microsoft takes this approach. Microsoft has chosen a phased rollout for machine‑readable attestations (CSAF + VEX), starting with Azure Linux and expanding outward. That “crawl, walk, run” approach is intended to give customers deterministic product mappings for the most common Linux artifacts first; the same phrasing has appeared in many MSRC CVE pages as the company expands its invrosoft.com]
Practical consequence
- If you run Azure Linux images (or CBL‑Mariner‑derived kernels and packages) you should treat that attestation as actionable: check package versions, apply updates, and follow Microsoft’s remediation guidance for the product.
- If you run other Microsoft artifacts (for example, WSL kernels shipped by Microsoft, custom Azure Marketplace VM images, Azure node images, container images published by Microsoft, or Windows‑native software that might bundle OpenSSL), you cannot assume you are safe simply because those artifacts are not listed in MSRC’s attestation; absence of a listing is not proof of absence of the vulnerable code. Independent verification is required in those cases.
Is Azure Linux the only Microsoft product that could be affected?
Short answer: No — but it is the only Microsoft product Microsoft has publicly attested (so far) to include the affected OpenSSL code for CVE‑2023‑6237.Why “not necessarily only” is thpenSSL is a ubiquitous downstream library. It can be compiled and bundled in many different products, especially those derived from Linux distributions or that run Linux workloads. A Microsoft‑branded Linux distribution (Azure Linux) is an obvious confirmed carrier because it explicitly packages OpenSSL; however, Microsoft distributes many different artifacts and images that may embed or link against OpenSSL (kernel userland packages, container images, appliance images, node images, and third‑party software Microsoft distributes or republishes).
- Whether any given Microsoft artifact is affected depends on the exact OpenSSL version bundled in that artifact and whether the vulnerable API/path is present and exercised by that artifact’s runtime behavior. That requires per‑artifact inspection (package versions, dynamically linked libraries, and runtime API usage).
Examples of Microsoft artifacts that could plausibly carry the same OpenSSL library (and thus merit inspection)
- Azure Linux images and the CBL‑Mariner family (explicitly confirmed).
- Azure Marketplace images and VM images in which Microsoft packages or caches common distro packages.
- Container images published or maintained in Microsoft registries that include OpenSSL in userland packages (for example, images derived from Linux vendors).
- WSL2 kernel images and linux‑azure kernels if those artifacts include an OpenSSL build (this is less common but not impossible for certain development tooling scenarios).
- Windows products and services that embed OpenSSL specifically (rare for Microsoft first‑party Windows components, but possible for third‑party software Microsoft ships or republishes).
Cross‑checking the claim with independent sources
- The OpenSSL advisory documents the defect, the affected versions (OpenSSL 3.0.0 through 3.0.12; 3.1.0 through 3.1.4; 3.2.0 through 3.2.0 — fixes shipped in 3.0.13, 3.1.5 and 3.2.1) and the functional details of EVP_PKEY_public_check(). This is the canonical technical record.
- Multiple downstream vendors (for example SUSE and Red Hat family advisories aggregated by vulnerability databases) list CVE‑2023‑6237 and have pushed patches into their packages, demonstrating that distributions quickly adopted the upstream OpenSSL fixes. That confirms both the nature of the fix and that the issue was broadly remediated in distribution packages.www.suse.com/support/update/announcement/2024/suse-su-20240518-1/)
- Microsoft’s own transparency blog explains the CSAF + VEX rollout and why per‑product attestations are being published starting with Azure Linux; MSRC CVE pages that accompany many Linux CVEs repeat the same FAQ text about Azure Linux being “potentially affected” and Microsoft’s plan to update CVE mappings if additional Microsoft products are found to include the component. That matches the snippet you quoted.
How to verify exposure and remediate (practical guidance)
If you operate Azure Linux, other Microsoft images, or any Linux‑based workloads, follow these steps immediately:- Inventory packages and library versions.
- On RPM‑based systems: rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' openssl openssl-libs openssl-devel
- On DEB‑based systems: dpkg -l | grep -i openssl
- For container images: run a lightweight container and inspect installed packages or inspect the image’s SBOM if provided.
- For binaries: ldd /path/to/binary | grep ssl to find dynamically linked OpenSSL.
- Confirm the OpenSSL version against the fixed releases.
- If your OpenSSL is older than 3.0.13 / 3.1.5 / 3.2.1 you should plan to update to a fixed package from your vendor or distribution. The OpenSSL advisory lists these fixed releases.
- Patch and deploy updated packages.
- Apply vendor patches (Microsoft’s Azure Linux update, distribution updates from Red Hat / SUSE / Debian / Ubuntu, or updated container images).
- For Azure Linux specifically, apply the Azure Linux security update Microsoft published for the affected packages. Nessus content and Azure Linux advisories show that Microsoft applied the update for its images.
- Mitigations for applications that explicitly call EVP_PKEY_public_check() or use the OpenSSL pkey CLI:
- Avoid calling EVP_PKEY_public_check() on untrusted data unless you can enforce size and complexity bounds on modulus values.
- Sanitize inputs and reject absurdly large key fields before passing them to OpenSSL.
- Use resource limits (process CPU quotas, timeouts, worker process isolation) for services that validate or parse external key material.
- For closed or third‑party Microsoft artifacts:
- Request or obtain the SBOM / SBOM‑style inventory for the artifact.
- Ask the vendor (or Microsoft if the artifact is Microsoft‑published) for the CSAF/VEX attestation or package inventory for the CVE in question. Microsoft’s VEX/CSAF rollout means some artifacts will already have machine‑readable attestations; if not, request per‑artifact verification.
- Detection aonitor CPU spikes and repeated long‑running openssl pkey invocations or scripts that call EVP_PKEY_public_check().
- Watch IDS/IPS logs for repeated submission of unusually large RSA key fields to any public API you expose.
Risk assessment and operational impact
- For most servers and applications that do not invoke OpenSSL’s key validation APIs on externally supplied key material, the practical exploitation risk is low. The OpenSSL team explicitly notes that the SSL/TLS implementation is not directly affected by this issue.
- The real risk applies to code paths that explicitly accept user‑supplied public keys and call EVP_PKEY_public_check() (or use the OpenSSL pkey utility with -check on untrusted input). In those cases, an attacker who can supply chosen key material can cause CPU exhaustion and denial of service with high reliability.
- In cloud environments, the risk also includes resource‑consumption costs (attacker‑driven CPU usage can inflate bills) and availability implications for multi‑tenant services that perform key verification on user inputs.
Why Microsoft’s product‑scoped attestation model matters (supply‑chain perspective)
- The industry has struggled historically with noisy vulnerability reportndors or ecosystems without clarity about which specific product builds include the vulnerable lines of source code. Microsoft’s decision to publish machine‑readable CSAF + VEX attestations (starting with Azure Linux) is meant to reduce that noise by providing per‑product, per‑CVE status: Known Affected, Not Affected, Under Investigation, or Fixed. This reduces false positives for defenders and improves prioritization.
- However, the phased approach necessarily produces interim states where only a subset of products have been inventoried. In those interim states, the vendor must use careful, deliberate language — exactly the kind of language Microsoft used — to avoid implying exclusivity where none is yet proven. The upshot for defenders: use the VEX/CSAF data where available, but where it is not available, fall back to artifact‑level inspection.
Recommendations for security teams (action checklist)
- Treat Microsoft’s Azure Linux VEX/CSAF attestation as authoritative for Azure Linux images; patch those images immediately if they contain vulnerable OpenSSL packages. //www.tenable.com/plugins/nessus/215789)
- Inventory all Microsoft‑published artifacts you run (WSL kernels, Azure Marketplace images, containers, node images). Don’t assume “not listed = safe.” If an artifact is not present in MSRC’s VEX mapping for CVE‑2023‑6237, perform your own package inspection or request the SBOM from Microsoft.
- For application developers and maintainers: review any code that calls EVP_PKEY_public_check() or untrusted use of OpenSSL key‑validation functions; add input size checks and reject key structures with unreasonable bitlengths before handing them to OpenSSL.
- Leverage process isolation and CPU quotas for parsing/validation tasks that may receive untrusted input; use worker processes with strict time limits to avoid single‑threaded CPU exhaustion. (This is practical hardening against resource‑exhaustion vulnerabilities.)
- Subscribe to vendor CSAF/VEX feeds where possible and use machine‑readable attestations to automate triage and patching decisions. Microsoft’s MSRC blog and the VEX rollout documentation explain how to find and use those attestations.
Limitations, open questions, and cautions
- Microsoft’s attestation for Azure Linux is a clear, actionable statement for that product family. It is not a universal statement about all Microsoft software. If you need absolute certainty about a particular Microsoft artifact, your organization should either request an SBOM / VEX attestation for that artifact from Microsoft or perform a direct inventory check of the artifact’s packages and runtime behavior.
- Some claims are difficult to verify publicly: whether closed‑source Microsoft servi OpenSSL release internally is often not publicly documented, and in such cases you must rely on Microsoft’s published VEX/CSAF data or on contractual/exchange channels to obtain authoritative inventory. Treat any assertion that “only Azure Linux is affected” as provisional unless accompanied by a f VEX attestation that enumerates all Microsoft artifacts and marks them Not Affected or Fixed.
- The immediate exploitability of CVE‑2023‑6237 is limited compared to TLS protocol bugs, but the class of problem — algorithmic resource exhaustion — shows up repeatedly in cryptographic and parsing code. Defender posture should therefore include input size limits, parsing timeouts, and process isolation as routine mitigations.
Final analysis — strengths and risks of Microsoft’s approach
Notable strengths
- Product‑level clarity where provided: When Microsoft publishes a VEX/CSAF attestation naming Azure Linux as a known affected product, customers running those images have an unambiguous, machine‑readable signal to act on. That greatly simplifies triage and reduces false positive triage time.
- Upstream correctness and distribution patching: OpenSSL issued a timely patch and distributions have integrated the fix; that ecosystem behavior — upstream fix followed by distro packaging and downstream advisories — reduces the window of exposure for most users.
Potential risks and gaps
- Inventory completeness: The phased VEX rollout leaves gaps in per‑product coverage early on. Customers must therefore be careful not to over‑interpret “Azure Linux includes the library” as “therefore no other Microsoft product does.” That ambiguity creates operational risk if defenders assume safety for non‑attested artifacts.
- Closed artifacts and opaque bundling: Some Microsoft‑published artifacts (or third‑party binaries Microsoft redistributes) may still bundle vulnerable OpenSSL versions without public disclosure. Until those are inspected or attested, customers should retain a posture of “unknown = check me.”
- Human interpretation vs machine attestation: Even with CSAF/VEX available, many customers lack automated pipelines to consume and act on the attestations. The protective value of VEX grows only if organizations integrate machine‑readable attestations into their CI/CD and patch orchestration flows.
Conclusion
CVE‑2023‑6237 is an OpenSSL resource‑exhaustion defect in the EVP_PKEY_public_check() path that was fixed in the 3.x stream of OpenSSL. Distributions and downstream package maintainers have issued updates, and Microsoft has explicitly attested that Azure Linux includes the implicated open‑source library and is therefore potentially affected — a product‑scoped inventory statement that is authoritative for Azure Linux artifacts.However, Microsoft’s attestation is not a universal exclusivity guarantee. Any Microsoft artifact that bundles a vulnerable OpenSSL build could, in principle, be affected until that artifact is inventory‑checked and declared Not Affected or Fixed in MSRC’s CSAF/VEX feed. Organizations must therefore combine three actions: (1) apply the OpenSSL patches (or vendor updates) where available, (2) perform per‑artifact inventory checks for Microsoft and other vendor artifacts, and (3) harden parsing/validation code paths against resource exhaustion by adding input bounds, timeouts, and isolation.
In short: Azure Linux is the Microsoft product Microsoft has confirmed so far; it is not — and should not be read as — definitive proof that no other Microsoft product can contain the vulnerable OpenSSL code. Act on the Azure Linux attestation immediately if you run it, and treat other Microsoft artifacts with caution and verification until they appear in the VEX/CSAF inventory or you have performed an independent package-level inspection.
Source: MSRC Security Update Guide - Microsoft Security Response Center
