Researchers uncovered an unexpected behavior of HTTP client proxies when created in .NET code, potentially allowing attackers to write malicious code to arbitrary files. This in turn can open remote code execution (RCE) attack paths through web shells and malicious PowerShell scripts in many .NET applications, including commercial products.
Microsoft does not plan to fix this issue in the .NET Framework itself, saying that application developers are responsible for not passing untrusted and user-controlled URLs to the code classes that initialize HTTP client proxies.
“The impact depends on how each application uses the proxy classes, but in practice we achieved RCE in almost every product we investigated,” Piotr Bazydło, a researcher with security firm watchTowr said in a report. Bazydło also authored a technical whitepaper that he presented Wednesday at the Black Hat Europe conference.
By taking advantage of this unexpected .NET behavior, the researcher found RCE issues in Barracuda Service Center, Ivanti Endpoint Manager, Umbraco 8 CMS, Microsoft PowerShell, and Microsoft SQL Server Integration Services. However, he believes many more products and private enterprise apps are likely vulnerable.
“The most powerful exploitation path arises when applications generate HTTP client proxies from attacker-supplied WSDL files using the ServiceDescriptionImporter class,” he said. “That mechanism alone enabled successful exploitation in products from Barracuda, Ivanti, Microsoft and Umbraco, and it took only a few days of review to find working cases.”
HTTP client proxies can handle non-HTTP protocols
The .NET Framework and ASP.NET are among the most popular programming languages for enterprise applications. When a developer wants their application to communicate with an XML Web Service over HTTP they must create a proxy class that is derived from the built-in HttpWebClientProtocol class.
The Framework also provides three proxy classes — SoapHttpClientProtocol, HttpGetClientProtocol, and HttpPostClientProtocol — that enable support for SOAP, HTTP-GET, and HTTP-POST, respectively. The SoapHttpClientProtocol, which allows SOAP requests to be performed inside .NET applications, is particularly popular, because SOAP is a widely used protocol for exchanging XML-formatted messages between web services over HTTP.
Therein lies the core of the issue: As the names of these classes — and their official documentation — imply, they are meant to be used for HTTP communication. However, what Bazydło found is that passing URLs with the file:// scheme to these proxy classes will result in the FileWebRequest handler being called instead of HttpWebRequest.
“Wait, what? Why does a SOAP proxy need to be able to ‘send’ SOAP requests to a local file?” he said. “Nobody on this planet expects to receive a valid SOAP response from the filesystem.”
Because there is no mention in the documentation that these classes also work with the FILE or FTP protocol schemes, and there’s no reasonable expectation that they would, many developers are likely not aware of this behavior and have not taken additional steps to prevent this.
A path to exploitation
While this strange behavior enables exploitation, it does not guarantee it. First, an attacker would need to be able to control the URL passed to one of these classes in the application code. Although Microsoft seems to suggest this should not happen, in practice plenty of application developers expose SOAP API endpoints in their applications, sometimes without authentication.
One example found by Bazydło was in Barracuda Service Center, a popular enterprise Remote Monitoring and Management (RMM) platform. The issue, now tracked as CVE-2025-34392, was patched in hotfix 2025.1.1.
By being able to pass an arbitrary URL to a SOAP API endpoint in an affected .NET application, an attacker can trigger a leak of NTLM challenge. For example, a file:// URL pointing to a remote attacker-controlled SMB server will cause the system to send its NTLM credentials in encrypted form to that server. The attacker can then either attempt to crack them or use them in an NTLM relay attack.
To cause a more powerful local arbitrary file write, however, the attacker needs to be able to also control the arguments sent to the SOAP method, which will mean arbitrary strings can be inserted inside the XML output written to the controlled path on disk. Controlling this will often be enough to write a web shell in CSHTML (server-side templates) format on the server hosting the vulnerable app.
But it doesn’t stop here. Another way to exploit this is through Web Services Description Language (WSDL) imports. WSDL is an XML-based language web services use to provide information about their features and available interfaces. A service can provide a WSDL file to a client application, which then parses it to automatically build valid SOAP requests to the service.
Generating client SOAP proxies from WSDL imports is a fairly common functionality in .NET applications, and this is achieved by parsing WSDL files using the ServiceDescriptionImporter class. As Bazydło found, ServiceDescriptionImporter does not validate that the service definition in the WSDL file is HTTP or HTTPS.
“To summarize, WSDL imports create a very powerful exploitation path for the invalid cast issue in HttpWebClientProtocol,” he said. “If an attacker controls the imported WSDL, they also control: The target URL, which allows the proxy to interact with the filesystem; the SOAP method names; the names and types of method arguments.”
This was the case for the Barracuda Service Center vulnerability, but also for Umbraco 8 CMS — one of the most popular content management systems written in .NET — and Ivanti EPM. Umbraco 8 reached end-of-life in February so no longer receives security patches.
“At a high level, the story is simple,” the watchTowr researcher said. “The .NET Framework allows its HTTP client proxies to be tricked into interacting with the filesystem. With the right conditions, they will happily write SOAP requests into local paths instead of sending them over HTTP. In the best case, this results in NTLM relaying or challenge capture. In the worst case, it becomes remote code execution through webshell uploads or PowerShell script drops.”
No Responses