Trying to assess a house you've never seen, using only its street number from a city that doesn't publish maps
Tenable plugin ID 1610114 falls in the compliance check plugin range (IDs 1,000,000+). According to Tenable's documentation, compliance plugins are *numbered starting at 1,000,000 and are all unique to sites* — meaning the ID is dynamically assigned based on which audit file checks were loaded first in your specific Tenable installation. The public Tenable plugin database (tenable.com/plugins) does not list compliance plugins in this range. The highest publicly-listed standard vulnerability detection plugin IDs are in the ~476,000 range (as of October 2026), and the highest listed Policy Compliance family plugin is ~321,205. Plugin 1610114 is unreachable from any public datasource.
Because this is a site-specific compliance check — not a CVE-based vulnerability detection plugin — there is no vendor CVSS score, no NVD/MITRE record, no EPSS score, no KEV listing, and no public advisory to compare against. The check could be anything from a CIS Benchmark hardening control (e.g., Ensure SSH root login is disabled) to a DISA STIG requirement, a PCI-DSS configuration audit, or a custom organizational policy check. Without knowing the check name, audit file, benchmark ID, or check description, no meaningful severity reassessment is possible. To proceed, export the plugin details from your Tenable console: in Tenable.io go to *Findings > Vulnerabilities*, filter by Plugin ID 1610114, and provide the plugin name, description, audit file name, and check reference (e.g., CIS control number or STIG ID).
1 steps from start to impact.
Compliance check identity unknown
- Access to the Tenable console or scan export to identify what this check actually evaluates
- The plugin ID is not publicly resolvable — only the originating Tenable instance knows what it maps to
nessus-cli plugin-details 1610114 on your Nessus scanner or export from the Tenable.io API: GET /workbenches/vulnerabilities/{plugin_id}/info.- Searching public vulnerability databases (NVD, MITRE, CVE.org) — compliance checks are not CVEs and will not appear in these databases
- Searching the public Tenable plugin database (tenable.com/plugins) — compliance plugins in the 1,000,000+ range are site-specific and not listed publicly
- Applying generic patching — compliance checks evaluate configuration, not software versions; patching does not remediate configuration drift
The supporting signals.
| Plugin Type | Tenable Compliance Check (Policy Compliance family, ID range 1,000,000+) |
|---|---|
| Public Resolvability | None — compliance plugin IDs are site-specific per Tenable documentation |
| CVE Mapping | None — compliance checks typically do not map to CVEs; they evaluate configuration posture against benchmarks (CIS, STIG, PCI-DSS, custom) |
| NVD/MITRE Record | No record — expected, as this is not a vulnerability detection plugin |
| CVSS Score | N/A — compliance checks use Pass/Fail/Error severity: Pass = Info, Fail = High, Error = Medium in Nessus reporting |
| EPSS Score | N/A — EPSS does not cover compliance checks |
| KEV Status | Not applicable — CISA KEV catalogs exploited vulnerabilities, not configuration checks |
| Proof-of-Concept | N/A — compliance checks are not exploits; no PoC concept applies |
| Public Plugin Database | Highest public Nessus plugin ID: ~476,218 (SCA checks, Oct 2026). Highest Policy Compliance family plugin: ~321,205. Plugin 1,610,114 is well above both ranges. |
| How to Resolve | Export from your Tenable instance: Tenable.io → Findings → filter Plugin ID 1610114 → copy plugin name and description. Tenable.sc → Analysis → Vulnerabilities → Plugin ID 1610114. Nessus CLI → GET /scans/{scan_id}/hosts/{host_id}/plugins/1610114. Resubmit with the check name. |
Sources.
Why this verdict
- Unresolvable identifier: Plugin 1610114 is a site-specific Tenable compliance check ID in the 1,000,000+ range. These IDs are dynamically assigned per installation and do not appear in any public plugin database, NVD, MITRE, or vendor advisory.
- No attack path can be modeled: Without knowing whether this check evaluates SSH configuration, password policy, registry hardening, firewall rules, or any other control, there is no basis for severity scoring. Compliance checks are configuration posture evaluations, not vulnerability detections.
- Role multiplier: indeterminate. The affected component, attack surface, blast radius, and deployment role are all unknown. The check could apply to workstations, domain controllers, or network appliances — but we cannot determine which without the check details.
- Assessed as IGNORE for the noisgate advisory only — this does NOT mean the underlying compliance finding should be ignored. It means the noisgate engine cannot produce a meaningful reassessment without the check name and description. The compliance finding itself may be critical depending on what it evaluates.
Why not higher?
This cannot be assessed at any severity level because the plugin ID is site-specific and publicly unresolvable. Assigning LOW, MEDIUM, HIGH, or CRITICAL without knowing what the check evaluates would be fabrication, not analysis. The IGNORE verdict reflects the *assessability* of the finding, not its importance.
Why not lower?
IGNORE is the lowest possible verdict. It is appropriate here because it signals that no action flows from this advisory — the user must resubmit with the actual check details for a real assessment.
Crowdsourced verification payload.
Run this on any host with curl and network access to your Tenable.io instance. Replace YOUR_ACCESS_KEY, YOUR_SECRET_KEY, and the plugin ID. Requires Tenable.io API keys with read access to workbenches.
#!/usr/bin/env bash
# noisgate-resolve-tenable-compliance-plugin.sh
# Purpose: Retrieve the actual name and description of a site-specific
# Tenable compliance plugin so it can be reassessed.
# Usage: bash noisgate-resolve-tenable-compliance-plugin.sh 1610114
# Requires: curl, jq, Tenable.io API keys
set -euo pipefail
PLUGIN_ID="${1:-1610114}"
TIO_ACCESS_KEY="${TIO_ACCESS_KEY:-YOUR_ACCESS_KEY}"
TIO_SECRET_KEY="${TIO_SECRET_KEY:-YOUR_SECRET_KEY}"
TIO_URL="https://cloud.tenable.com"
if [[ "$TIO_ACCESS_KEY" == "YOUR_ACCESS_KEY" ]]; then
echo "[!] Set TIO_ACCESS_KEY and TIO_SECRET_KEY environment variables first."
echo " export TIO_ACCESS_KEY=<your-access-key>"
echo " export TIO_SECRET_KEY=<your-secret-key>"
echo "UNKNOWN - API keys not configured"
exit 2
fi
echo "[*] Querying Tenable.io for plugin $PLUGIN_ID ..."
RESPONSE=$(curl -sS -w "\n%{http_code}" \
-H "X-ApiKeys: accessKey=$TIO_ACCESS_KEY; secretKey=$TIO_SECRET_KEY" \
-H "Accept: application/json" \
"$TIO_URL/workbenches/vulnerabilities/$PLUGIN_ID/info")
HTTP_CODE=$(echo "$RESPONSE" | tail -1)
BODY=$(echo "$RESPONSE" | sed '$d')
if [[ "$HTTP_CODE" -ne 200 ]]; then
echo "[!] API returned HTTP $HTTP_CODE"
echo "$BODY" | head -5
echo "UNKNOWN - API error"
exit 2
fi
PLUGIN_NAME=$(echo "$BODY" | jq -r '.info.plugin_details.name // "N/A"')
DESCRIPTION=$(echo "$BODY" | jq -r '.info.plugin_details.description // "N/A"' | head -10)
SOLUTION=$(echo "$BODY" | jq -r '.info.plugin_details.solution // "N/A"')
FAMILY=$(echo "$BODY" | jq -r '.info.plugin_details.family // "N/A"')
SEVERITY=$(echo "$BODY" | jq -r '.info.plugin_details.severity // "N/A"')
echo "========================================"
echo "Plugin ID: $PLUGIN_ID"
echo "Name: $PLUGIN_NAME"
echo "Family: $FAMILY"
echo "Severity: $SEVERITY"
echo "Description: $DESCRIPTION"
echo "Solution: $SOLUTION"
echo "========================================"
echo ""
echo "Resubmit to noisgate as:"
echo " Reassess: $PLUGIN_NAME"
echo ""
if [[ "$PLUGIN_NAME" == "N/A" ]]; then
echo "UNKNOWN - Plugin not found or no data returned"
exit 2
else
echo "RESOLVED - Plugin details retrieved. Resubmit for assessment."
exit 0
fi