Microsoft has confirmed that Azure Linux ships with a vulnerable version of libssh, exposing systems to a memory corruption bug tracked as CVE-2025-5351. The advisory, posted on the Microsoft Security Response Center (MSRC) portal, marks the first public acknowledgment that a Microsoft product is potentially affected by the flaw—but the company’s careful wording leaves the door open to wider impact across its portfolio.
The Vulnerability at a Glance
CVE-2025-5351 is a double-free bug deep inside libssh, the widely used open-source library that implements the SSH protocol for clients and servers. The problem lives in the pki_key_to_blob() function, which converts cryptographic key structures into binary blob formats. If an internal memory allocation fails during the export process—particularly when libssh is built against OpenSSL 3.0 or newer—the error-cleanup code can free the same heap pointer twice. That’s a textbook double-free, and it’s notorious for corrupting heap memory, crashing applications, or, in the hands of a skilled attacker, enabling code execution under the right conditions.
Distributions like Ubuntu, Debian, and Amazon Linux have already documented the flaw and shipped patches. Microsoft’s entry now confirms that Azure Linux, the company’s own lightweight Linux distribution used in containers and cloud workloads, contains the affected library. The advisory doesn’t pull punches: “Azure Linux includes this open-source library and is therefore potentially affected.”
But here’s the nuance that’s tripping up many admins. The statement is an attestation of confirmed impact for one product—not a declaration that everything else is safe. Microsoft says it began publishing machine-readable CSAF/VEX attestations in October 2025, and that if further products are found to carry the vulnerable libssh code, the CVE record will be updated. Until that happens, however, the absence of a product name on the MSRC page means nothing. It’s not proof of safety; it’s just a blank spot in the inventory.
Who Needs to Act Now
The practical impact splits cleanly along use-case lines.
For Azure Linux users: This is a priority patch. Microsoft’s guidance is unambiguous—your images are vulnerable. Apply the official package updates as soon as they’re available. The fix is straightforward in most package-managed environments, but if you’re running immutable container images or heavily customized virtual machines, you’ll need to rebuild and redeploy. Don’t wait.
For administrators of other Microsoft Linux artifacts: This is where the answer gets complicated. If you run Azure Marketplace Linux appliances, Windows Subsystem for Linux (WSL) distributions, or specialized management VMs, you need to verify. Microsoft hasn’t exhaustively scanned every binary it ships, and libssh could be embedded in ways that aren’t obvious—statically linked into an agent binary, vendored in an appliance, or pulled in as a transitive dependency. The only safe assumption is “unverified,” not “unaffected.”
For developers building on libssh: If your CI/CD pipeline pulls in libssh directly—especially if you depend on OpenSSL 3.x—check your dependency manifests. The bug is triggered only in specific error paths (usually under low-memory conditions), so you might not have seen a crash. But stability risks alone justify pulling the fixed version from your distro or upstream.
For home users and casual Windows users: The immediate risk is low, but if you’re experimenting with WSL or running Linux VMs on your machine, it’s worth a quick check. Use your package manager to see if libssh is installed, and update it if a new version is available. The command dpkg -l | grep libssh (on Debian-based systems) or rpm -qa | grep libssh (on Red Hat-based ones) will show you the version. Compare that to your distro’s advisory.
How We Got Here
This story is less about a single bug and more about the messy, ongoing cleanup of software supply chains. libssh is everywhere—it’s the engine behind SFTP transfers, remote management tools, and countless embedded devices. The vulnerability itself was reported through standard disclosure channels, and the upstream fix flowed into distribution patches. So far, so routine.
Microsoft’s involvement, however, highlights an awkward truth about modern cloud platforms. The company started shipping its own Linux distribution—CBL-Mariner, later rebranded Azure Linux—as a container host OS and lightweight VM image. That brought all the maintenance burdens of any Linux distro, including tracking and patching CVEs in thousands of open-source packages. Azure Linux is built from curated tiers of upstream source code, which theoretically allows fast patching, but it also means that when a bug like this hits, Microsoft is on the hook to publicly disclose the impact, coordinate fixes, and manage customer expectations.
The transparency push is real. In October 2025, Microsoft began issuing Common Security Advisory Framework (CSAF) documents and Vulnerability Exploitability eXchange (VEX) statements—machine-readable formats that tell automated tools whether a given CVE affects a specific product. The MSRC entry for CVE-2025-5351 points to that effort and promises updates as more products are inventoried. But the rollout is phased, and many products haven’t been attested yet. So we’re in a transitional period where a single, carefully worded advisory can be misinterpreted as a definitive answer.
How to Protect Your Systems
The single most important step: patch Azure Linux if you use it. Microsoft’s advisory is your green light to pull the fix. For everything else, adopt a “trust but verify” posture. Here’s a practical checklist:
- Inventory your Microsoft Linux exposure. Make a list of all Azure VMs, Marketplace images, container base images, WSL distributions, and third-party appliances that might bundle Microsoft software. If any of them include libssh, flag them for deeper inspection.
- Scan for libssh versions. Use package manager queries, binary checks (
strings <binary> | grep libssh), or Software Bill of Materials (SBOM) tools to discover where libssh lives and which version is running. Pay special attention to anything built against OpenSSL 3.0 or later, as that’s where the double-free is most likely to be triggered. - Apply patches from authoritative sources. Don’t rely on Microsoft to tell you about non-Azure Linux products. Check the advisories of your distribution (if you’re on Ubuntu, go to Ubuntu Security; if you’re on Amazon Linux, check the ALAS). Apply the fixed libssh package as soon as it’s available.
- Mitigate if you can’t patch immediately. The bug is triggered only when you export keys—something that doesn’t happen in many SSH connections. If your services don’t rely on key export functionality, you can reduce risk by disabling or restricting that feature temporarily. Also, harden your services so that crash attempts don’t cause widespread disruption; set up resource limits and monitor for abnormal restarts.
- Monitor Microsoft’s CSAF/VEX feeds. Bookmark the MSRC CVE page for CVE-2025-5351 and watch for expansions to the affected product list. If you use automated vulnerability management tools, configure them to ingest Microsoft’s CSAF documents. That way, if a product you depend on later gets flagged, you’ll know instantly.
- Integrate SBOMs into your CI/CD pipeline. For developers, this is a long-term supply-chain hygiene play. Generate SBOMs for your container images and applications, and require them to be updated with every build. That makes it trivial to search for vulnerable components like libssh after a CVE is published.
The Bigger Picture
CVE-2025-5351 is not the worst vulnerability of the year—it’s primarily a stability bug with limited exploit potential under most configurations. But it’s a bellwether. As giants like Microsoft sink deeper into the open-source ecosystem, they inherit the same transparency obligations that distributions have practiced for decades. The cautious, product-scoped advisory language represents a starting point, not a finish line. Over time, expect Microsoft’s CSAF/VEX coverage to expand, making it easier to answer the question “Does this CVE affect my Microsoft product?” with a quick API call.
For now, Azure Linux users have a clear mandate: patch. Everyone else should resist the temptation to interpret silence as safety. The supply chain is too tangled for that.