Microsoft has publicly confirmed that its Azure Linux distribution is affected by a recently disclosed vulnerability in the libssh library, which could allow attackers to compromise the confidentiality and integrity of SSH connections. The advisory, published on the Microsoft Security Response Center (MSRC), marks the first official acknowledgment that the open-source component at the heart of CVE-2025-5987 is present in a Microsoft-maintained product. While the advisory provides clear guidance for Azure Linux users, it also raises important questions for organizations that consume a wide range of Microsoft-supplied artifacts—from virtual machine images to developer tools.

The Vulnerability at a Glance

CVE-2025-5987 stems from a subtle mismatch in how libssh and OpenSSL handle error codes during the initialization of the ChaCha20-Poly1305 cipher. Under normal conditions, libssh relies on OpenSSL’s return value to determine whether a cryptographic context was set up correctly. But when the system is under memory pressure—specifically, when heap space is exhausted—OpenSSL returns an error code that happens to align with the value libssh uses to indicate success (SSH_OK, which is zero). As a result, libssh proceeds with a cipher context that may be only partially initialized, leading to undefined behavior.

According to Ubuntu’s security advisory, this flaw “can lead to undefined behavior, including compromised data confidentiality and integrity or crashes.” The bug affects libssh when built against an OpenSSL backend and when the ChaCha20-Poly1305 cipher is negotiated. Attackers who can trigger heap exhaustion (for example, by sending crafted traffic or exploiting a memory leak) might exploit the vulnerability to decrypt communications or crash the SSH service.

The upstream libssh project addressed the issue in version 0.11.2, released in late June 2025. Since then, major Linux distributors—including Ubuntu, Red Hat, SUSE, and Amazon Linux—have shipped patched packages. Microsoft’s advisory for Azure Linux follows that same pattern, telling customers that their images are in scope and should be updated.

What Microsoft’s Advisory Actually Says

The MSRC entry for CVE-2025-5987 contains a short, deliberate statement: “Azure Linux includes this open-source library and is therefore potentially affected.” That phrasing is part of Microsoft’s newer, scoped approach to vulnerability disclosures, designed to give machine-readable attestations (like VEX and CSAF documents) that precisely map a CVE to a specific product. It is not a blanket assurance that no other Microsoft product carries the vulnerable code.

In practice, this means:
- Azure Linux images are confirmed to contain the affected libssh version. Administrators should prioritize patching those systems.
- Microsoft has committed to updating the advisory if additional products are discovered to include the same library. Until then, other products remain unattested—neither confirmed affected nor confirmed safe.

For security teams, the advisory is a starting point, not a complete picture. The company ships a vast and diverse set of artifacts: cloud VM images, Marketplace offerings, container base images, WSL distributions, vcpkg packages, SDKs, and more. Any of these could embed libssh either dynamically or statically, even if no advisory has been published yet.

Where Else libssh Might Lurk in Microsoft Ecosystems

Based on how Microsoft and its partners distribute software, libssh could appear in several places beyond Azure Linux. A practical inventory should cover:

  • Azure Marketplace VM images: Publishers often base their images on Azure Linux or other distributions that include libssh. A virtual appliance might ship the library without explicit notice.
  • Container base images: Microsoft’s own container registries, as well as partner images built from Microsoft bases, may inherit libssh from the underlying distribution.
  • Developer toolchains: Microsoft’s vcpkg package manager offers libssh builds for Windows. Applications compiled with vcpkg could statically link a vulnerable libssh version.
  • WSL and WSL2 distributions: The userland components of Windows Subsystem for Linux may include libssh, especially if they are built from standard distribution packages.
  • Agents, SDKs, and CLI tools: While less common, some Microsoft-supplied binaries that handle SSH connections (e.g., Azure CLI extensions, DevOps agents) might bundle libssh.

The absence of an MSRC advisory for a specific product should not be interpreted as proof of safety. As the company itself notes, the mapping is updated only when internal inventories confirm the presence of the vulnerable component.

