Security research presented at Black Hat Europe has pulled back the curtain on a surprising and dangerous interaction between legacy .NET SOAP client proxies and Web Services Description Language (WSDL) imports — a design quirk that lets SOAP clients be coerced into writing arbitrary files and, in real deployments, has led to reliable remote code execution (RCE) in widely used enterprise products. The vulnerability class, dubbed "SOAPwn" by the researchers, hinges on how the .NET Framework's SoapHttpClientProtocol and WSDL-driven proxy generation interact with generic WebRequest creation; watchTowr's Piotr Bazydło says Microsoft has declined to issue a framework-level fix, leaving responsibility to application vendors and administrators to mitigate exposed attack paths.
From a security engineering perspective, the practical consequences are:
Source: theregister.com Microsoft won’t fix .NET RCE bug affecting enterprise apps
Background
What the researchers found
At its core the issue involves the .NET base class SoapHttpClientProtocol — the usual parent of code-generated SOAP client proxies found across thousands of applications. When an application constructs a proxy to call a SOAP service, the proxy holds the service URL and delegates the actual transport to the framework's WebRequest plumbing. The watchTowr research shows that, because the creation routine is generic, non-HTTP schemes such as file:// (including UNC paths) can be accepted and processed; the result is that a SOAP POST can be written to a filesystem location instead of sent over the network. That file write can be abused to place web shells, scripts, or other payloads that give attackers code execution on the server running the vulnerable product. This surprising behavior is not hypothetical. Bazydło demonstrated multiple exploitation chains: one that leverages an application that imports attacker-supplied WSDL to dynamically generate a client proxy, and another that simply manipulates a proxied target URL so a SOAP POST is written to disk. Practical exploits against Barracuda Service Center, Ivanti Endpoint Manager, and Umbraco 8 CMS were shown, including webshell uploads and payload drops that led to RCE on test systems.Timeline and disclosure
Researchers reported the initial discovery through responsible channels — a disclosure via the Zero Day Initiative (ZDI) and later coordinated reports to Microsoft. According to the researcher, Microsoft advised that the framework behaved as designed and placed the onus on application developers to avoid passing untrusted data into SoapHttpClientProtocol-based proxies. watchTowr displayed its findings at Black Hat Europe after responsible disclosure activity spanning 2024 and 2025.Technical anatomy: how a SOAP client can end up writing files
SoapHttpClientProtocol and generic request creation
Generated SOAP proxies in .NET commonly inherit from SoapHttpClientProtocol. When those proxies are invoked they use underlying facilities (WebRequest / HttpWebRequest abstractions) to prepare and send a request. The critical detail highlighted by the research is that the proxy infrastructure does not strictly validate that the transport is HTTP(S) only. Because the WebRequest factory can resolve different URI schemes to corresponding handlers, an attacker-controlled URI using a file:// or an SMB UNC path can end up being handled by a file/SMB handler, causing the SOAP request body (POST content) to be written to disk or to a network share instead of delivered to an HTTP server. The implications are twofold:- Arbitrary file write: An attacker who can control the target URL (or cause an application to import a WSDL that sets such a URL) can cause the server to write arbitrary XML or binary payloads to attacker-controlled locations.
- NTLM relay and authentication abuse: Writing to an SMB share under attacker control can trigger NTLM authentication flows (the server attempting to access the share), creating opportunities for NTLM relay, credential capture, or lateral movement depending on the environment.
WSDL-driven proxy generation as an escalation vector
A more powerful exploitation path involves ServiceDescriptionImporter and programmatic proxy generation. Many enterprise products import remote WSDLs at runtime (or read locally stored WSDLs that originate from external parties) to build client proxies. If the WSDL originates from an attacker-controlled location, it can specify service endpoints and namespaces that shape how the generated proxy functions — including the URL used by the proxy and even the types and namespaces that will be materialized in the generated assembly. By combining a crafted WSDL with proxy generation, attackers can force a server to create a proxy that will write to filesystem paths or to network shares, or that will deserialize attacker-specified types — a pathway to webshell drops or worse.Real-world impact: vendors and CVEs
Barracuda Service Center (RMM)
watchTowr's disclosure included a detailed case where Barracuda Service Center's RMM product accepted WSDL imports without sufficient validation. Researchers demonstrated arbitrary file write and insecure reflection that led to remote code execution. Barracuda issued fixes in Service Center RMM version 2025.1.1 and multiple CVEs were published that track the issues (including arbitrary file write / RCE and insecure reflection / deserialization). Administrators were urged to upgrade immediately.Ivanti Endpoint Manager (EPM)
Ivanti patched a set of vulnerabilities in Endpoint Manager (EPM) that included a high-severity arbitrary file write / RCE that watchTowr tied back to SOAP/WSDL handling in some exploitation scenarios. Ivanti released 2024 SU4 SR1 to remediate these issues and credited multiple researchers in advisories. The Ivanti findings were consistent with the vectors described by watchTowr — notably WSDL imports and dynamic proxy generation.Umbraco 8 and other products
watchTowr mentioned Umbraco 8 CMS as a product that could be exploited via the namespace-based payload drop technique in SOAP bodies. Public vendor advisories tying Umbraco's October 2024 security advisories to this specific SOAP/WSDL exploit are not as prominent; Umbraco has released patches for multiple vulnerabilities and urged upgrades for legacy 8.x instances, but a direct, vendor-stated CVE mapping to the SOAPwn technique was less visible at publication time. The researcher-reported list of affected products is explicitly presented as anecdotal and partial: given .NET's broad footprint, the full set of affected apps — including custom in-house solutions — is likely much larger. Readers should treat product lists as an evolving set and verify vendor bulletins for their specific versions. This particular claim (Umbraco being impacted by watchTowr's exact technique) is reported by the researchers and by multiple news outlets, but direct vendor mapping for every named product varies.Microsoft's stance and the debate over responsibility
The response
According to the researchers, Microsoft reviewed the reports and declined to treat the behavior as a vulnerability in the framework, stating that SoapHttpClientProtocol’s URL is not meant to be user-controlled and that developers must validate inputs — i.e., Microsoft categorized the problem as an application-level issue rather than a platform-level bug requiring a framework update. watchTowr says it was told to avoid consuming untrusted input that could generate and execute code. That response, as reported by the researcher, provoked pushback because the framework's class names and documentation give an expectation of HTTP transport semantics that developers reasonably assume.Why this matters technically and practically
There is an important distinction between a platform intentionally exposing a capability and one exposing a surprising behavior that leads to dangerous outcomes. If a class is named and documented as an HTTP-based SOAP proxy but still routes requests through a generic creation path that resolves file handlers, the cognitive gap can cause developers to make reasonable-looking choices that become insecure in production.From a security engineering perspective, the practical consequences are:
- Many codebases generate or consume WSDLs and use generated proxies without deep inspection of the generated transport URLs.
- Admins and developers are trained to validate user inputs, but WSDL imports and proxy generation are often treated as configuration tasks or trusted integration points, not as an active attack surface that must be sanitized.
- A framework-level hardening — for example, enforcing HTTP(S)-only transports for SoapHttpClientProtocol-created proxies or making the transport choice explicit — would reduce whole classes of downstream errors. Microsoft’s decision not to change the framework leaves that hardening to application vendors and ops teams.
Risk assessment: who needs to worry and why
- Organizations running or exposing management or integration consoles (RMM, EPM, CMS, etc. that accept WSDL imports or that use dynamic service discovery are at high risk.
- Software that programmatically generates .NET SOAP proxies from remotely sourced WSDLs — or that accepts a service URL derived from user input — should be treated as a critical attack surface.
- Legacy .NET deployments (Framework 4.x and earlier service stacks) and apps that interoperate with Windows file/SMB stacks present elevated opportunities for NTLM relay and credential capture.
- The risk is not limited to off-the-shelf products; in-house enterprise integrations and automation tools that use ServiceDescriptionImporter or Add Web Reference-style flows may be vulnerable even if never publicly exposed.
Practical mitigations (immediate to medium term)
The following steps balance immediate risk reduction and practical remediation for organizations that rely on .NET-based SOAP integrations.- Apply vendor updates immediately.
- Upgrade Barracuda Service Center to the patched 2025.1.1 release where fixes were made.
- Upgrade Ivanti Endpoint Manager to the 2024 SU4 SR1 release that addresses the reported issues.
- Block and monitor risky protocols at the network edge.
- Deny outbound file:// and SMB traffic from application servers to untrusted networks.
- Block the server's ability to reach arbitrary SMB shares and alert on any file writes to network shares initiated by application processes.
- Harden WSDL consumption.
- Disallow runtime importing of WSDLs from unverified external URLs. Require WSDLs be vetted and stored in a controlled repository.
- Validate any service URLs generated from WSDLs: enforce HTTP(S)-only schemes and canonicalize URIs before use.
- Sanitize and restrict generated proxies.
- If an application must generate proxies at runtime, run generation in a hardened sandbox that removes the ability to reach filesystem or SMB handlers.
- Prefer static, code-reviewed proxy generation during build time rather than dynamic imports at runtime.
- Implement least privilege and isolation for app pools and services.
- Ensure web apps and service processes run with the minimal privileges necessary and that webroot locations are not writable by application accounts.
- Use AppLocker/Code Integrity and webserver hardening to prevent execution of unexpected files placed in web directories.
- Monitor for indicators of exploitation.
- Watch for new or unexpected ASHX/ASPX/CSHTML files in web directories, unusual SMB connections, and sudden WSDL imports or proxy generation events in logs.
- Audit WSDL-related configuration changes and restrict who can modify integration endpoints.
- Test and scan internal apps.
- Use static analysis and dynamic testing to identify code paths that rely on ServiceDescriptionImporter or accept WSDL URLs/target URLs from untrusted sources.
Developer and vendor recommendations
- Reassess integration trust models.
- Treat WSDLs and service definitions as active input vectors, not passive text. Any runtime import must be validated.
- Make transport selection explicit.
- Where possible, require configuration or explicit code to choose an HTTP(S) transport and fail loudly if the URL scheme is not allowed.
- Increase transparency in generated code.
- Generated proxies should include warnings and runtime checks preventing non-HTTP schemes.
- Consider per-assembly policy guards.
- Use runtime checks or AppDomain policies to prevent code-generated proxies from resolving non-HTTP handlers.
- Advocate for framework-side safeguards.
- Vendors should weigh the trade-offs of platform changes that would make the intended use explicit; while Microsoft has declined to change the behavior at present, ecosystem pressure and staged proposals might prompt future hardening.
Critical analysis: strengths, weaknesses, and who’s right?
Strengths of the research
- The research exposes a systemic issue that crosses vendor boundaries: it is not a single-product bug but a framework interaction that amplifies risk across many applications.
- The researchers produced practical exploit chains and demonstrated real-impact outcomes (webshells, scripts, NTLM opportunities), and vendors subsequently produced fixes — validating the severity of the vectors.
- By highlighting WSDL imports and ServiceDescriptionImporter as an abuse surface, the work calls attention to a frequently overlooked integration pattern.
Weaknesses and limitations
- Not every .NET application using SoapHttpClientProtocol is automatically vulnerable; exploitation requires either an untrusted URL entry point or unsafe WSDL imports. The real-world exposure depends on product design, authentication barriers, and network segmentation.
- Some vendor mappings remain anecdotal in public reporting; while Barracuda and Ivanti published advisories, other mentions (e.g., Umbraco) were less uniformly traceable to vendor CVEs at the time of reporting, so caution is required when extrapolating a full list of affected products. Researchers and reporters are clear that the list is partial and evolving.
On Microsoft’s decision not to change the framework
- Microsoft's stance — that SoapHttpClientProtocol is not intended to accept user-controlled URLs and that developers are responsible for validating inputs — is consistent with a philosophy that application logic and input validation are developer responsibilities.
- However, API ergonomics and naming matter. If a class is named and documented in a way that implies HTTP-only semantics but internally routes requests through a generic factory, the platform creates a usability gap that produces real security risks. Preventing surprising behavior at the framework level is often the most effective way to protect a broad population of downstream apps, especially in enterprise contexts with heavy legacy footprints.
Conclusion and takeaways
The SOAPwn findings are a reminder that legacy integration patterns — like runtime WSDL imports and dynamically generated SOAP proxies — remain powerful attack surfaces in modern enterprise environments. The practical impact has already been demonstrated: reliable arbitrary file writes and RCE were shown against commercial products, and vendor patches have been issued where problems were confirmed. At the same time, the vendor ecosystem faces a hard operational choice. Microsoft’s decision to classify this as application-level responsibility forces vendors and operators to shoulder the remediation and hardening burden. That approach can be effective where development teams are mature and inventories are complete, but it leaves less-resourced organizations exposed. Until a platform-level mitigation arrives (if it ever does), the most effective defense is a combination of immediate vendor patching, network-level restrictions on file/SMB flows, elimination of untrusted WSDL imports, and strict runtime validation of service URLs. For defenders: prioritize inventory and containment. For developers: treat WSDLs and generated proxies as untrusted inputs unless they’re explicitly vetted. For platform vendors: balance API backward compatibility with clear, secure-by-default semantics — surprising behaviors in core classes are invitations to widespread, high-impact exploits.Source: theregister.com Microsoft won’t fix .NET RCE bug affecting enterprise apps
