Microsoft has confirmed that its Azure Linux distribution is potentially vulnerable to CVE-2025-10148, a recently disclosed flaw in the curl library’s WebSocket implementation. The advisory, published this week, clarifies that Azure Linux includes the affected open-source component—but leaves open the question of whether other Microsoft products that ship curl, including Windows, could also be at risk.

The vulnerability at a glance

CVE-2025-10148 centers on a mistake in curl’s WebSocket frame masking. According to the upstream curl project, versions 8.11.0 through 8.15.0 failed to generate a fresh 32-bit mask for every outgoing WebSocket frame, instead reusing a fixed mask across an entire connection. That deviation from RFC 6455 produces a predictable masking pattern that a malicious server can exploit under narrow conditions.

The primary attack scenario is proxy cache poisoning. If a client connects to a malicious WebSocket server over a cleartext connection (ws://) through a misconfigured proxy, the attacker can craft frames that the proxy incorrectly interprets as HTTP traffic. The proxy may then cache attacker-controlled content and serve it to other users. The fix, released in curl 8.16.0, forces unique masks per frame as the standard requires.

Crucially, exploitation demands both an unencrypted WebSocket session and a proxy that mishandles WebSocket frames. In most modern environments where TLS (wss://) is the norm, the attack surface shrinks dramatically. Still, the flaw has earned reasonable attention because libcurl is embedded in countless products and images.

What Microsoft said (and didn’t say)

Microsoft’s advisory, first posted on the Microsoft Security Response Center (MSRC) update guide, offers a short FAQ: “Is Azure Linux the only Microsoft product that includes this open-source library and is therefore potentially affected by this vulnerability?” The answer is essentially: Azure Linux does include it, and we began publishing machine-readable CSAF/VEX attestations in October 2025 to confirm such things for Azure Linux.

That statement is accurate for Azure Linux. Microsoft has completed an inventory check for its own curated Linux distribution, which powers many Azure VM images and container base images, and found the vulnerable library present. The advisory also says that if additional products are identified as impacted, Microsoft will update the CVE record—a standard commitment.

Notice what the advisory doesn’t say. It does not assert that no other Microsoft product contains the vulnerable curl version. It does not address Windows, where curl has shipped as a system component for years. It does not cover the multitude of Azure Marketplace images, Azure Kubernetes Service (AKS) node images, developer tooling, or SDKs that might include libcurl. For consumers who rely on anything beyond Azure Linux itself, the advisory is a signal to check—not an all-clear.

Who should worry: real-world impact by user type

Home and casual users

If you run a personal Azure Linux VM, update its curl package to version 8.16.0 or later immediately. For Windows users, check your system curl version (more on that below). The actual risk of exploitation is low—most home networks don’t route traffic through caching proxies that could be poisoned, and web services predominantly use encrypted WebSockets. Still, keeping software current eliminates the vector entirely.

IT administrators and security teams

Your scope is broader. Any Microsoft-supplied image or binary that incorporates libcurl is a candidate. Start by identifying every Windows endpoint, Azure VM, container image, build agent, and developer workstation running in your environment. The attack conditions may be narrow, but proxy cache poisoning, when it occurs, can affect many downstream clients at once. A single unpatched system that connects to a weaponized WebSocket server could become patient zero for content manipulation.

Developers and DevOps engineers

Your build pipelines, self-hosted runners, and base images likely include curl. If you’re building containers on top of Microsoft-provided base images, confirm the libcurl version inside each layer. A vulnerable curl in a CI/CD agent might be used to fetch dependencies over WebSockets—an edge case, but one worth closing.

How the curl bug crept into Microsoft products

Curl’s ubiquity is both a strength and a headache. The library and its command-line tool are shipped in three broad patterns inside Microsoft’s ecosystem:

  1. System packages in Linux distributions: Azure Linux, which is built from Microsoft’s own package repositories, bundles a specific version of curl. Microsoft’s VEX attestation confirms that version is vulnerable until updated.
  2. Windows system binaries: Windows 10 and 11 include curl.exe and libcurl.dll in System32 and SysWOW64. Microsoft compiles these from upstream curl sources, and the shipped version can lag behind the latest upstream release. If the Windows build of curl is based on versions 8.11.0–8.15.0, it is affected.
  3. Embedded in applications and services: Many Microsoft products and third-party tools link libcurl internally. Visual Studio, Azure DevOps agents, PowerShell modules, and even some Azure services might bundle the library. These usages are harder to track without SBOMs or manual inspection.

Microsoft’s decision to begin its VEX program with Azure Linux makes operational sense. Azure Linux is a controlled artifact that the company builds, tests, and distributes directly. By attesting to it first, Microsoft validates the tooling and processes before expanding to more complex product lines. That rollout strategy, however, leaves customers who manage hybrid estates—Windows, containers, and various Marketplace images—without a complete picture.

Immediate steps for every Microsoft environment

Until Microsoft broadens its advisories, assume that any Microsoft artifact not explicitly declared “not affected” may still contain the vulnerable curl. Here’s how to respond.

1. Inventory curl versions across your estate

  • Windows endpoints: Open a command prompt and run curl --version (or check the file properties of %WINDIR%\System32\curl.exe). If the version is between 8.11.0 and 8.15.0, it’s affected.
  • Azure VMs and container instances: For Azure Linux, Microsoft’s attestation is clear—update now. For other distro-based images, run your package manager’s query (rpm -q curl, dpkg -l curl) and compare the version.
  • Containers and AKS node images: Scan base images with a vulnerability scanner. Many commercial and open-source scanners already flag this CVE.
  • Build agents and developer tools: Inspect self-hosted agents and the SDKs they install. Look for curl in toolchains like vcpkg or winget packages.

2. Patch or upgrade curl to 8.16.0 or later

  • Azure Linux: Use the distro’s package manager to update curl. Microsoft will likely release an updated package soon if it hasn’t already.
  • Windows: Microsoft hasn’t released a security update for this CVE yet. If your version is affected, you can either wait for a Microsoft patch or manually replace the system curl with an updated build from the official curl website—though the latter may break support. The safest near-term path is to apply mitigations.
  • Containers and custom images: Rebuild images with updated base layers. If you maintain your own base images, bump the curl version in your Dockerfile and redeploy.

3. Apply mitigations while patching

  • Enforce encrypted WebSocket (wss://): Configure applications and network controls to prefer or require TLS. Most modern libraries default to wss://; ensure yours do.
  • Tighten your proxies: Verify that front-end and caching proxies do not interpret WebSocket frames as HTTP. Block, or at minimum never cache, WebSocket traffic. Check your proxy vendor’s documentation for correct handling.
  • Restrict outbound cleartext: If your network policies allow, block outbound ws:// connections at the firewall until all internal clients are patched.

4. Monitor Microsoft’s VEX and CSAF feeds

Microsoft has committed to updating the CVE record if other products are found affected. Integrate the CSAF feed into your vulnerability management pipeline if you haven’t already. That way, any new impact statement appears in your dashboards automatically.

5. Demand SBOMs for Microsoft products you depend on

For images, packages, and services not yet covered by a VEX attestation, request a software bill of materials (SBOM) from Microsoft or your support channel. An SBOM lists all components and their versions, letting you verify curl’s presence without waiting for a public advisory.

What happens next: the road to better transparency

CVE-2025-10148 is far from the most dangerous vulnerability of the year, but it illustrates an important trend. As Microsoft modernizes its vulnerability disclosure practices—moving toward machine-readable CSAF/VEX—customers gain better tools to automate risk assessment. The company’s first steps with Azure Linux are a positive sign.

Yet, the phased rollout exposes gaps. Most organizations run a mix of Windows, Linux, containers, and cloud services, and they need equal clarity across all those surfaces. Expect pressure on Microsoft to accelerate VEX coverage for Windows system components, Azure Marketplace images, and popular development tools. In the interim, the best defense is a thorough, automated inventory paired with a “verify before trusting” mindset.

Keep an eye on the MSRC update guide for CVE-2025-10148. If your scans reveal a vulnerable curl, you’ll already be ahead of the game—and your users won’t notice a thing.