WhatsUp Gold CVE-2026-65937

The attacker must be authenticated to WhatsUp Gold (per the CVE description - note this conflicts with the PR:N CVSS metric, which should be verified). The attacker must have adjacent network access to the WhatsUp Gold web server (AV:A), meaning they must be on the same internal network segment, VLAN, or subnet hosting the monitoring platform - internet-based attackers cannot directly reach most WhatsUp Gold deployments. A victim user must interact with the page containing the injected payload (UI:R), meaning passive exploitation without victim action is not possible. No special non-default configuration is described as required; the flaw appears to exist in standard WhatsUp Gold deployments before 2026.0.2. Exploitation is limited by: the authenticated prerequisite, the adjacent-network constraint, and the need for victim interaction.

The NVD-assigned CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) presents a direct conflict with the CVE description, which explicitly states 'authenticated attacker.' The PR:N metric implies no authentication is required, yet the description requires the attacker to be authenticated - this discrepancy must be verified against the vendor advisory before triaging. The adjacent attack vector (AV:A) meaningfully constrains exposure: internet-facing exploitation is not indicated, and the attacker must reside on the same network segment or VLAN as the WhatsUp Gold instance, which is typical of internal monitoring infrastructure. User interaction (UI:R) is required, meaning a victim must load the poisoned page. No KEV listing indicates no confirmed active exploitation by CISA. No public proof-of-concept code was identified in the provided data. EPSS data was not provided. Overall, this is a genuine high-severity finding for organizations running unpatched WhatsUp Gold internally, but the AV:A constraint and authentication prerequisite (per description) reduce realistic exploitation risk compared to a purely network-accessible, unauthenticated flaw.

An attacker authenticated to WhatsUp Gold - for example, a low-privileged monitoring user or an insider threat - navigates to an input field susceptible to stored XSS and submits a crafted payload that bypasses the application's frontend validation. The payload is stored server-side. When a network administrator subsequently loads the affected page (e.g., a device dashboard or alert configuration view), the stored script executes in the administrator's browser, exfiltrating their session cookie to an attacker-controlled endpoint and granting full administrative access to the network monitoring platform. No public proof-of-concept has been identified, but the attack is straightforward for anyone with application access.