Microsoft won’t fix .NET RCE bug affecting slew of enterprise apps, researchers say

Steven

Microsoft won’t fix .NET RCE bug affecting slew of enterprise apps, researchers say

Summary

Security researchers from watchTowr disclosed a vulnerability in .NET’s SoapHttpClientProtocol that can be coerced into writing SOAP POST payloads to the filesystem (eg. file://), enabling arbitrary file writes and, in many cases, remote code execution (RCE). Piotr Bazydło presented the findings at Black Hat Europe, showing multiple exploitation paths — including malicious WSDL imports that generate unsafe HTTP client proxies — and demonstrated RCE against products such as Barracuda Service Center (now fixed), Ivanti Endpoint Manager and Umbraco 8. Researchers say the problem is widespread across vendor and in‑house .NET apps. Microsoft has declined to patch the framework, arguing developers must not pass untrusted URLs into the client proxy APIs.

Key Points

  1. The vulnerable class is SoapHttpClientProtocol; it can create client proxies for multiple schemes (HTTP, FTP, FILE) and will write POST SOAP requests to local files if given a filesystem URL.
  2. Attackers can supply malicious WSDL URLs to force apps to generate unsafe client proxies, producing remote exploitation paths.
  3. Exploitation methods include uploading ASPX webshells and dropping CSHTML or PowerShell payloads via SOAP namespaces, leading to RCE.
  4. watchTowr reported the issue via ZDI and again in July, but Microsoft declined to change behavior, saying developers must validate inputs.
  5. Known affected products (demonstrated or reported) include Barracuda Service Center (fixed), Ivanti Endpoint Manager and Umbraco 8; the true list is likely much larger given widespread .NET usage.
  6. Less severe impacts can include NTLM relay attacks, but the primary risk is arbitrary file write and server‑side code execution.

Content summary

The researcher found that SoapHttpClientProtocol, while documented as an HTTP SOAP client, uses a general creation method that accepts non‑HTTP schemes. If an attacker can influence the target URL (for example by importing a malicious WSDL), the proxy can write the SOAP request body directly to a file path. watchTowr showed multiple chains to RCE — including generating proxies from attacker‑controlled WSDLs and embedding payloads in SOAP namespaces — and successfully exploited several enterprise products. Microsoft was notified but responded that this behaviour is by design and that developers should not pass user‑controlled URLs to the API.

The report emphasises that many vendor and in‑house .NET applications may unknowingly be vulnerable, particularly where WSDL import or dynamic proxy generation is allowed without strict validation. The researcher criticises Microsoft’s stance of blaming developers rather than hardening the framework behaviour.

Context and relevance

This matters because it touches framework‑level behaviour that many developers take as safe: an “HTTP client proxy” that can be tricked into writing to the filesystem is an unexpected privilege escalation path. The refusal of a major platform vendor to patch a framework behaviour increases the burden on vendors and organisations to audit, patch and mitigate their products. It also highlights risks around dynamic WSDL import, automated proxy generation and trusting external service descriptions.

Immediate relevance: any organisation running .NET apps that import WSDLs, generate client proxies at runtime, or accept user‑supplied service URLs should treat this as high priority.

Mitigation and recommended actions

Short term mitigations include:

  • Disable or restrict WSDL import and runtime client proxy generation where possible.
  • Reject or validate any user‑supplied URLs before they reach SoapHttpClientProtocol; explicitly block file:// and other non‑HTTP schemes.
  • Harden network controls: restrict outbound traffic from application servers and limit who can fetch external WSDLs.
  • Use application allowlists, runtime protections, and Web Application Firewalls (WAFs) to detect unusual file writes or webshells.
  • Push vendors for patches and check vendor advisories for affected products; apply product‑level fixes where available.

Author style

Punchy: this isn’t just another footnote. A framework quirk enabling RCE across many apps — and Microsoft declining to change it — is a serious operational headache and deserves attention from dev, security and vendor teams.

Why should I read this?

If you run or manage .NET apps, especially ones that import WSDLs or generate client proxies dynamically, this is the kind of gotcha that can turn into a full‑blown breach. It’s quick intel: know the risky behaviours, lock down WSDL imports, and pressure vendors — you’ll thank yourself later.

Source

Source: https://go.theregister.com/feed/www.theregister.com/2025/12/10/microsoft_wont_fix_net_rce/