Notes Station 3 CVE-2026-39991

Exploitation requires the attacker to first hold a valid Notes Station 3 user account (PR:L) and requires a second victim user to actively view or interact with the attacker-injected content (UI:A) for the script to execute. Limiting factors: this is not remote-unauthenticated - authentication is mandatory per the CVSS PR:L metric, and the dependency on victim interaction means it cannot be triggered autonomously. Impact is confined to the victim's browser session (subsequent-system C:L/I:L); the QNAP NAS host and Notes Station application itself suffer no direct confidentiality, integrity, or availability loss. Patched in Notes Station 3 3.9.12 and later.

This is a genuinely low-to-moderate priority issue, not a top-tier emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N) scores 4.8 (Medium) and tells a consistent story: a network-reachable but authenticated attacker (PR:L - requires a valid user account) must get a victim to actively interact (UI:A) for the injected script to fire, and the only impacts are low confidentiality/integrity to a subsequent system (the victim's browser session, SC:L/SI:L), with no impact to the vulnerable host itself (VC:N/VI:N/VA:N). No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no signal of active or imminent widespread exploitation. The signals are mutually consistent rather than conflicting - a classic stored/reflected XSS requiring prior authentication and user interaction. The main caveat: the description says the attacker must first 'gain a user account,' which aligns with PR:L, but it does not specify whether self-registration is possible on typical deployments; if accounts are easily obtained, the practical barrier is lower than PR:L implies. Verify account-provisioning model with the vendor.

An attacker who holds (or registers) a low-privileged Notes Station 3 account injects malicious JavaScript into a note or shared field. When another authenticated user views the attacker-controlled content, the script executes in that victim's browser session, potentially stealing session tokens or performing actions as the victim. No public exploit code was identified at time of analysis.