.NET SOAPwn Flaw Opens Door for File Writes and Remote Code Execution via Rogue WSDL

Dec 10, 2025Ravie LakshmananEnterprise Security / Web Services

New research has uncovered exploitation primitives in the .NET Framework that could be leveraged against enterprise-grade applications to achieve remote code execution.

WatchTowr Labs, which has codenamed the “invalid cast vulnerability” SOAPwn, said the issue impacts Barracuda Service Center RMM, Ivanti Endpoint Manager (EPM), and Umbraco 8. But the number of affected vendors is likely to be longer given the widespread use of .NET.

The findings were presented today by watchTowr security researcher Piotr Bazydlo at the Black Hat Europe security conference, which is being held in London.

SOAPwn essentially allows attackers to abuse Web Services Description Language (WSDL) imports and HTTP client proxies to execute arbitrary code in products built on the foundations of .NET due to errors in the way they handle Simple Object Access Protocol (SOAP) messages.

“It is usually abusable through SOAP clients, especially if they are dynamically created from the attacker-controlled WSDL,” Bazydlo said.

As a result, .NET Framework HTTP client proxies can be manipulated into using file system handlers and achieve arbitrary file write by passing as URL something like “file://” into a SOAP client proxy, ultimately leading to code execution. To make matters worse, it can be used to overwrite existing files since the attacker controls the full write path.

In a hypothetical attack scenario, a threat actor could leverage this behavior to supply a Universal Naming Convention (UNC) path (e.g., “file://attacker.server/poc/poc”) and cause the SOAP request to be written to an SMB share under their control. This, in turn, can allow an attacker to capture the NTLM challenge and crack it.

That’s not all. The research also found that a more powerful exploitation vector can be weaponized in applications that generate HTTP client proxies from WSDL files using the ServiceDescriptionImporter class by taking advantage of the fact that it does not validate the URL used by the generated HTTP client proxy.

In this technique, an attacker can provide a URL that points to a WSDL file they control to vulnerable applications, and obtain remote code execution by dropping a fully functional ASPX web shell or additional payloads like CSHTML web shells or PowerShell scripts.

Following responsible disclosure in March 2024 and July 2025, Microsoft has opted not to fix the vulnerability, stating the issue stems from either an application issue or behavior, and that “users should not consume untrusted input that can generate and run code.”

The findings illustrate how expected behavior in a popular framework can become a potential exploit path that leads to NTLM relaying or arbitrary file writes. The issue has since been addressed in Barracuda Service Center RMM version 2025.1.1 (CVE-2025-34392, CVSS score: 9.8) and Ivanti EPM version 2024 SU4 SR1 (CVE-2025-13659, CVSS score: 8.8).

“It is possible to make SOAP proxies write SOAP requests into files rather than sending them over HTTP,” Bazydlo said. “In many cases, this leads to remote code execution through webshell uploads or PowerShell script uploads. The exact impact depends on the application using the proxy classes.”