IBM Verify Directory EUVD-2026-119737

The weakness is in how IBM Security Verify Directory (10.0.0 through 10.0.4) and IBM Verify Directory (11.0.0) accept GET requests for authentication, causing credentials supplied as URL query parameters to be written to browser history and server logs. Realizing harm is not a direct network attack against the service: an attacker must obtain read access to a location where those URLs are recorded - server/application logs, intermediate proxy or load-balancer logs, centralized log/SIEM stores, or the browser history of a shared or compromised client host. Exploitation is therefore limited by the requirement that authentication actually be performed via GET with credentials in the URL and by the attacker needing privileged visibility into those log/history sinks; it does not grant integrity or availability impact and does not by itself bypass authentication.

This is a moderate-severity information-disclosure issue (CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) rather than a top-priority emergency, and the signals are internally consistent. The CVSS vector indicates a network-reachable (AV:N) low-complexity (AC:L) flaw but one that requires some privilege level (PR:L) and yields only a confidentiality impact (C:H, I:N, A:N) - matching a design weakness (CWE-650) where the directory accepts GET requests carrying credentials, exposing passwords in browser history and server/proxy logs rather than granting direct code execution or data modification. No EPSS score, KEV listing, SSVC automatable/technical-impact values, or POC reference were provided in the input, so there is no evidence of active or automated exploitation; the vuln.today Decision label is 'this_month', consistent with a real-but-not-urgent credential-hygiene defect. The practical risk is secondary exposure: harvested credentials from logs could later enable account takeover, so impact depends heavily on who can read the logs (log aggregation operators, proxy admins, shared browser hosts). Treat it as a genuine priority for credential-handling remediation on the affected IBM directory products, but not as a drop-everything issue absent any exploitation signal.

An attacker or insider with read access to web server logs, proxy logs, SIEM/log-aggregation data, or a shared workstation's browser history retrieves cleartext passwords that were transmitted as URL query parameters during authentication to IBM Security Verify Directory. Those captured credentials are then replayed to log in as the victim and access directory data. No public exploit was identified at time of analysis; exploitation is passive credential harvesting rather than an active memory-corruption attack.