WSO2 API Manager EUVD-2026-39638

Exploitation requires that the WSO2 API Manager process inbound messages through the message-flow/mediation component that handles WS-Addressing headers - i.e. a SOAP/WS-* proxy or API flow where WS-Addressing is parsed. The attacker only needs network reachability to that endpoint; per the CVSS vector AV:N/AC:L/PR:N/UI:N there is no authentication or user interaction required against affected versions. The limiting factor is exposure and routing: real impact depends on the gateway having network paths to valuable internal services, and deployments that do not expose WS-Addressing-enabled flows or that already enforce strict egress filtering meaningfully constrain exploitation.

Signals are mixed. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H = 10.0) and SSVC (Automatable: yes) argue for high priority: network-reachable, no authentication, low complexity, and scope change into internal systems. Against that, EPSS is only 0.20% (10th percentile), SSVC Exploitation is 'none', SSVC Technical Impact is only 'partial' (not 'total'), the CWE is SSRF rather than direct RCE, and there is no public exploit or KEV listing. The SSVC 'partial' technical impact directly conflicts with the vendor's C:H/I:H/A:H maximal rating - SSRF's realized impact depends entirely on what internal services the gateway can reach, so the 10.0 is likely a worst-case rating rather than guaranteed full compromise. Net: treat as a genuine high-priority patch for any internet-facing WSO2 API Manager because exploitation is unauthenticated and automatable, but the absence of in-the-wild activity and low EPSS suggest it is not yet under active mass exploitation.

An external attacker sends a crafted SOAP request to an internet-facing WSO2 API Manager with a malicious WS-Addressing ReplyTo/To header pointing at an internal address (for example a cloud metadata service or an internal admin endpoint). The gateway, without authentication, issues a server-initiated request to that destination, letting the attacker reach or probe internal services unreachable from outside. No public proof-of-concept has been identified, but the low complexity and unauthenticated network vector make weaponization straightforward.