New research out today from cybersecurity company watchTowr Pte. Ltd. details a new class of vulnerabilities in the .NET Framework that can allow attackers to weaponize standard SOAP client proxies for arbitrary file writes and full remote code execution.

Presented at Black Hat Europe 2025, the research paper “SOAPwn: Pwning .NET Framework Applications Through HTTP Client Proxies And WSDL,” details a long-standing design flaw in how .NET handles web requests inside core proxy classes.

The issue detailed in the research relates to the HttpWebClientProtocol class, which underpins several widely used proxy types, including SoapHttpClientProtocol, DiscoveryClientProtocol and HttpSimpleClientProtocol.

The researchers found that while the proxy is meant to only handle HTTP requests, it also internally relies on WebRequest.Create without properly enforcing the protocol type. Because it does so, the target URL can coerce the proxy into using non-HTTP handlers such as file:// or UNC paths to allow SOAP request bodies to be written directly to the filesystem.

The result allows for attacks ranging from NTLM credential relaying to arbitrary file writes that can overwrite scripts and configuration files.

The impact can vary but becomes more severe when applications dynamically generate SOAP proxies from attacker-controlled Web Services Description Language files using the ServiceDescriptionImporter class, a pattern the researchers say is encouraged by Microsoft’s own documentation. The ability to craft a malicious WSDL can allow attackers to control key elements of the generated proxy, including its service URL, method names and input types.

In real-world testing, this technique enabled researchers to drop functional ASPX and CSHTML webshells, leading directly to remote code execution.

The researchers have demonstrated several successful exploitations against enterprise-grade products, including Barracuda Service Center RMM, Ivanti Endpoint Manager and Umbraco 8 CMS.

In the Barracuda Networks Inc. case, a single unauthenticated SOAP request was sufficient to force the application to import a malicious WSDL, generate a vulnerable proxy and write a webshell into the product’s web directory, resulting in full system compromise.

Normally at this point in cybersecurity research papers, the story would involve the researchers working with the vendor — in this case Microsoft — to resolve the issue before going public with the details, but that’s not the case here.

The watchTowr researchers claim to have been disclosing and trying to get action from Microsoft since 2024, but instead, Microsoft has classified the behavior as an application-level issue rather than a framework vulnerability, stating that developers should not accept untrusted input for URL or WSDL processing. The researchers argue that this position ignores the fundamentally unintuitive behavior of an HTTP client proxy that can be coerced into filesystem and SMB interactions.

According to the researchers, Microsoft has dismissed attempts by claiming that the “issue stems from application behavior, where users should avoid consuming untrusted input that could generate and execute code.”

“So first we blame the application. If that is not an option, because it would require fixing Microsoft’s own code, we blame the user,” the researchers write. “The Neanderthal user should have manually verified the WSDL file and realized that it could write SOAP requests to files instead of sending them over HTTP.”

The research warns that the flaw is likely present across a wide range of in-house and vendor-supplied .NET applications and urges defenders to audit for unsafe use of ServiceDescriptionImporter and any user-controllable SoapHttpClientProtocol URLs.

Image: SiliconANGLE/Ideogram