Tenable Security Center EUVD-2026-58734

Exploitation requires two concurrent prerequisites: (1) a local OS account or active shell session on the system running Tenable Security Center, and (2) write access to a specific Security Center configuration file - the exact file is not named in available public data. The CVSS 4.0 vector confirms PR:L (low-privileged local user sufficient) and UI:N (no victim interaction needed after the file is modified). No network access and no administrator approval are required once those two conditions are met. The primary limiting factors are: local system access is required (not remotely exploitable), and the target configuration file must be writable by the attacker's account - in hardened deployments where Security Center configuration files are owned exclusively by the service account, an unprivileged local user would be unable to exploit this without first compromising the service account or gaining additional file-system access.

The CVSS 4.0 score of 8.5 accurately reflects the high impact - full host compromise - but the local attack vector (AV:L) and low-privilege prerequisite (PR:L) meaningfully constrain the exploitable population compared to network-facing, unauthenticated flaws. Attackers must already hold a local OS account or shell on the Security Center host AND possess write access to the targeted configuration file, which in well-hardened deployments is restricted to the service account alone. The absence of a CISA KEV entry and the lack of reported public POC code suggest no widespread opportunistic exploitation at time of analysis. EPSS data was not included in the input and cannot be assessed. The self-disclosure by Tenable (the product vendor itself) and prompt patch release are positive indicators; however, Security Center hosts are high-value targets - they aggregate vulnerability data across an organization's entire environment - making post-compromise impact disproportionately severe even if initial access is local. Environments where multiple users or service accounts can write to Security Center configuration directories carry materially higher real-world risk.

A local attacker - such as a compromised service account, a developer with access to the Security Center host, or an insider - writes OS command payloads into the targeted Security Center configuration file. When the Security Center service next reads and processes that file (for example, during a scheduled scan job or service restart), the injected commands execute at the elevated privilege level of the Security Center process, granting the attacker full control of the host. No public exploit code has been identified at time of analysis, but the low-complexity rating (AC:L) and straightforward CWE-78 class suggest the technique would be readily replicable by any attacker who achieves the file write prerequisite.