New research reveals exploit primitives in the .NET Framework that could be leveraged against enterprise-grade applications to enable remote code execution.
WatchTowr Labs, which codenamed the “invalid cast vulnerability” SOAPwn, said the issue affects Barracuda Service Center RMM, Ivanti Endpoint Manager (EPM), and Umbraco 8. However, given the popularity of .NET, the number of affected vendors will likely be longer-term.
The findings were announced today by watchTowr security researcher Piotr Bazydlo at the Black Hat Europe security conference in London.
Essentially, SOAPwn allows attackers to execute arbitrary code in products built on the foundation of .NET by abusing Web Services Description Language (WSDL) imports and HTTP client proxies due to errors in the way Simple Object Access Protocol (SOAP) messages are handled.
“It is typically exploitable via a SOAP client, especially if it is created dynamically from an attacker-controlled WSDL,” Bazydlo said.
As a result, the .NET Framework HTTP client proxy can be manipulated to use the file system handler and pass something like “file://” as a URL to the SOAP client proxy to accomplish writing an arbitrary file, which can ultimately lead to code execution. Even worse, since the attacker controls the complete write path, it could be used to overwrite existing files.
In a hypothetical attack scenario, an attacker could leverage this behavior to provide a Universal Naming Convention (UNC) path (e.g., “file://attacker.server/poc/poc”) and a SOAP request would be written to an SMB share under their control. This allows an attacker to capture and decrypt NTLM challenges.
That’s not all. This research also found that applications that use the ServiceDescriptionImporter class to generate HTTP client proxies from WSDL files can have a more powerful exploitation vector that can be weaponized by leveraging the fact that the URLs used in the generated HTTP client proxies are not validated.
This technique allows an attacker to execute remote code by providing a vulnerable application with a URL pointing to a WSDL file that they manage and dropping a fully functional ASPX web shell or an additional payload such as a CSHTML web shell or PowerShell script.
After responsible disclosures in March 2024 and July 2025, Microsoft chose not to fix the vulnerability, stating that the issue was due to an issue or behavior in the application and that “users should not use untrusted input that can generate and execute code.”
This finding indicates that expected behavior in common frameworks can be a potential exploit path leading to NTLM relaying and arbitrary file writes. This issue has since been resolved 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).
“Instead of sending SOAP requests over HTTP, it is possible to write them to a file in a SOAP proxy,” Bazydlo said. “This often results in remote code execution via WebShell uploads or PowerShell script uploads. The exact impact depends on the application using the proxy class.”
Source link