How We Got Here

The journey from code quirk to CVE followed a typical open-source vulnerability lifecycle. libssh is a widely used library that implements the SSH2 protocol; it is embedded in countless applications and operating systems. For years, its integration with OpenSSL’s ChaCha20-Poly1305 cipher worked correctly—until edge cases around memory exhaustion were examined.

When the bug was discovered and reported, upstream maintainers quickly issued a fix. The 0.11.2 release notes explicitly list CVE-2025-5987 as resolved. Distributors then rebuilt and published updated packages. Microsoft, which uses Azure Linux as the foundation for several of its cloud and edge products, followed with its own scoped advisory in July 2025.

This pattern—a cross-ecosystem ripple of patches—is becoming routine, but it underscores a persistent challenge: the same open-source code can surface in dozens of products from a single vendor, and each product requires a separate attestation.

What to Do Now: A Practical Checklist

The immediate priority is patching systems that are known to be affected. Beyond that, perform a broader discovery sweep to find any overlooked instances of libssh. Here are concrete steps for different environments.

For Azure Linux Users

  1. Update the libssh package to the version provided by your distribution’s patch. On Azure Linux, run:
    bash sudo apt update && sudo apt upgrade libssh
    Or use the equivalent dnf or yum command on RPM-based derivatives.
  2. Verify the installed version:
    bash dpkg -l | grep libssh # Debian-based rpm -qa | grep libssh # RPM-based
    The patched version will be at least 0.11.2 or a release that backports the fix (e.g., Ubuntu’s packages carry the CVE identifier in the changelog).

For All Other Systems

  1. Inventory: Identify all systems running Linux that originated from Microsoft images (Azure Marketplace, custom VMs, WSL). Include containers pulled from Microsoft Container Registry or any image based on a Microsoft-distributed base.
  2. Detect libssh presence:
    - For dynamic linking: ldd /path/to/binary | grep libssh
    - For packages: dpkg -l | grep libssh (Debian/Ubuntu), rpm -qa | grep libssh (RHEL/Fedora)
    - For containers: Run a shell inside the container and query the package database, or use a scanner like Trivy or Clair.
  3. Check the crypto backend: The vulnerability requires an OpenSSL backend. Confirm with:
    bash ssh -V 2>&1 | grep OpenSSL # if SSH client shows backend ldd /path/to/libssh.so | grep libcrypto # shows OpenSSL linkage
    If libssh is linked against a different crypto library (e.g., libgcrypt), the bug does not apply.
  4. Patch or mitigate:
    - Where possible, apply vendor patches. Rebuild any statically linked binaries with the updated libssh.
    - If a patch isn’t immediately available, disable the ChaCha20-Poly1305 cipher in your SSH configuration. For OpenSSH, edit sshd_config and ssh_config to remove [email protected] from the list of accepted ciphers.
    - Restrict SSH access to trusted network segments and monitor for abnormal process behavior or crashes.
  5. Monitor Microsoft’s advisory: The MSRC page for CVE-2025-5987 is the authoritative source for updated product mappings. Check it periodically, and subscribe to security notifications if you manage a large fleet.

For Development Teams

  • Review CI/CD pipelines that use vcpkg or similar package managers. Scan build artifacts for libssh dependency, especially in Windows applications that include SSH clients or servers.
  • Generate and store Software Bills of Materials (SBOMs) to simplify future vulnerability tracking. Tools like Syft or build-time integration can automate this.

Outlook

Microsoft’s handling of CVE-2025-5987 illustrates both the strengths and the limitations of modern vulnerability disclosure. The Azure Linux attestation is clear and actionable, but the broader ecosystem demands that customers maintain their own artifact discovery processes. As open-source components continue to proliferate, vendor advisories will increasingly rely on machine-readable formats, making automation essential. For now, the best defense is a thorough inventory and a swift patch cycle—starting with Azure Linux and extending to every Microsoft-derived image and binary in your infrastructure.