A behavior flaw in OpenSSH (CVE-2025-32728) undermines a key security restriction: the DisableForwarding directive may silently allow X11 and agent forwarding, even when administrators explicitly tried to block them. The bug, present in versions from 7.4 through 9.x and fixed in OpenSSH 10.0, has been officially acknowledged by Microsoft only in Azure Linux. Yet the outdated OpenSSH server packages hidden inside Windows, WSL distributions, and custom containers mean far more systems could be exposed.

What the Flaw Actually Breaks

OpenSSH’s DisableForwarding option is supposed to shut down all port, X11, and agent forwarding for matching connections. In practice, before version 10.0, the server could still permit X11 and agent forwarding in certain configurations, making the directive unreliable as a security barrier. The fix, shipped in OpenSSH 10.0 on April 9, 2025, reworks the logic so that DisableForwarding truly blocks those channels.

The National Vulnerability Database and distribution advisories track the issue under CVE-2025-32728, with a CVSS score hovering around 3.8 to 4.3—medium to low. That modest rating reflects the local attack vector and limited confidentiality and integrity impact in many server roles. But for environments that depend on DisableForwarding to contain users on bastion hosts or jump servers, the practical risk can be much higher: a successful agent-forwarding bypass can allow credential theft and lateral movement.

Microsoft’s Advisory: Why Azure Linux and Not Everything Else?

Microsoft’s Security Response Center (MSRC) published a brief note for CVE-2025-32728 stating that “Azure Linux includes this open-source library and is therefore potentially affected.” The advisory also pledges to update the CVE record if other Microsoft products are found to be impacted.

That phrasing, common to many vendor attestations, means Microsoft has completed a focused inventory of Azure Linux and confirmed the vulnerable component’s presence. It does not mean the company has exhaustively scanned every other product it ships. The advisory is a starting point, not a clean bill of health for Windows, WSL, or any other artifact.

The Real Scope: Where OpenSSH Hides in Microsoft’s Ecosystem

Azure Linux may be the only product Microsoft has explicitly named, but OpenSSH appears in many other places that Microsoft customers run every day:

  • Windows itself (client and server): Modern Windows releases include an in-box OpenSSH client and an optional OpenSSH server as a Feature on Demand. The version can lag significantly behind upstream. Many Windows Server installations that enabled the SSH server for remote management may still be running a pre‑10.0 build.
  • Windows Subsystem for Linux (WSL / WSL2): Each WSL distribution is a full Linux userland that may ship or install OpenSSH server packages. Vulnerabilities inside WSL instances carry the same operational weight as those in traditional VMs.
  • Custom and Marketplace images: Any Azure VM or container image—whether from the marketplace, a third party, or built in-house—can bundle OpenSSH. Microsoft’s attestation for Azure Linux does not automatically cover those images.
  • Containers and Kubernetes nodes: If you bring your own container images (BYOI) to AKS or other platforms, you’re responsible for scanning and patching the OpenSSH binaries inside them.

For Windows admins in particular, the in-box OpenSSH server often goes unnoticed. Microsoft’s own documentation describes how to upgrade it, but many organizations never apply those updates until prompted by a CVE.

What You Need to Do Now

1. Find Every OpenSSH Server in Your Environment

Run ssh -V across servers, containers, and WSL distributions to collect version strings. Check package managers (dpkg -l openssh-server, rpm -q openssh-server, Get-WindowsCapability -Online | ? Name -like 'OpenSSH.Server*') to see what’s installed. Don’t forget CI/CD workers, gold images, and any bastion hosts that serve as entry points.

2. Apply Hardening Configuration Immediately

Even before an upgrade, you can close the gap with explicit directives in sshd_config:

X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

These statements take precedence and enforce the block regardless of any lingering DisableForwarding bug. Roll them out now—especially on bastion hosts and sensitive accounts.

3. Upgrade to OpenSSH 10.0 or Later

  • Linux: Pull the latest package from your distribution’s repositories once they contain the 10.0+ fix, or compile from source.
  • Windows: Check Windows Update for an updated in-box package. If none is available yet, install the official Win32-OpenSSH build from GitHub, following Microsoft’s upgrade guidance.
  • Containers: Rebuild images with a patched OpenSSH and promote them through your deployment pipelines.

4. Rebuild and Redeploy Where Necessary

Vendored code doesn’t patch itself. If your build process pins a specific OpenSSH version or includes it in a static binary, you must rebuild the artifact after updating the dependency. Immutable images that still contain the old sshd binary remain vulnerable.

5. Turn On Monitoring and Logging

Configure logging on bastion hosts to capture forwarding channel negotiations. Set up alerts for unexpected agent‑forwarding requests—especially from service accounts that shouldn’t need it. This gives you visibility while you complete patching and serves as a long‑term safety net.

Why Layered Controls Matter

This bug is a textbook illustration of why no single configuration directive should be the only line of defense. DisableForwarding was meant to be a convenient umbrella, but the implementation didn’t match the documentation. By pairing it with explicit no settings—and by treating forwarding as a privilege that should be granted only to specific hosts and users—you reduce the blast radius of future bugs.

Outlook

Microsoft’s advisory is the first official word, not the last. As the company’s CSAF/VEX attestation program expands, we can expect automated, machine‑readable updates for more products. In the meantime, treat CVE‑2025‑32728 as a supply‑chain issue that requires your own discovery and remediation. OpenSSH 10.0 is the definitive fix, and getting there should be the top priority for any SSH‑enabled Windows, Linux, or WSL host.