Someone asked you to patch your clipboard — this plugin is the scan's own diary entry, not a security finding
Nessus Plugin 19506 ("Nessus Scan Information") is a Settings-family informational plugin that ships with every Nessus scan. It records metadata about the scan itself: scanner version, plugin feed version, scan duration, port scanner used, port range scanned, whether credentialed checks succeeded, ping RTT, number of parallel hosts, and whether superseded-patch display is enabled. It was first published 2005-08-26 and has been updated continuously (currently v2.138 / NASL file scan_info.nasl). It fires on every scanned host regardless of OS — Windows, macOS, Linux. There is no CVE, no CWE, no vulnerability, and no exploitable condition associated with this plugin.
The vendor severity of INFO is exactly correct — in fact, calling it a "severity" at all is generous. This plugin exists so analysts can audit scan quality ("did creds work? how long did the scan take? what port range was covered?"). It is the equivalent of a log header. Any workflow that routes plugin 19506 into a patch queue has a filtering problem, not a security problem. If this is showing up in your remediation backlog, your Tenable SC / Tenable.io dashboard filters need to exclude severity:info or at minimum the Settings plugin family.
1 steps from start to impact.
No attack path exists
- None — this is not a security finding
- There is no exploit, no attack surface, and no condition to satisfy
severity = Info (or specifically the Settings plugin family). This prevents scan metadata from consuming analyst time. No mitigation SLA applies — this is a workflow hygiene fix, do it whenever convenient.Credentialed Checks: yes appears on hosts where you expect authenticated scanning. Flag hosts where it says no — *that* is the actionable signal from this plugin, and it's about scan coverage gaps, not host vulnerabilities.- Patching the target host — there is nothing to patch; the plugin reflects scanner metadata, not a flaw on the host.
- Disabling the plugin in scan policy — technically possible but counterproductive; you lose scan-quality telemetry that helps troubleshoot credential failures and scan performance issues.
- Firewall rules or network segmentation — irrelevant; the finding is generated by your own scanner, not by traffic from the target.
The supporting signals.
| CVE | None. No CVE is associated with this plugin. |
|---|---|
| CWE | None. No weakness class applies. |
| Plugin Family | Settings — Nessus scan configuration and telemetry family |
| Plugin Type | summary — informational, zero risk |
| Vendor Severity | INFO — the lowest possible classification in Tenable's taxonomy |
| First Published | 2005-08-26 (over 21 years ago) |
| Current Version | v2.138 (scan_info.nasl), last updated 2026-07-10 |
| Supported Platforms | Windows, macOS, Linux — fires on every scanned host |
| Exploitation Evidence | None. No PoC, no exploit, no KEV entry, no EPSS score. This is not a vulnerability. |
| Why It Appears in Scans | Nessus emits this on every host to record scan metadata: engine version, credential success, scan duration, port range, RTT, parallelism settings. It is audit/QA data for the scan operator. |
Sources.
Why this verdict
- Not a vulnerability: Plugin 19506 identifies zero exploitable conditions. It is a scan-metadata record — the Nessus equivalent of an HTTP access log entry.
- No CVE, no CWE, no attack surface: There is no weakness to exploit, no affected software version, no patch to apply. The plugin fires unconditionally on every host in every scan.
- Role multiplier: Irrelevant. Whether this plugin fires against a domain controller, an ESXi host, or a dev laptop, the output is identical scan telemetry with zero security impact. Blast radius is null across all deployment roles.
- Filtering signal: If this plugin is surfacing in a remediation queue, the issue is dashboard/report configuration. Exclude
severity:infoor theSettingsplugin family from vulnerability management workflows.
Why not higher?
There is no scenario — zero — in which this plugin represents a security risk. It contains no vulnerability data, no misconfiguration data, and no exposure data. Raising it to LOW would be dishonest and would erode trust in the severity model.
Why not lower?
IGNORE is already the lowest tier in the noisgate taxonomy. There is nowhere lower to go. This finding requires no action of any kind beyond fixing the filter that routed it to your queue.
Crowdsourced verification payload.
No verification is needed because this is not a vulnerability. However, if you want to confirm that plugin 19506 is present in a .nessus export (to validate your exclusion filter is working), run the following one-liner on any workstation with grep available. No special privileges required.
#!/usr/bin/env bash
# noisgate — confirm plugin 19506 is informational scan metadata
# Usage: bash check_19506.sh <path_to_nessus_file>
# Run on: any workstation with access to .nessus export files
# Privileges: none (read access to the file)
set -euo pipefail
if [ $# -lt 1 ]; then
echo "Usage: $0 <path_to_nessus_file>"
exit 3
fi
FILE="$1"
if [ ! -f "$FILE" ]; then
echo "UNKNOWN — file not found: $FILE"
exit 2
fi
# Check if plugin 19506 exists in the report
if grep -q 'pluginID="19506"' "$FILE"; then
SEVERITY=$(grep -A2 'pluginID="19506"' "$FILE" | grep -oP 'severity="\K[0-9]+' | head -1)
if [ "$SEVERITY" = "0" ]; then
echo "PATCHED — Plugin 19506 is present with severity 0 (Info). This is expected scan metadata, not a vulnerability."
exit 0
else
echo "UNKNOWN — Plugin 19506 found with unexpected severity: $SEVERITY. Review your Nessus configuration."
exit 2
fi
else
echo "UNKNOWN — Plugin 19506 not found in $FILE. The scan may have been run with a restricted plugin set."
exit 2
fi