Stop SOAPwn: AI Defense for .NET SOAP RCE Risks

A single “helpful” feature in legacy enterprise stacks—auto-generating SOAP client proxies from a WSDL—can turn into an attacker-controlled file write and, in many cases, remote code execution. That’s the core lesson of SOAPwn, a newly detailed exploitation path in .NET Framework SOAP tooling that researchers demonstrated publicly in December 2025.

Most security programs still treat SOAP as “old, stable, and internal.” That assumption is exactly why SOAPwn matters. It’s not a flashy supply-chain compromise; it’s a sharp reminder that trusted protocols plus unsafe code generation equals a fast route to web shells, credential capture, and lateral movement. And it’s also a great example of where AI in cybersecurity actually earns its keep: detecting weird-but-valid behaviors that signatures and static rules often miss.

What SOAPwn actually enables (in plain terms)

SOAPwn enables arbitrary file writes—and sometimes full remote code execution—by abusing how .NET Framework SOAP client proxies handle WSDL imports and URLs. The vulnerability isn’t a single product bug; it’s an exploitation primitive that shows up when applications use .NET SOAP components in risky ways.

WatchTowr Labs described two big outcomes:

• Arbitrary file write by coercing SOAP client proxy behavior into using file system handlers instead of HTTP.
• Remote code execution (RCE) when the file write lands somewhere executable (like dropping an ASPX web shell into a web root) or when the app generates proxy code from attacker-controlled WSDL.

Here’s the stance I’ll take: if your environment still runs .NET Framework-era SOAP integrations, you should assume you have at least one exposure path unless you’ve audited and fenced it off.

The mechanics that make SOAPwn dangerous

The danger comes from “valid” inputs being interpreted in unsafe ways. Specifically:

• Some .NET Framework HTTP client proxies can be manipulated by passing a file:// URL where the proxy expects an endpoint.
• Because the attacker can often control the full output path, this becomes write-anywhere behavior, including overwriting existing files.
• If the attacker can provide a file:// path pointing to a UNC/SMB location, they can trigger outbound authentication flows and capture NTLM challenge/response material.

That last point is easy to underplay. “It’s just an auth challenge.” No. In real enterprise networks, forced authentication can become credential cracking opportunities, NTLM relay conditions, and a stepping stone into more privileged access.

The “rogue WSDL” vector: when code generation becomes code execution

The higher-impact route appears when applications generate SOAP client proxies from WSDL using ServiceDescriptionImporter. If an app accepts a WSDL URL from untrusted or semi-trusted input (or fetches it from a location an attacker can influence), the attacker can supply a WSDL that causes the generated proxy to use unsafe URLs.

From there, the playbook is familiar:

1. Feed the app a WSDL you control.
2. Coerce the generated proxy behavior into writing attacker-controlled content.
3. Drop a web shell (ASPX/CSHTML) or a script payload.
4. Execute commands under the app’s identity.

This is one of those chains where every individual step looks “reasonable” in logs—until you connect them.

Who’s affected—and why “patched vendor” doesn’t mean “fixed risk”

Multiple enterprise products were confirmed impacted, but the real blast radius is any custom app using similar .NET Framework SOAP patterns. Researchers called out impact in products like Barracuda’s service tooling, Ivanti Endpoint Manager, and Umbraco 8.

A few practical implications for security and engineering leaders:

• Vendor patches reduce exposure, not uncertainty. You may have internal services built the same way, with no vendor to bail you out.
• End-of-life software becomes a permanent liability. Umbraco 8 being EoL means you can’t count on upstream fixes even when the risk is clear.
• Framework behavior debates don’t help defenders. Whether this is “by design” or “app misuse,” attackers don’t care. They care that it works.

Snippet-worthy reality check: If an app can be tricked into writing a request to disk, it can often be tricked into writing something executable.

What defenders should look for (detection that actually works)

You don’t catch SOAPwn by searching for “SOAPwn.” You catch it by watching for mismatches between intent and behavior. That’s exactly why this belongs in an “AI in Cybersecurity” series: the strongest signal is often a pattern anomaly, not a known indicator.

Fast checks your team can run this week

Start by inventorying where SOAP client proxies are created and how endpoints are set. The goal is to answer: “Can untrusted input influence where the SOAP client sends requests—or writes them?”

Prioritize these hunting questions:

1. Do any services accept WSDL URLs as parameters? (Directly or indirectly)
2. Do you generate proxies dynamically at runtime? If yes, where does the WSDL come from?
3. Do any logs show file:// schemes in places that should only be http(s)://?
4. Do servers initiate unexpected SMB traffic outbound? Especially to non-corporate hosts.
5. Do you see SOAP payloads being written to disk locations they don’t normally touch?

