Brocade Management Software EUVD-2026-86470

Exploitation requires (1) adjacent-network access to the affected Brocade/Broadcom management software (AV:A - not routable across the internet by default) and (2) an existing low-privilege authenticated account (PR:L). The attacker must be able to submit 'specific user account structures' that exercise the vulnerable Java cache-key object-comparison path; the flaw manifests only for those particular account-data shapes that cause the comparison routine to mis-evaluate object identity. No user interaction is needed (UI:N). Limiting factors: the adjacency requirement, the need for prior authentication, and the niche enterprise deployment footprint all substantially narrow realistic exploitability.

This is a moderate-severity issue that is realistically LOW priority for most organizations. The vendor CVSS 4.0 vector (AV:A/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N, base 6.9) tells a specific and internally consistent story: exploitation requires adjacent-network access (AV:A) and existing low-level privileges (PR:L), and the sole impact is to integrity (VI:H) with no confidentiality or availability impact. There is NO EPSS score, NO CISA KEV listing, and NO public proof-of-concept, so all exploitation signals point to theoretical rather than active risk. A notable CONFLICT: the input tag says 'Information Disclosure,' but the CVSS vector explicitly sets VC:N (no confidentiality impact) and VI:H (integrity impact) - this is an identity/authorization-integrity flaw (CWE-1025 comparison-using-wrong-factors causing 'identity mismatch'), NOT information disclosure. The description is also heavily obfuscated and never names the affected product; the reporter address (sirt@brocade.com) and the Broadcom advisory number (39000) strongly indicate this is a Brocade product, most likely SANnav given the near-identical advisory batch (SA 38996-38999). Because exploitation needs both adjacency and prior authentication against a niche enterprise SAN-management appliance, real-world exposure is small - this is a high-CVSS-number-in-context but low-real-world-urgency issue absent evidence of exploitation.

An attacker who already holds a low-privilege account and network adjacency to the management appliance submits specially structured user-account data that trips the flawed Java cache-key object comparison, causing the system to resolve one identity as another. This identity mismatch could let the attacker have actions attributed to, or authorization resolved as, a different (higher-value) account. No public exploit code exists, and the adjacent-plus-authenticated prerequisites meaningfully constrain who can attempt it.