Microsoft’s short advisory language — that “Azure Linux includes this open‑source library and is therefore potentially affected” — is an accurate, product‑scoped attestation, but it is not a categorical statement that Azure Linux is the only Microsoft product that could ever contain the vulnerable libssh code. view
In late June and July 2025 a vulnerability was assigned CVE‑2025‑5987 and tracked across vendor databases: a mismatch in return‑code semantics between OpenSSL and libssh caused libssh to sometimes treat OpenSSL’s error return (rv == 0) as the libssh success code (SSH_OK == 0). The practical outcome is that, under conditions such as heap exhaustion during ChaCha20 initialization, libssh could proceed with a partially initialized cipher context, producing undefined behavior that may affect confidentiality, integrity, or availability. The issue is specifically observable when the ChaCha20‑Poly1305 cipher is used with libssh built against an OpenSSL backend.
Upstream libssh released a security update (libssh 0.11.2) that lists CVE‑2025‑5987 among the fixed issues; downstream distributors (Ubuntu, Amazon Linux, Red Hat, SUSE, Rocky, etc.) have produced advisories and patched packages.
Microsoft’s public statement — the short line quoted above — is visible in MSRC product‑mapping language and reflects the new, scoped way Microsoft is publishing attestations for Azure Linux and selected product artifacts. Microsoft has also said it will update CVE entries if additional products are found to contain the implicated library. That declarative, inventory‑scoped wording is intentional: it tells Azure Linux customers that their images are in‑scope for mitigation while leaving open the possibility ttifacts might later be identified.
Microsoft’s phrasing accomplishes two things concisely:
Microsoft has publicly attested that Azure Linux includes the vulnerable open‑source library and should be considered potentially affected. That is an important, actionable fact: Azure Linux images are confirmed in‑scope and should be patched. However, the absence of additional product attestations does not equal the absence of risk elsewhere in Microsoft’s footprint. The vendor explicitly stated itrecord if impact to additional products is identified; until then, other Microsoft artifacts remain unattested rather than proven safe.
Why this distinction matters operationally:
For defenders, the correct operational posture is straightforward:
Conclusion: Azure Linux is the one Microsoft product Microsoft has publicly attested so far as containing the vulnerable libssh component — and that matters — but it is not the only place to look. Your remediation plan should treat Azure Linux as the top priority and then expand to artifact‑level discovery across the rest of your Microsoft‑consumed images and binaries.
Source: MSRC Security Update Guide - Microsoft Security Response Center
In late June and July 2025 a vulnerability was assigned CVE‑2025‑5987 and tracked across vendor databases: a mismatch in return‑code semantics between OpenSSL and libssh caused libssh to sometimes treat OpenSSL’s error return (rv == 0) as the libssh success code (SSH_OK == 0). The practical outcome is that, under conditions such as heap exhaustion during ChaCha20 initialization, libssh could proceed with a partially initialized cipher context, producing undefined behavior that may affect confidentiality, integrity, or availability. The issue is specifically observable when the ChaCha20‑Poly1305 cipher is used with libssh built against an OpenSSL backend.
Upstream libssh released a security update (libssh 0.11.2) that lists CVE‑2025‑5987 among the fixed issues; downstream distributors (Ubuntu, Amazon Linux, Red Hat, SUSE, Rocky, etc.) have produced advisories and patched packages.
Microsoft’s public statement — the short line quoted above — is visible in MSRC product‑mapping language and reflects the new, scoped way Microsoft is publishing attestations for Azure Linux and selected product artifacts. Microsoft has also said it will update CVE entries if additional products are found to contain the implicated library. That declarative, inventory‑scoped wording is intentional: it tells Azure Linux customers that their images are in‑scope for mitigation while leaving open the possibility ttifacts might later be identified.
What the MSRC sentence actually means — and what it doesn’t
Microsoft’s phrasing accomplishes two things concisely:- It tells customers that a Microsoft‑maintained product — Azure Linux — contains the vulnerable upstream component and therefore needs the vendor’s patching cadence and follow‑up.
- It sets a conservative boundary for the advisory: Microsoft will expand the mapping if its internal inventories find the same upstream component in other products.
- It does not mean Azure Linux is the exclusive place where libssh appears across Microsoft’s entire product portfolio.
- It does not guarantee that every other Microsoft image, binary, Marketplace VM image, agent, SDK, or container has been scanned and declared safe or unaffected.
- It does not absolve customers or integrators from doing artifact‑level discovery in their own environments if they consume Microsoft artifacts (images, containers, VM templates, binaries, agents).
Technical recap: what CVE‑2025‑5987 is — short and verifiable
- The bug is a return‑code mismatch between OpenSSL and libssh during ChaCha20‑Poly1305 key/cipher initialization. When OpenSSL returns an error code that happens to equal zero in the upstream API, libssh’s wrapper interprets it as SSH_OK and proceeds. This can leave the cipher context only partially initialized. The result is undefined behavior that can be exploited indirectly (confidentiality/integrity impact or crashes), especially under memory/heap exhaustion conditions.
- Upstream remediation: libssh published a security release (0.11.2) that explicitly lists this issue as fixed. Distributors and package maintainers followed with patched packages.
- Practical mitigations until a patch is applied:
- Upgrade libssh to a patched version (0.11.2 or later where the fix is present).
- If you cannot upgrade immediately, consider disabling the chacha20‑poly1305@openssh.com cipher when libssh is built against the OpenSSL backend, or avoid using that cipher suite in affected deployments.
Is Azure Linux the only Microsoft product that includes libssh?
Short answer: No — not necessarily, and the published MSRC wording does not claim exclusivity.Microsoft has publicly attested that Azure Linux includes the vulnerable open‑source library and should be considered potentially affected. That is an important, actionable fact: Azure Linux images are confirmed in‑scope and should be patched. However, the absence of additional product attestations does not equal the absence of risk elsewhere in Microsoft’s footprint. The vendor explicitly stated itrecord if impact to additional products is identified; until then, other Microsoft artifacts remain unattested rather than proven safe.
Why this distinction matters operationally:
- Microsoft ships a very large and varied set of artifacts: cloud VM images, Marketplace images, container base images, telemetry/agent binaries, SDKs, developer tools and libraries (including vcpkg), and cross‑platform components. Any of those artifacts can — and historically have — embedded third‑party libraries indirectly or directly.
- A vulnerable library in one product (a distro image) can appear unchanged in other places: a Marketplace VM image, a partner appliance image, a container derived from the distro, or a vendor binary built and packaged with the library statically linked.
Where else libssh can appear inside Microsoft ecosystems (practical examples)
Use these as a checklist for discovery — these artifact classes are common carriers for third‑party libraries:- Azure Marketplace VM images and publisher images that are derived from or include Azure Linux (or other Linux distributions) can carry the same distro packages or static binaries.
- Container base images published by Microsoft (or by partners that used Microsoft‑published bases) may include libssh in their package lists.
- Developer tooling and package ecosystems: Microsoft’s vcpkg supports libssh builds for Windows, which means Windows developer builds or third‑party Windows apps built with vcpkg could host libssh as a dependency.
- WSL / WSL2 distributions and kernel/userland artifacts that were built from or packaged with the affected libssh versions.
- Microsoft‑published SDKs, agents, or CLI tools that vendor or statically link libssh (less common, but possible where projects include native libs).
- Partner or ISV images made available through Microsoft channels that include Linux packages.
Practical detection and triage steps (prioritized for operators)
Below is a practical playbook you can apply across estates (cloud images, on‑prem VMs, containers, build artifacts, and developer machines).- Inventory and prioritize
- Identify all systems that run Microsoft‑published Linux images (Azure Linux, Marketplace images), containers derived from Microsoft bases, or Microsoft‑distributed binaries (agents, SDKs).
- Prioritize network‑facing and high‑value assets where SSH is in use (jump hosts, bastions, admin tools, automation agents).
- Detect libssh presence and version
- On package‑managed systems:
- Debian/Ubuntu: dpkg -l | grep libssh
- RHEL/Fedora/CentOS/Amazon Linux: rpm -qa | grep libssh
- For installed binaries: ldd /path/to/binary | grep libssh (dynamic linking).
- For statically‑linked programs, inspect build metadata, SBOMs, or reproduce the build to confirm the linked libs.
- Container images: run image scans (Trivy, Clair, distro package queries) or run a quick container shell and query the package database (e.g., docker run --rm image dpkg -l | grep libssh).
- Verify backend and cipher usage
- Not all libssh builds use OpenSSL as the backend — the vulnerability is specific to ChaCha20 with the OpenSSL backend. Confirm whether the affected package/binary was built with OpenSSL or another crypto backend.
- Check application configuration for enabled ciphers; temporarily disabling chacha20‑poly1305 is an acceptable compensating control if you cannot patch immediately.
- Patch and rebuild
- Apply distro patches where available; upgrade libssh to the fixed package versions (upstream libssh 0.11.2 or later).
- For statically built or vendored binaries, rebuild with the patched libssh or replace the binary with an updated vendor build.
- For container images, update base images and rebuild images; redeploy through CI/CD pipelines.
- Compensating controls and monitoring
- Disable the ChaCha20‑Poly1305 cipher in libssh configuration if patching is delayed.
- Restrict access to SSH‑providing services from untrusted networks; implement network ACLs and host hardening.
- Monitor for anomalous SSH behavior and crashes; watch telemetry for processes using libssh that show unexpected termination or panic behavior.
- Record and communicate
- Update inventories, SBOMs, and incident trackon steps and timelines.
- If you consume Microsoft artifacts, track MSRC/VEX/CSAF attestations for updates — Microsoft has committed to updating CVE mappings when other products are discovered affected.
Technical hard facts I verified (sources cross‑checked)
- libssh upstream lists CVE‑2025‑5987 and includes it in the 0.11.2 security release notes (libssh 0.11.2 security and bugfix release). This confirms upstream acknowledgement and the release that carries the fix.
- NVD tracks CVE‑2025‑5987 and summarizes the return‑code/heap exhaustion behavior that leads to a partially initialized cipher context. This gives an independent registry corroborating the vulnerability description.
- Multiple distributors and security trackers (Ubuntu, Amazon Linux, Red Hat/SUSE/rocky advisories) published advisories and package updates mapping the CVE to package fixes for their platforms; these show the practical, cross‑ecosystem remediation activity. ([ubuntu.com](https://ubuntu.com/security/CVE-2025-5987?utm_sourc’s MSRC wording that “Azure Linux includes this open‑source library and is therefore potentially affected” is an inventory attestation and is explicitly phrased as such; Microsoft also states it will update the CVE as further impact is discovered. This is Microsoft’s public posture and the central line that spawned this question.
Risk analysis: strengths and limitations of Microsoft’s approach
Strengths- Clarity for Azure Linux customers. Microsoft’s explicit attestation lets defenders who rely on Azure Linux act quickly and confidently: the image is in‑scope and should be patched according to Microsoft’s guidance.
- Machine‑readable intent. Microsoft’s move toward machine‑readable VEX/CSAF attestations helps automation and rapid triage across large fleets; customers and security vendors can use these attestations to suppress false positives and focus remediation where it matters most.
- Commitment to update. Microsoft’s public commitment to update mappings if additional products are found to carry the component is a valuable operating promise.
- Attestation is not exhaustive. Microsoft’s language is scoped and conservative by design; it does not assert the absence of the vulnerable component in other Microsoft artifacts. That leaves a practical discovery burden for customers that ingest Microsoft‑published images, containers, or third‑party bundled artifacts.
- Third‑party packaging variability. The same libssh code can appear in many forms: distro packages, vendored static libraries, or embedded within a binary. Automated detection may miss statically linked or vendor‑embedded cases without SBOMs or build records.
- Timing and cadence mismatch. MSRC attestations may lag internal discovery; the promise to update is good, but organizations cannot rely on vendor attestations alone for immediate certainty across all artifacts they run.
- Operational friction for rebuilds. For staticaleated binaries, the remediation path is often “rebuild and redeploy” — a disruptive task that requires CI changes and testing, not just a package update on the host.
Recommendations for Microsoft customers and integrators
- Treat the MSRC attestation as the official in‑scope statement for Azure Linux and patch Azure Linux images immediately if you consume those images. That is the highest‑priority remedial action because it’s an authoritative vendor mapping.
- Simultaneously run an artifact‑level discovery sweep across:
- Marketplace VM images you run.
- Containers pulled from Microsoft or partner registries.
- VMs or appliances that may have been built from Microsoft images.
- Build artifacts and CI outputs that use Microsoft tools (vcpkg, Azure pipelines) and might have produced binaries that include libssh.
- Use SBOMs (generated and stored in CI/CD pipelines) to detect vendored or statically linked copies of libssh. For legacy binaries where SBOMs are missing, rely on binary inspection (strings, ldd, go version -m for Go, or build logs) to determine the library provenance.
- Apply compensating controls if immediate rebuild/upgrade is impractical:
- Disable ChaCha20‑Poly1305 for applications using an OpenSSL backend where feasible.
- Harden network exposure (restrict SSH to management networks).
- Add monitoring for process crashes or unexpected behavior in SSH‑dependent services.
- Track VEX/CSAF attestations from Microsoft and other vendors; incorporate them into your vulnerability management automation but do not treat them as a substitute for local runtime checks.
Final assessment and takeaways
Microsoft’s public language that “Azure Linux includes this open‑source library and is therefore potentially affected” is precise and correct — it tells Azure Linux users to treat their images as in‑scope and to apply updates. But it is not an exclusivity claim: other Microsoft artifacts could contain libssh, and the lack of a public Microsoft attestation for a product does not prove the component is absent from that product.For defenders, the correct operational posture is straightforward:
- Patch Azure Linux immediately (first, because MSRC says it is in‑scope).
- Run artifact‑level discovery across all Microsoft‑supplied images and binaries you consume.
- Treat Microsoft’s attestation as the canonical starting point for automation (VEX/CSAF), but validate locally with SBOMs, package queries, and binary inspection.
Conclusion: Azure Linux is the one Microsoft product Microsoft has publicly attested so far as containing the vulnerable libssh component — and that matters — but it is not the only place to look. Your remediation plan should treat Azure Linux as the top priority and then expand to artifact‑level discovery across the rest of your Microsoft‑consumed images and binaries.
Source: MSRC Security Update Guide - Microsoft Security Response Center
