soapwn-wsdl-rce

Exploit .NET SOAP WSDL deserialization flaws to deploy webshells.

11|1|Updated May 4, 2026
One-click install
npx skills add https://github.com/dreadnode/capabilities --skill soapwn-wsdl-rce
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: soapwn-wsdl-rce
Source: https://github.com/dreadnode/capabilities/tree/main/capabilities/web-security/skills/soapwn-wsdl-rce
Command: npx skills add https://github.com/dreadnode/capabilities --skill soapwn-wsdl-rce

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill addresses the risk of undetected remote code execution in .NET applications that consume external SOAP services via WSDL import, where a silent type cast failure during deserialization allows attackers to write arbitrary executable files (like .aspx webshells) to the server via user-influenced WSDL URLs.

Core Features & Use Cases

  • Endpoint Detection: Probes common SOAP/WCF/ASMX endpoints and validates .NET server response headers to confirm target viability.
  • Exploit Parameter Validation: Tests for user-influenced WSDL URL parameters via JSON APIs and SOAP import headers, using out-of-band callbacks to confirm server-side fetching behavior.
  • Payload Deployment & Fallbacks: Crafts malicious WSDL payloads to trigger file writes, verifies webshell accessibility, and provides alternative path suggestions and chaining options for blocked execution scenarios.
  • Use Case: Red teamers assessing .NET applications that integrate third-party SOAP services can use this Skill to automate exploitation of the WSDL proxy deserialization flaw to gain initial access without triggering standard security alerts.

Quick Start

Use the soapwn-wsdl-rce skill to exploit a user-influenced WSDL URL parameter on a target .NET SOAP endpoint to deploy a functional webshell and gain remote code execution.

Frequently Asked Questions about soapwn-wsdl-rce

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How does .NET SOAP WSDL deserialization lead to remote code execution?

A silent type cast failure during .NET SOAP WSDL proxy deserialization allows attackers to write arbitrary executable files, such as .aspx webshells, to the server via user-influenced WSDL URLs, achieving remote code execution.

How do I exploit a user-influenced WSDL URL parameter on a .NET SOAP endpoint?

You can exploit a user-influenced WSDL URL parameter by crafting malicious WSDL payloads that trigger arbitrary file writes, deploying a functional webshell to gain remote code execution on the vulnerable .NET server.

Can I use this to gain initial access to .NET applications consuming third-party SOAP services?

Yes, red teamers assessing .NET applications that integrate third-party SOAP services can use this technique to automate exploitation of the WSDL proxy deserialization flaw and gain initial access without triggering standard security alerts.

How do I confirm server-side fetching behavior when testing for WSDL import vulnerabilities?

You can test for user-influenced WSDL URL parameters via JSON APIs and SOAP import headers, using out-of-band callbacks to confirm server-side fetching behavior on the target .NET application.

What should I do if webshell execution is blocked after deploying a malicious WSDL payload?

If webshell execution is blocked, the Skill provides alternative path suggestions and chaining options to bypass execution restrictions and achieve remote code execution on the vulnerable .NET server.