Microsoft won’t fix .NET RCE bug affecting slew of enterprise apps, researchers say
(2025/12/10)
- Reference: 1765387839
- News link: https://www.theregister.co.uk/2025/12/10/microsoft_wont_fix_net_rce/
- Source link:
Security researchers have revealed a .NET security flaw thought to affect a host of enterprise-grade products that they say Microsoft refuses to fix.
Piotr Bazydło, principal vulnerability researcher at watchTowr, unveiled the findings at Black Hat Europe on Wednesday, claiming that several vendor and in-house solutions could be vulnerable to remote code execution (RCE) attacks due to errors in the way applications built on Microsoft's .NET framework handle Simple Object Access Protocol (SOAP) messages.
The researcher identified the SoapHttpClientProtocol class as the primary culprit, explaining that it can be exploited in different ways to achieve an attacker's goals.
[1]
The class inherits from HttpWebClientProtocol, as do other client proxy types, but watchTowr highlighted SoapHttpClientProtocol as it is by far the most common across codebases.
[2]
[3]
Bazydło said in a [4]blog post shared with The Register before publication: "Its name and the official documentation both paint a simple picture: it should handle SOAP messages transported over HTTP. Straightforward. Predictable. Safe. Reality is less cooperative."
The class is responsible for setting the target URL of the SOAP service and defining a SOAP method, but the vulnerability arises when attackers can manipulate that target URL and the way SoapHttpClientProtocol creates clients.
[5]
Despite being designed to handle HTTP requests, SoapHttpClientProtocol uses a generic creation method that supports multiple protocols, including HTTP/HTTPS, FTP, and FILE.
If an attacker can set the target URL to a file system instead of an HTTP web address, the class will ignore the error and then write the SOAP request (which uses the POST method) directly into the file.
Bazydło wrote: "Wait, what. Why should a SOAP proxy be able to 'send' SOAP requests to a local file? Nobody on this planet expects to receive a valid SOAP response from the filesystem."
[6]
This unintended behavior can be abused by attackers to arbitrarily write files, including the XML data in the SOAP request. Or, less impactfully, NTLM relay attacks.
The researcher brought this issue to Microsoft at the time via the [7]Zero Day Initiative (ZDI). Microsoft reportedly told Bazydło it would not be fixing the bug since developers should not be allowing untrusted inputs.
"Predictably, Microsoft treated the behavior as a feature rather than a vulnerability," Bazydło said. "The response blamed developers and users.
"According to Microsoft, the URL passed to SoapHttpClientProtocol should never be user-controlled, and it was the developer's responsibility to validate inputs.
"Of course, all developers regularly decompile .NET Framework assemblies and read the internal implementation, so they obviously know that an 'HTTP client proxy' can be convinced to write data to the filesystem. How could anyone think otherwise?"
A year later, the folks at watchTowr started investigating Barracuda Service Center, which it described as "a widely deployed RMM platform," and one of the (now-fixed) enterprise-grade products vulnerable to the .NET exploits.
They soon found that its SOAP API method could be accessed with no authentication, leading them to an alternate exploitation path: through importing Web Services Description Language (WSDL) files.
Attackers can feed a URL that points to a WSDL file they control to vulnerable applications, which then generate an HTTP client proxy from it.
Bazydło said he found two ways to achieve remote code execution using this method: through uploading ASPX webshells; or dropping payloads (CSHTML webshells or [8]PowerShell scripts) via the namespace of a SOAP request's body.
He said that there are likely more ways to exploit the vulnerability, but the namespace technique was sufficient to exploit [9]Ivanti Endpoint Manager and Umbraco 8 CMS.
These were the products mentioned in the watchTowr report as being affected, but the total number is thought to be much higher.
"Given the wide usage of [10].NET , and the limitations of hours in a day, the list of affected products should be considered anecdotal. There are most definitely numerous affected vendor and in-house solutions affected, but bluntly, we believe we've made our point with the above list," Bazydło said.
The watchTowr team reported the second exploit path to Microsoft in July, but were met with a similar response as they had received through the ZDI a year earlier.
Microsoft told the researchers again that it was not its fault that users were accepting untrusted inputs.
They received a near-identical response in follow-up reports to Microsoft, made in the context of Microsoft's own products, some of which were also affected by the bug.
Although the issue relates to application behavior, "users should avoid consuming untrusted input that could generate and execute code," Microsoft said.
Clearly delighted with the response, Bazydło wrote: "So first we blame the application. If that is not an option, because it would require fixing Microsoft's own code, we blame the user.
"The neanderthal user should have manually verified the WSDL file and realized that it could write SOAP requests to files instead of sending them over HTTP. Sigh." ®
Get our [11]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aTn7lEIGol_dSY776yc8SQAAAQU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aTn7lEIGol_dSY776yc8SQAAAQU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aTn7lEIGol_dSY776yc8SQAAAQU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://labs.watchtowr.com/soapwn-pwning-net-framework-applications-through-http-client-proxies-and-wsdl/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aTn7lEIGol_dSY776yc8SQAAAQU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aTn7lEIGol_dSY776yc8SQAAAQU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2025/10/05/zdi_wiz_hacking_contest_kerfuffle/
[8] https://www.theregister.com/2025/07/04/microsoft_finally_bids_farewell_to/
[9] https://www.theregister.com/2025/02/21/ivanti_traversal_flaw_poc_exploit/
[10] https://www.theregister.com/2025/09/11/microsoft_dotnet_10/
[11] https://whitepapers.theregister.com/
Piotr Bazydło, principal vulnerability researcher at watchTowr, unveiled the findings at Black Hat Europe on Wednesday, claiming that several vendor and in-house solutions could be vulnerable to remote code execution (RCE) attacks due to errors in the way applications built on Microsoft's .NET framework handle Simple Object Access Protocol (SOAP) messages.
The researcher identified the SoapHttpClientProtocol class as the primary culprit, explaining that it can be exploited in different ways to achieve an attacker's goals.
[1]
The class inherits from HttpWebClientProtocol, as do other client proxy types, but watchTowr highlighted SoapHttpClientProtocol as it is by far the most common across codebases.
[2]
[3]
Bazydło said in a [4]blog post shared with The Register before publication: "Its name and the official documentation both paint a simple picture: it should handle SOAP messages transported over HTTP. Straightforward. Predictable. Safe. Reality is less cooperative."
The class is responsible for setting the target URL of the SOAP service and defining a SOAP method, but the vulnerability arises when attackers can manipulate that target URL and the way SoapHttpClientProtocol creates clients.
[5]
Despite being designed to handle HTTP requests, SoapHttpClientProtocol uses a generic creation method that supports multiple protocols, including HTTP/HTTPS, FTP, and FILE.
If an attacker can set the target URL to a file system instead of an HTTP web address, the class will ignore the error and then write the SOAP request (which uses the POST method) directly into the file.
Bazydło wrote: "Wait, what. Why should a SOAP proxy be able to 'send' SOAP requests to a local file? Nobody on this planet expects to receive a valid SOAP response from the filesystem."
[6]
This unintended behavior can be abused by attackers to arbitrarily write files, including the XML data in the SOAP request. Or, less impactfully, NTLM relay attacks.
The researcher brought this issue to Microsoft at the time via the [7]Zero Day Initiative (ZDI). Microsoft reportedly told Bazydło it would not be fixing the bug since developers should not be allowing untrusted inputs.
"Predictably, Microsoft treated the behavior as a feature rather than a vulnerability," Bazydło said. "The response blamed developers and users.
"According to Microsoft, the URL passed to SoapHttpClientProtocol should never be user-controlled, and it was the developer's responsibility to validate inputs.
"Of course, all developers regularly decompile .NET Framework assemblies and read the internal implementation, so they obviously know that an 'HTTP client proxy' can be convinced to write data to the filesystem. How could anyone think otherwise?"
A year later, the folks at watchTowr started investigating Barracuda Service Center, which it described as "a widely deployed RMM platform," and one of the (now-fixed) enterprise-grade products vulnerable to the .NET exploits.
They soon found that its SOAP API method could be accessed with no authentication, leading them to an alternate exploitation path: through importing Web Services Description Language (WSDL) files.
Attackers can feed a URL that points to a WSDL file they control to vulnerable applications, which then generate an HTTP client proxy from it.
Bazydło said he found two ways to achieve remote code execution using this method: through uploading ASPX webshells; or dropping payloads (CSHTML webshells or [8]PowerShell scripts) via the namespace of a SOAP request's body.
He said that there are likely more ways to exploit the vulnerability, but the namespace technique was sufficient to exploit [9]Ivanti Endpoint Manager and Umbraco 8 CMS.
These were the products mentioned in the watchTowr report as being affected, but the total number is thought to be much higher.
"Given the wide usage of [10].NET , and the limitations of hours in a day, the list of affected products should be considered anecdotal. There are most definitely numerous affected vendor and in-house solutions affected, but bluntly, we believe we've made our point with the above list," Bazydło said.
The watchTowr team reported the second exploit path to Microsoft in July, but were met with a similar response as they had received through the ZDI a year earlier.
Microsoft told the researchers again that it was not its fault that users were accepting untrusted inputs.
They received a near-identical response in follow-up reports to Microsoft, made in the context of Microsoft's own products, some of which were also affected by the bug.
Although the issue relates to application behavior, "users should avoid consuming untrusted input that could generate and execute code," Microsoft said.
Clearly delighted with the response, Bazydło wrote: "So first we blame the application. If that is not an option, because it would require fixing Microsoft's own code, we blame the user.
"The neanderthal user should have manually verified the WSDL file and realized that it could write SOAP requests to files instead of sending them over HTTP. Sigh." ®
Get our [11]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aTn7lEIGol_dSY776yc8SQAAAQU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aTn7lEIGol_dSY776yc8SQAAAQU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aTn7lEIGol_dSY776yc8SQAAAQU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://labs.watchtowr.com/soapwn-pwning-net-framework-applications-through-http-client-proxies-and-wsdl/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aTn7lEIGol_dSY776yc8SQAAAQU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aTn7lEIGol_dSY776yc8SQAAAQU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2025/10/05/zdi_wiz_hacking_contest_kerfuffle/
[8] https://www.theregister.com/2025/07/04/microsoft_finally_bids_farewell_to/
[9] https://www.theregister.com/2025/02/21/ivanti_traversal_flaw_poc_exploit/
[10] https://www.theregister.com/2025/09/11/microsoft_dotnet_10/
[11] https://whitepapers.theregister.com/
m4r35n357
You can at least try experimenting with live USB systems. Give yourself options.
Sandgrounder
So your 'solution' to an issue affecting unknown numbers of enterprise server based applications running legacy. Net framework libraries and the ancient Soap framework, is to suggest users switch their desktop client?
Maybe it's me being a bit slow. Perhaps you could explain in really simple terms that a. Net developer may understand exacly how this would resolve the issue for the quoted scenario for an Umbraco CMS for example.
And did I miss the year of the Linux desktop or is that still just around the corner along with fusion power and flying cars?
Paul Herber
Has anyone tried softsoaping MS?
No? Thought not.
Anonymous Coward
enshittification
Doctor Syntax
"users should avoid consuming untrusted input that could generate and execute code,"
Does Microsoft have a definitive list of ways in which that could happen so that users will know how to avoid them?
Paul Herber
HTH
The response was bad worded.
Jou (Mxyzptlk)
The response "users should avoid consuming untrusted input" is the actual bug, which sound to me like calling the developer a user (which is not entirely wrong, but that is another discussion).
I am on Microsoft side, there are valid scenarios for using file:// instead of http(s):// (and various other XXXX://). The application should filter URI prefixes, even if they are encapsulated "WSDL file they control to vulnerable applications, which then generate an HTTP client proxy from it.", because it is still the application executing the encapsulated file://, and not the "user" as TheReg cites MS.
What would happen if MS decides to add an mandatory "AllowFileURI" which is by default $false unless otherwise specified? I don't know...
The obvious solution is for everybody to "fix" Microsoft and their Artificial Ignorance invasion by migrating now to a Linux distribution on the desktop. Unlike Windows 11, there are no "hardware requirements" stopping the vast majority of Windows 10 hardware owners from installing Linux. Some oddball systems may need expert assistance, but all that hardware is old enough that it'll be on the major distribution's supported hardware lists for several years now...