Tenable Security Center EUVD-2026-58727

Exploitation requires an authenticated account with access to the report-generation feature of Tenable Security Center (CVSS PR:L confirms a low-privilege but non-anonymous account is needed; administrative rights are explicitly NOT required). The attacker must be able to reach the SC web/report interface over the network (AV:N) and supply input that is later processed during server-side report rendering - the report-rendering/evaluation path is the exact feature that must be reachable. Limiting factors: a valid low-privilege login is mandatory, so anonymous internet scanning cannot trigger it directly; exposure therefore scales with how many report-capable accounts exist and whether the console is network-restricted. No end-user interaction is required (UI:N), and no non-default configuration is called out in the description.

The CVSS 4.0 base score of 9.4 (Critical) is driven by a network vector with low attack complexity, high impact to confidentiality, integrity and availability of both the vulnerable system and subsequent systems, and - importantly - a privilege requirement of PR:L rather than PR:N, meaning some valid low-privilege account is a hard prerequisite. This is a genuine priority rather than an inflated high-CVSS-but-low-real-risk finding: the target is a security appliance whose service account typically has broad reach, code execution needs no user interaction, and any authenticated report-capable user suffices, so any organization running SC with multiple analyst accounts should treat this as urgent. That said, the practical exposure depends on how tightly SC access is controlled - an internet-exposed or loosely-provisioned instance is far more at risk than one restricted to a small vetted operations team. No EPSS score and no KEV/POC signals were supplied, so exploitation probability cannot be quantified from the input; the absence of these should not be read as low likelihood given the trivial complexity once an account is held.

An analyst-level user who already holds valid Security Center credentials (for example a contractor or a compromised low-privilege account) crafts a malicious report input containing an injected code directive, then triggers report generation; the server evaluates the payload during rendering and executes attacker-controlled commands as the SC service account. From there the attacker can read stored scan results and credentials and pivot into the managed environment. No public exploit is identified at time of analysis, and no user interaction beyond the attacker's own session is required.