Log signals that should trigger an investigation

Treat these as high-confidence suspicious patterns, even before you confirm SOAPwn.

• Endpoint strings containing file://, \\ (UNC patterns), or unexpected scheme changes
• Sudden spikes in:
  • Web server writes to content directories (web roots)
  • Creation/modification of .aspx, .cshtml, .ps1 in app-accessible paths
• Outbound authentication attempts and SMB connections from application servers
• SOAP client errors that coincide with unusual filesystem activity

Here’s what works in practice: correlate application logs + filesystem telemetry + network egress into one story. Teams that keep these in separate silos usually miss the chain.

Where AI security tools help (and where they don’t)

AI-enabled cybersecurity systems help most when the exploit chain looks “legal” at each step but statistically weird in sequence. SOAPwn is a perfect example: it can be a normal WSDL fetch, a normal SOAP request, and a normal file write—just combined in a way your environment rarely does.

AI detection: the behaviors that matter

A strong AI-based detection approach focuses on relationships:

• Sequence anomaly detection: WSDL retrieval → proxy generation → file write in a sensitive directory
• Entity behavior baselining: the SOAP service account suddenly writes executable files
• Network graph anomalies: an app server that never talks SMB suddenly reaches out to an external host
• Semantic payload inspection: SOAP bodies that include unexpected headers, encodings, or size distributions

This is a big deal for SOC teams during December change freezes and holiday staffing gaps (yes, that’s a seasonal reality). If your defenses require manual correlation across tools at 2 a.m., the attacker wins on timing alone.

AI response: what you can safely automate

Automation shouldn’t mean “shut down production because something feels off.” For SOAPwn-style chains, the best automated actions are scoped and reversible:

• Quarantine or block outbound SMB from app servers (or at least alert + require approval)
• Temporarily block file:// schemes in suspicious endpoint-setting paths (via WAF/app config guards)
• Auto-isolate the web server when:
  • an executable web artifact is written and
  • the writer process is not part of the known deployment pipeline
• Trigger an automated snapshot + evidence capture (process tree, open connections, modified files)

AI doesn’t replace engineering controls here. It buys you speed and consistency when the signals are subtle.

How to reduce SOAPwn risk without rewriting everything

The most reliable mitigation is to prevent untrusted input from influencing code generation or proxy endpoints. If you want a short checklist that changes the risk profile quickly, this is it.

Engineering guardrails (practical, not theoretical)

1. Ban dynamic WSDL consumption from untrusted sources

   • Allowlist internal WSDL hosts
   • Pin certificates where feasible
   • Cache approved WSDLs and serve them internally

2. Validate and constrain URL schemes

   • Explicitly allow https:// (and maybe http:// for legacy internal services)
   • Explicitly deny file:// and UNC patterns at input validation boundaries

3. Lock down write paths

   • The app identity should not have write permissions to web roots
   • Separate upload directories from executable directories
   • Use “no-exec” filesystem mount options where applicable

4. Harden authentication flows

   • Reduce/disable NTLM where possible
   • Block outbound SMB from servers that don’t need it
   • Monitor for forced-auth patterns

5. Treat EoL platforms as active risk, not “technical debt”

   • If a CMS/runtime is EoL, isolate it or replace it
   • Put compensating controls in front of it (strict egress, strict file-write monitoring)

SOC playbook: a simple SOAPwn triage flow

When an alert hits, don’t start by debating whether it’s “real SOAPwn.” Start by validating the impact chain.

1. Confirm endpoint manipulation: any file:// or unexpected scheme usage?
2. Confirm file write: what was written, where, and by which process identity?
3. Confirm execution: web requests to newly written artifacts, PowerShell execution, or suspicious child processes
4. Contain: isolate host or block execution paths; rotate credentials if NTLM exposure occurred

If your AI security tooling can auto-build this chain as a case timeline, you’ll cut response time dramatically.

The bigger lesson for AI in cybersecurity

SOAPwn is less about SOAP and more about “inputs that become behavior.” That pattern shows up everywhere in modern security incidents: CI/CD variables that become commands, templates that become code, configs that become network routes.

AI in cybersecurity is at its best when it spots those behavior shifts early—before the web shell lands, before the NTLM relay attempt, before the attacker pivots into domain assets.

If you’re responsible for .NET applications, your next step is straightforward: find every place your environment generates SOAP proxies or consumes WSDL, then put hard boundaries around it. If you’re running a SOC, tune your detections around scheme misuse, unexpected file writes, and outbound SMB from servers that shouldn’t speak it.

The question to ask your team before the next incident isn’t “Do we have an alert for SOAPwn?” It’s: Can we detect when a trusted enterprise protocol starts behaving like a file writer?