Tenable Nessus EUVD-2026-113393

Exploitation requires an authenticated Nessus user account that has been granted scan-creation (policy/scan configuration) rights, and the scanner must be running on Linux. The attacker must create a custom Unix compliance audit (.audit) policy and run it against the scanner host itself, causing the compliance checks to read files with the privileges of the nessusd process. Limiting factors: it is confined to readable text files (no write/modify and no service disruption), the disclosed data is bounded by what the nessusd service account can read, and it cannot be performed anonymously - it depends on holding a valid low-privileged-but-scan-capable account, so it is primarily an insider or compromised-operator risk rather than an unauthenticated remote one.

This is a genuine but moderate-priority issue, not a drop-everything emergency. The CVSS 3.1 base score is 6.5 (medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N: the network attack vector reflects that Nessus is driven through its web/API interface, but PR:L means exploitation is gated behind a valid, authenticated Nessus account that already holds scan-creation rights - so this is fundamentally a post-authentication / privilege-boundary problem rather than a pre-auth internet-facing one. The impact is confidentiality-only and bounded: C:H covers reading arbitrary text files, but I:N and A:N mean no tampering or disruption, and the read happens only with the nessusd process's privileges. The vendor/priority signals are consistent with medium urgency: the vuln.today decision label is 'this_month' (not act_now or emergency), there is no CISA KEV listing, and no EPSS score was supplied in the input (EPSS data is MISSING, so exploitation probability cannot be quantified here). There is no public exploit identified at time of analysis. The main caveat to flag: AV:N combined with PR:L looks slightly high given the flaw requires an authenticated operator to configure and run a custom compliance audit against the scanner itself - the practical barrier is possession of a scan-creation-capable account, so treat the 'network' label as 'reachable via the Nessus console by an authorized user' rather than 'exploitable by an anonymous remote attacker.'

A low-privileged but authenticated Nessus user who has been granted scan-creation rights builds a custom Unix compliance audit (.audit) policy and points it at the scanner host itself; the audit checks execute with nessusd's privileges and return the contents of text files the user should not be able to see, such as configuration files or credential material readable by that service account. Because PR:L requires valid credentials and UI:N applies only to the attacker's own actions, the realistic actor is a malicious or compromised internal scan operator rather than an anonymous outsider. No public exploit identified at time of analysis.