WatchTowr Labs安全研究人员公开SOAPwn研究，披露.NET Framework内置HTTP用户端代理HttpWebClientProtocol及其衍生的SoapHttpClientProtocol存在设计缺陷，微软多次将相关回应标记为不修补，但实际测试证实，攻击者可结合Web服务描述语言（Web Services Description Language，WSDL）导入机制，在多款企业级产品上构建可重复利用的远程程序代码执行攻击链，部分产品场景甚至在无需额外用户操作的情况下即可触发。
研究人员指出，这类简单对象访问协议（Simple Object Access Protocol，SOAP）用户端代理名义上用于通过HTTP访问XML Web服务，但实例上会根据网址前缀自动选择不同通信组件。也就是说，只要攻击者有办法变动代理的URL设置，就能把原本指向HTTP服务的网址，改成指向本机文件路径或SMB分享路径。因此原本要当成SOAP请求送出去的内容，反而可能被写进服务器文件系统，或被送到攻击者控制的文件分享点，前者带来任意位置写入文件的风险，后者则造成NTLM散列外流。
不少.NET应用允许管理者输入WSDL网址，程序会通过ServiceDescriptionImporter自动产生并调用SOAP用户端代理。当WSDL由攻击者提供时，攻击者可以在WSDL里动手脚，把服务地址改成服务器上的文件路径，并设计好SOAP内容的结构，让代理在指定路径写入ASPX或CSHTML等可执行文件。对外看起来如同正常调用Web服务，实际上则是在服务器指定路径写入一个Webshell或其他恶意脚本文件，让攻击者后续得以远程执行程序代码。
在已公开的案例中，研究人员在Barracuda Service Center RMM与Ivanti Endpoint Manager等产品中验证完整攻击流程，前者漏洞编号CVE-2025-34392，并以2025.1.1热修补更新处理，后者则对应CVE-2025-13659。研究人员并指出，Umbraco 8 CMS、Microsoft PowerShell与SQL Server Integration Services也存在可利用场景，代表这并非单一实例疏失，而是.NET SOAP HTTP用户端代理设计在实务使用下衍生的系统性问题。
研究人员提到，微软主张不应让不受信任输入控制URL或WSDL来源，因而将问题界定为应用程序与用户层级。在缺乏框架端修补的前提下，研究人员建议厂商与企业团队主动盘点是否使用SoapHttpClientProtocol与ServiceDescriptionImporter等组件，特别是允许外部导入WSDL并动态产生代理的功能，并在应用层限制仅接受HTTP与HTTPS协议，同时为WSDL来源设置明确信任边界。
