.net Soapwn Flaw Opens Door For File Writes And Remote Code...
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://
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 "us
Source: The Hacker News