OpenSSH’s behavior bug tracked as CVE‑2025‑32728 — where sshd’s DisableForwarding directive failed to reliably disable X11 and agent forwarding in releases prior to OpenSSH 10.0 — is real, fixed upstream, and important to treat as a supply‑chain and configuration risk rather than a single‑product problem.
OpenSSH 10.0 (released April 9, 2025) contains a security fix that explicitly corrects the way sshd honors the DisableForwarding option; prior OpenSSH releases (from 7.4 up through the 9.x line) could leave agent forwarding and X11 forwarding usable in certain configurations even when administrators relied on DisableForwarding to block those channels. The upstream release notes and multiple CVE records document the change and identify the affected version range.
When Microsoft’s Security Response Center (MSRC) or other vendors publish a short product‑level statement — for example, “Azure Linux includes this open‑source library and is therefore potentially affected” — they are communicating the result of a scoped inventory for a specific product artifact. That language means Microsoft has confirmed the component exists in its Azure Linux builds and is therefore in scope for remediation, and that Microsoft will update the CVE/product mapping if it finds additional product artefacts that include the same upstream code. It is not, however, a categorical statement that no other Microsoft product could contain the vulnerable OpenSSH code.
This distinction — attestation of presence vs exclusivity — is the key to answering the question administrators and security teams face: Is Azure Linux the only Microsoft product that includes OpenSSH and therefore potentially affected? The short technical answer is: No, Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the vulnerable component, but it is not the only Microsoft product that could include OpenSSH and therefore could be affected in practice. Evidence and practical guidance follow.
Administrators and security teams should therefore treat MSRC’s Azure Linux attestation as the start of a focused response: immediately inventory all places you run or ship OpenSSH, apply short‑term config mitigations, upgrade to OpenSSH 10.0+ where possible, rebuild images that vendor the old code, and implement SBOM and runtime detection to prevent recurrence. Microsoft’s move to publish CSAF/VEX attestations improves transparency, but it does not remove the need for local discovery and rapid remediation.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
OpenSSH 10.0 (released April 9, 2025) contains a security fix that explicitly corrects the way sshd honors the DisableForwarding option; prior OpenSSH releases (from 7.4 up through the 9.x line) could leave agent forwarding and X11 forwarding usable in certain configurations even when administrators relied on DisableForwarding to block those channels. The upstream release notes and multiple CVE records document the change and identify the affected version range.When Microsoft’s Security Response Center (MSRC) or other vendors publish a short product‑level statement — for example, “Azure Linux includes this open‑source library and is therefore potentially affected” — they are communicating the result of a scoped inventory for a specific product artifact. That language means Microsoft has confirmed the component exists in its Azure Linux builds and is therefore in scope for remediation, and that Microsoft will update the CVE/product mapping if it finds additional product artefacts that include the same upstream code. It is not, however, a categorical statement that no other Microsoft product could contain the vulnerable OpenSSH code.
This distinction — attestation of presence vs exclusivity — is the key to answering the question administrators and security teams face: Is Azure Linux the only Microsoft product that includes OpenSSH and therefore potentially affected? The short technical answer is: No, Azure Linux is the only Microsoft product Microsoft has publicly attested (so far) to include the vulnerable component, but it is not the only Microsoft product that could include OpenSSH and therefore could be affected in practice. Evidence and practical guidance follow.
Why Microsoft names Azure Linux (and what that naming actually means)
Product‑scoped inventory is how vendors manage complex footprints
Large vendors ship thousands of artifacts — VM images, managed node images, container base images, Windows components, WSL kernels, Marketplace images, and more. To avoid incorrect or premature statements, vendor security teams commonly publish product‑level attestations only after completing an internal inventory or automated SBOM/scan for the artifact in question. Microsoft’s public wording that “Azure Linux includes this open‑source library and is therefore potentially affected” reflects that workflow: inventory completed for Azure Linux, attestation published, and an explicit promise to update the CVE mapping if additional products are discovered to ship the same code.Attestation ≠ exclusivity
The mere absence of a public attestation for another Microsoft product does not prove that product is free of the vulnerable code. It simply means that Microsoft either has not yet completed a separate inventory for that product, or that the inventory shows the product does not contain the component. This is a practical, not a cryptographic, distinction: the vulnerable behavior exists in upstream OpenSSH releases and can be present wherever those releases (or downstream builds carrying the same code) are shipped. Security teams should therefore treat the MSRC attestation as a starting point for focused response, not as definitive proof of a universal safe state across all Microsoft artifacts.Where OpenSSH typically shows up inside Microsoft environments (and why that matters)
OpenSSH is not limited to a single Linux distribution; it appears in many places across modern IT environments. For Microsoft customers, the common places to check include:- Azure Linux images: Microsoft‑maintained Linux distributions and node images in Azure (the product Microsoft explicitly attested for several CVEs). If you run Azure Linux VMs or nodepools, treat those images as in scope.
- Windows (client and server): Modern Windows releases include an in‑box OpenSSH client and an optional OpenSSH server as a supported Feature on Demand; Microsoft documents how to install, configure, and upgrade these components. Many Windows installations therefore ship an OpenSSH binary and configuration that could be older than upstream. Administrators should check the in‑box OpenSSH version and consider upgrading the in‑box package or installing the newer Win32‑OpenSSH build if needed.
- Windows Subsystem for Linux (WSL / WSL2): WSL distributions are user‑chosen Linux images that may include OpenSSH packages. WSL is a host for a Linux userland; vulnerabilities in OpenSSH inside WSL containers are the same operational risk as in any Linux distro running on a VM.
- Azure Marketplace and custom VM/Marketplace images: Marketplace images or any custom images built by teams can contain OpenSSH packages. Microsoft’s attestation of Azure Linux does not automatically cover Marketplace images built by third parties or images built by you and deployed into Azure.
- Containers, containers in AKS, and CI artifacts: OpenSSH can be installed or vendored into container base images. If you bring your own images (BYOI), you are responsible for scanning and patching them.
- Other Microsoft artifacts: Microsoft publishes many kernel builds, SDK artifacts, and service images. Any of these could include OpenSSH binaries or libraries depending on packaging and build choices — until Microsoft inventories and publishes VEX/CSAF attestations for them, absence of a statement is not proof of absence.
Technical reality: what CVE‑2025‑32728 actually allows and how severe it is
- The defect is an expected behavior violation (CWE‑440): DisableForwarding’s implementation did not consistently enforce the documented effect of disabling X11 and agent forwarding in sshd prior to OpenSSH 10.0. That allowed certain forwarding channels to remain usable under specific configs. Multiple public trackers (NVD, distribution advisories) and the OpenSSH 10.0 release notes document the fix.
- The vulnerability’s exploitability is typically local (depends on how users authenticate and how jump hosts/bastions are configured) rather than a straightforward unauthenticated remote compromise. However, in bastion or shared jump host scenarios the ability to bypass forwarding restrictions materially increases the risk of credential theft and lateral movement (for example, SSH agent forwarding abuse). Public trackers assigned a medium‑low CVSS range (around 3.8–4.3) reflecting local vector and limited confidentiality/integrity impact in many typical server configurations.
- The practical risk is highest where administrators rely on DisableForwarding to contain sensitive accounts (bastions, restricted jump accounts, or automation accounts). If those configurations were expected to eliminate forwarding channels, the bug undermines that expectation and requires compensating controls immediately.
Is Azure Linux the only Microsoft product that could be affected? The long answer, with proof points
- Microsoft has publicly attested that Azure Linux includes the affected upstream OpenSSH component and therefore is potentially affected. That attestation is authoritative for the product while Microsoft completes inventories for other product families.
- Microsoft also ships or supports OpenSSH components in Windows (in‑box Feature on Demand packages) and documents how administrators should upgrade or replace in‑box OpenSSH with newer GitHub releases. Because Windows installations may carry older in‑box OpenSSH versions, they are a plausible place to find the same pre‑10.0 behavior — particularly on systems where the in‑box version lags upstream. Administrators should not assume Windows hosts are immune simply because MSRC named Azure Linux.
- WSL, custom Azure Marketplace images, containers, and other artifacts can and do contain OpenSSH packages. A product‑scoped MSRC attestation does not retroactively scan every possible image or container running on Azure or in a customer estate. Treat the MSRC attestation as a confirmed hit for Azure Linux and a pointer to perform wider discovery.
Recommended immediate actions for administrators and DevOps teams
Follow this sequence to assess, mitigate, and remediate risk from CVE‑2025‑32728 in Microsoft environments.1. Inventory and discovery (minutes to hours)
- Run package scans across VMs, containers, and images for OpenSSH versions. Search for sshd binary builds and check
ssh -Vor package metadata. - Inspect Windows hosts for in‑box OpenSSH:
ssh -Von supported Windows releases and compare with upstream OpenSSH 10.0+ requirement. Microsoft documents upgrading the in‑box OpenSSH and installing newer Win32‑OpenSSH builds. - Scan WSL distributions and container images in registries for OpenSSH packages.
- Query SBOMs (if available) and CI pipelines for upstream OpenSSH pins or vendored source.
2. Short‑term mitigations (hours)
- Where you rely on DisableForwarding to enforce policy, apply explicit, per‑server configuration to explicitly set:
- X11Forwarding no
- AllowAgentForwarding no
- AllowTcpForwarding no
These explicit directives help mitigate the mismatch until you can upgrade the server binary or platform package. - Limit access to bastion/jump hosts. If feasible, disable agent forwarding client‑side for sensitive accounts and require use of per‑host keys rather than agent forwarding.
- For Windows OpenSSH installations, ensure the in‑box version is reviewed and consider upgrading to the supported GitHub/Win32‑OpenSSH binaries if the in‑box build predates the OpenSSH 10.0 fix. Microsoft documents the upgrade procedures.
3. Patch and rebuild (days)
- Upgrade OpenSSH to 10.0 or later where possible on Linux and rebuild/redeploy any images that contain older OpenSSH binaries.
- For Windows, either update the in‑box OpenSSH package via Windows Update (if Microsoft has shipped a post‑10.0 update for your release) or install the newer Win32‑OpenSSH package from the supported GitHub releases and follow Microsoft’s guidance on safely upgrading.
- Rebuild and redeploy container images (AKS, ACI, custom images) that include OpenSSH so the vulnerable module is not left vendored in immutable images.
4. Verify and test (days)
- After upgrading, run tests to confirm forwarding channels are blocked when DisableForwarding is set and when the explicit no options are applied. Test agent forwarding (
ssh -A) and X11 forwarding (ssh -X) against accounts with Match/DisableForwarding rules. - Validate Windows hosts by running
ssh -Vand confirming behavior changes on the upgraded OpenSSH server.
5. Supply‑chain hygiene and detection (weeks)
- Enforce SBOM generation, dependency scanning, and pinned dependency policies so future upstream fixes are visible inside your CI/CD pipelines.
- Add runtime detection: alert on unexpected forwarding behavior from bastion and jump hosts, and log usage of agent/X11 channels. Confirm your logging captures forwarding channel negotiations to detect bypass attempts.
Special guidance for Azure customers
- If you run Azure Linux images (Microsoft‑maintained), Microsoft’s attestation means Microsoft has confirmed Azure Linux contains the affected OpenSSH build; apply the Azure Linux image updates Microsoft publishes or patch the package inside the VM as directed. Keep an eye on Microsoft’s CVE page and the CSAF/VEX feeds for machine‑readable updates from Microsoft.
- If you run BYOI (bring your own images) in Azure (containers, VM images, AKS nodepools built from custom images), you remain responsible for scanning and patching those images. Do not rely on Microsoft’s Azure Linux attestation to cover your custom artifacts.
- For managed services (PaaS) where OpenSSH is not typically exposed at the service layer, check whether any underlying node images or custom tooling include OpenSSH. The managed service may not be affected if it does not expose SSH services or include the vulnerable component; but verify via SBOMs or service documentation.
Why vendor attestations matter — and why independent discovery still matters more
Vendor attestations like Microsoft’s Azure Linux statement are useful and should be read as authoritative for the product they name. They show that the vendor has completed an internal inventory and publicly published machine‑readable VEX/CSAF metadata (Microsoft began that program publicly in October 2025). However:- Attestations are phased: they seldom cover every product at the moment a CVE is published. Microsoft explicitly states it will update CVE pages if additional products are identified as impacted.
- The responsibility to detect vulnerable components running in your tenancy, on your endpoints, or inside your containers rests with you. Attestations narrow the initial scope for responders but do not replace local discovery, scanning, and incident response.
- OpenSSH is shipped and packaged in many downstream artifacts. When a configuration like DisableForwarding is relied upon for security, a correctness bug in the implementation significantly increases the need for layered controls: explicit directives, restricted access, monitoring, and quick patch windows.
Critical analysis: strengths, gaps, and residual risk
Strengths
- Upstream response was clear: OpenSSH 10.0 fixed the logic for DisableForwarding; the change is published in release notes. Administrators can therefore fix the problem by upgrading to 10.0+.
- Microsoft’s transparency about Azure Linux and its CSAF/VEX rollout is a positive step toward machine‑readable vulnerability attestation across large product portfolios. That helps enterprise automation and vulnerability response.
Gaps and risks
- Vendor attestations are necessarily incremental. Until Microsoft completes inventories for other product families, some artifacts (WSL kernels, custom Marketplace images, in‑box Windows OpenSSH versions) could still carry the pre‑10.0 behavior.
- Many teams depend on configuration semantics (e.g., “DisableForwarding disables all forwarding”) as a security boundary. When implementation drifts from documentation, those teams are left exposed until they either apply patches or add defensive configuration and architectural controls.
- Rebuilds matter: Go modules, vendored libraries, or static binary builds may continue to include vulnerable code until rebuild/redeploy cycles complete. Simply updating a package repo without rebuilding and redeploying images or artifacts can leave the vulnerable code in place.
Practical checklist (one‑page, action‑oriented)
- Inventory: Find all sshd binaries and OpenSSH packages in servers, containers, WSL, and Windows hosts.
- Short mitigation: Add explicit X11Forwarding no, AllowAgentForwarding no, AllowTcpForwarding no where DisableForwarding is relied upon.
- Patch: Upgrade to OpenSSH 10.0+ or vendor packages that incorporate the fix.
- Rebuild: Rebuild container images and artifacts that may have vendored OpenSSH or packaging that embeds the older behavior.
- Verify: Test forwarded channels for accounts with DisableForwarding and confirm behavior post‑upgrade.
- Monitor: Log and alert on agent/X11 forwarding requests on bastions and jump hosts.
- SBOM: Enforce SBOM generation in CI, enable automated alerts on known vulnerable upstream versions.
- Communicate: If you run Azure Linux, follow Microsoft’s image updates; if you run custom images, update those independently and do not wait for product‑level attestations.
Conclusion
Microsoft’s public attestation that “Azure Linux includes this open‑source library and is therefore potentially affected” is an important and transparent data point — it confirms that Microsoft has completed an inventory for Azure Linux and found the upstream OpenSSH code in question. That said, the attestation does not prove exclusivity: other Microsoft artifacts (Windows in‑box OpenSSH, WSL images, Marketplace images, custom containers, and more) can and do include OpenSSH packages, and any of those artifacts could have pre‑10.0 behavior unless individually inventoried and patched.Administrators and security teams should therefore treat MSRC’s Azure Linux attestation as the start of a focused response: immediately inventory all places you run or ship OpenSSH, apply short‑term config mitigations, upgrade to OpenSSH 10.0+ where possible, rebuild images that vendor the old code, and implement SBOM and runtime detection to prevent recurrence. Microsoft’s move to publish CSAF/VEX attestations improves transparency, but it does not remove the need for local discovery and rapid remediation.
Source: MSRC Security Update Guide - Microsoft Security Response Center
