IBM WebSphere Application Server CVE-2026-15887

Exploitation requires that the attacker hold at least low-privileged authenticated access to the IBM WebSphere Application Server SOAP endpoint (PR:L per CVSS vector). The vulnerability is triggered specifically through the SOAP request processing pipeline - deployments that expose SOAP endpoints to untrusted authenticated users are directly at risk. The 'blind' nature limits direct data exfiltration: the attacker cannot read server responses, only infer internal network behavior through side channels. Additional risk elevation applies in cloud environments where IMDSv1 is enabled (no token required) or where internal services are reachable from the WAS host without authentication. Exploitation is limited by: (1) the requirement for valid credentials, (2) the blind nature ruling out direct response-body theft, and (3) the need for the SOAP processing path to be reachable from the attacker's access context.

The NVD-assigned CVSS 3.1 score of 5.4 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N reflects the authenticated nature of the attack (PR:L), which meaningfully constrains the threat surface to users or service accounts with valid credentials to the SOAP endpoint. No KEV listing and no public proof-of-concept further reduce near-term risk. That said, SSRF vulnerabilities carry elevated contextual risk in cloud-hosted or hybrid environments where metadata services (IMDSv1-style) are accessible, and WAS deployments behind WAFs that do not inspect outbound server requests could be quietly abused for internal reconnaissance. The S:U (unchanged scope) designation in the official vector is arguably conservative - SSRF fundamentally causes the vulnerable system to interact with other systems on behalf of the attacker, a dynamic more consistent with S:C. The I:L metric in the official vector also deserves scrutiny: direct data-write impact from blind SSRF is unclear. Real-world priority is moderate: authentication requirement and blind nature reduce urgency, but patching remains the correct response given WAS's enterprise footprint.

An authenticated user or compromised service account submits a crafted SOAP request to the WebSphere endpoint with an internal URL (e.g., an internal microservice, database admin UI, or cloud metadata endpoint) embedded in the message payload. The WAS server processes the SOAP body and issues an outbound HTTP request to that internal target. By observing differences in response latency or error messages returned by WAS, the attacker infers whether internal hosts are alive and which ports are open, effectively using the WAS host as a pivot for internal network reconnaissance without needing direct connectivity.