← Back to Feed CACHED · 2026-07-10 08:58:19 · CACHE_KEY tenable:33850
tenable:33850 · CWE-1104 · Disclosed 2008-08-08

Unix Operating System Unsupported Version Detection

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

This isn't a vulnerability — it's a coroner's report on your operating system

Tenable plugin 33850 (unsupported_operating_system.nasl) is an *informational lifecycle check*, not a CVE. It fires when Nessus fingerprints a Unix/Linux host running an OS release the vendor no longer supports — think RHEL 5/6, CentOS 6/8, Solaris 9/10 pre-ESU, AIX 5.x/6.1, Ubuntu 16.04/18.04 without ESM, macOS <11, Debian 9/10, SUSE 11, or NetApp/Nokia IPSO/embedded appliances that trip the same fingerprint. There is no single 'affected version range' — the plugin's whole point is to flag *any* OS release past its vendor End-of-Life date.

Tenable rates this Critical / CVSS 10.0 as a policy signal, not a technical measurement. The score reflects the compounding risk that no future kernel, libc, OpenSSL, or sudo CVE will ever be patched on this host — not that a single exploit exists today. In real environments the vendor label is directionally right (unsupported OSes are radioactive) but the score is a placeholder. The true severity depends entirely on the host's role and network exposure, which is why we reassess to HIGH with role-driven escalation to CRITICAL for identity, hypervisor, or edge boxes.

"Not a CVE — it's a lifecycle finding. Tenable's CVSS 10 is a placeholder; the real risk is unpatchable accumulated debt."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify EOL host via banner / fingerprint

Attacker enumerates the environment and identifies an unsupported OS via SSH banner, HTTP Server: header, SNMP sysDescr, or SMB dialect. Public tools like nmap -sV, whatweb, and Shodan lookups reveal EOL kernels within minutes. This is the reconnaissance equivalent of plugin 33850 running from the outside.
Conditions required:
  • Network reachability to any service on the host
  • Any version-leaking service (SSH, HTTP, SMB, SNMP)
Where this breaks in practice:
  • Egress-only hosts behind NAT are invisible externally
  • Banner scrubbing hides some but not all fingerprints
Detection/coverage: Passive: Zeek/Suricata SSH banner logging. Active: any credentialed VM scanner will flag the OS.
STEP 02

Select an unpatched public CVE for that kernel/libc/service

Attacker consults searchsploit, GitHub PoC repos, or KEV for exploits targeting the frozen software stack. EOL RHEL 6 hosts, for example, are trivially vulnerable to Dirty COW (CVE-2016-5195), CVE-2021-4034 pwnkit, CVE-2021-3156 Baron Samedit sudo, and OpenSSH CVE-2024-6387 regreSSHion if the version predates backports. There is no vendor patch to close the gap.
Conditions required:
  • Public PoC exists for at least one component on the host
  • Attacker has code-execution or auth vector into a vulnerable service
Where this breaks in practice:
  • Third-party ESM programs (Ubuntu Pro ESM, TuxCare/KernelCare, RHEL ELS) *can* patch some CVEs — check if ESM is contracted
  • Compensating controls (SELinux enforcing, seccomp, AppArmor) blunt some public exploits
Detection/coverage: EDR with behavioral kernel-exploit signatures catches Dirty COW/pwnkit variants; signature-only AV does not.
STEP 03

Exploit and gain code execution

Attacker weaponizes one of the known chains — e.g., CVE-2021-4034 (pwnkit) for local root, CVE-2024-6387 (regreSSHion) for pre-auth RCE, CVE-2022-0847 (Dirty Pipe) for LPE. Metasploit modules exist for most of these (exploit/linux/local/pkexec_cve_2021_4034). Because the OS is EOL, no vendor patch will ever land.
Conditions required:
  • Vulnerable service reachable or local shell available
  • Exploit compatible with the specific frozen kernel/glibc
Where this breaks in practice:
  • Hardened kernel builds, grsecurity, or unusual arch (ppc64/s390x) can break off-the-shelf PoCs
  • Modern EDR (CrowdStrike, SentinelOne, Elastic Defend on Linux) fires on syscall anomalies
Detection/coverage: auditd + Falco ruleset for privilege escalation; osquery lifecycle queries; Tenable follow-on plugins for each specific CVE.
STEP 04

Persist and pivot — no patches are coming

Once rooted, the attacker persists via cron, systemd unit, SSH authorized_keys, or LD_PRELOAD. Because the OS is unsupported, every future CVE in glibc, kernel, sudo, or OpenSSL becomes a permanent foothold reinforcement. Pivot targets depend on host role — an EOL RHEL 6 domain-joined app server becomes a stepping stone; an EOL Solaris host running Oracle DB becomes a data-egress pivot.
Conditions required:
  • Initial code execution achieved
  • Host has network reachability to internal assets
Where this breaks in practice:
  • Network segmentation (east-west firewall, microsegmentation) limits pivot range
  • Immutable-infra shops with short-lived nodes reduce persistence value
Detection/coverage: NDR (Darktrace/Vectra) on east-west anomalies; identity telemetry on unusual service-account activity.
03 · Intelligence Metadata

The supporting signals.

Finding typeInformational lifecycle detection, not a single CVE — plugin unsupported_operating_system.nasl v1.297
Vendor severity / scoreTenable CRITICAL / CVSS 10.0 (policy placeholder, not measurement)
CVSS vectorCVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — synthetic; reflects the aggregate risk of an unpatched OS
In-the-wild statusEOL Linux hosts are a favorite target of ransomware crews (Cl0p, LockBit, BlackCat) and initial-access brokers per Mandiant M-Trends 2025
Proof-of-conceptN/A directly — but PoCs exist for every frozen CVE the OS can no longer receive (pwnkit, Dirty Pipe, regreSSHion, Baron Samedit, etc.)
EPSSNot applicable — not a CVE; underlying CVEs like CVE-2024-6387 have EPSS >0.5
KEV statusThe plugin itself is not KEV-listed; many CVEs it *implies* are (pwnkit CVE-2021-4034 added 2022-06-27; Dirty Pipe CVE-2022-0847)
Affected releases (typical)RHEL/CentOS 5/6/8, Solaris ≤10, AIX ≤6.1, Ubuntu ≤18.04 no-ESM, Debian ≤10, SUSE 11, macOS ≤10.15, NetApp IPSO, older ONTAP fingerprints (see NetApp KB)
FixUpgrade to a vendor-supported release, or purchase extended support (RHEL ELS, Ubuntu Pro ESM, TuxCare ELS, Oracle Solaris ESU, IBM AIX SWMA extensions)
First published / last updatedPublished 2008-08-08, last updated 2025-09-23
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (8.5/10)

The vendor CRITICAL/10.0 is a policy label, not a measurement of an exploitable condition, so it cannot be defended as a universal CRITICAL across a fleet. The single most decisive factor is role-driven blast radius: an EOL host running a workstation-tier workload is HIGH backlog debt, while an EOL domain controller, hypervisor, or edge appliance is a floor-CRITICAL fleet-compromise risk that must be treated individually.

HIGH that unpatched EOL Unix hosts are a top-quartile enterprise risk
MEDIUM that the reassessed score applies uniformly — real severity depends on the specific host
HIGH that Tenable's CVSS 10.0 is a synthetic label, not a technical score

Why this verdict

  • Not a CVE, no PoC to score: Plugin 33850 is a lifecycle finding. There is no single exploit chain — the risk is the *statistical certainty* that some future CVE in the frozen stack will be unpatchable. Baseline down from CRITICAL to HIGH.
  • Friction adjustment — ESM/ELS programs: Ubuntu Pro ESM, RHEL ELS, TuxCare KernelCare, Oracle ESU, and IBM SWMA extensions materially reduce risk on hosts covered by them. Fleets with any ESM coverage should adjust down further.
  • Friction adjustment — network position: An EOL host on an isolated OT segment or behind a strict WAF is meaningfully less exposed than one internet-facing. Downgrade only applies where segmentation is verifiable.
  • Role multiplier — workstation / dev sandbox: Chain succeeds but blast radius is single-host. Verdict floor stays at HIGH given the long-tail CVE exposure.
  • Role multiplier — line-of-business app tier: Chain succeeds; blast radius extends to tenant/data. Sits at HIGH.
  • Role multiplier — domain controller / hypervisor / identity broker / backup server / edge appliance / CI runner: Chain succeeds; blast radius is fleet-scale or supply-chain-scale. Verdict floor for these hosts is CRITICAL — do NOT let the fleet-average downgrade mask them. Enumerate and treat individually.

Why not higher?

Uniformly CRITICAL treats every EOL host — including an air-gapped lab VM or a legacy printer front-end — as fleet-ending, which drowns out the actual high-value-role hosts that deserve emergency attention. Without a specific active-exploitation event tied to a specific EOL host, a fleet-wide CRITICAL is operationally unusable.

Why not lower?

MEDIUM would ignore the compounding reality that these hosts will *never* receive another security patch. Every kernel, glibc, OpenSSL, and sudo CVE published from EOL day forward is a permanent exposure. Ransomware initial-access brokers explicitly hunt EOL Linux/Solaris in ShadowServer and GreyNoise telemetry — this is not backlog hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Inventory and role-tag every 33850 hit — Export the plugin 33850 finding set and enrich with CMDB role data (DC, hypervisor, edge, DB, workstation). Anything role-tagged identity/hypervisor/edge/backup/CI moves to the CRITICAL queue; the rest stays HIGH. Complete within 30 days per the noisgate HIGH mitigation SLA.
  2. Purchase extended support where migration will slip — For hosts you cannot retire inside the noisgate remediation window, buy RHEL ELS, Ubuntu Pro ESM, TuxCare ELS, Oracle Solaris ESU, or IBM AIX SWMA extension. This restores patch coverage for the frozen CVEs and converts the finding from HIGH to MEDIUM until migration completes.
  3. Segment and firewall the EOL hosts — Move EOL hosts behind a dedicated VLAN with default-deny east-west, and front any exposed service with a WAF or reverse proxy that terminates TLS on a supported OS. Deploy within 30 days. Assume the OS itself is untrustworthy.
  4. Deploy a modern EDR / kernel-runtime agent — SentinelOne, CrowdStrike Falcon, or Elastic Defend on Linux catches syscall-level exploit behavior (pwnkit, Dirty Pipe) even when the underlying OS is unpatched. Confirm agent supports the EOL kernel — some vendors drop support along with the distro.
  5. Rotate credentials and remove Tier-0 trust — Ensure no Domain Admin, root SSH keys, or PAM secrets live on or trust the EOL host. Break lateral-movement paths so that when — not if — the host is popped, the blast radius stays local.
  6. Commit to a migration date with executive sign-off — Register every 33850 host in an exception register with a hard replacement date inside the 180-day noisgate HIGH remediation SLA (or ≤90 days for CRITICAL role-tagged hosts). Exceptions without a target date are how EOL fleets grow.
What doesn't work
  • Signature-based AV alone — the CVEs an EOL host is exposed to are frequently in-memory kernel/LPE chains that never touch disk.
  • 'It's behind the firewall' — most EOL exploitation is post-initial-access lateral movement, not perimeter breach.
  • Applying the last available vendor patch — after EOL there is no patch stream, so a fully-patched EOL host is still exposed to every subsequent CVE.
  • Marking as false positive because the appliance is 'Unix-based' (NetApp ONTAP, Nokia IPSO, appliance firmwares) — the underlying stack really is frozen; escalate to the appliance vendor for a supported firmware release.
06 · Verification

Crowdsourced verification payload.

Run on the target Unix/Linux host as any user (root not required). Invoke as ./check_eol.sh — no arguments. Exit code 2 = VULNERABLE (EOL), 0 = PATCHED (supported), 1 = UNKNOWN. Cross-checks against endoflife.date release windows shipped as a static table.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# noisgate: Tenable plugin 33850 verifier — Unix/Linux OS lifecycle check
# Exit codes: 0 PATCHED, 1 UNKNOWN, 2 VULNERABLE
set -u

today_epoch=$(date +%s)
result="UNKNOWN"
detail=""

to_epoch() { date -d "$1" +%s 2>/dev/null || echo 0; }

check_eol() {
  local name="$1" ver="$2" eol_date="$3"
  local eol_epoch
  eol_epoch=$(to_epoch "$eol_date")
  if [ "$eol_epoch" -eq 0 ]; then result="UNKNOWN"; return; fi
  if [ "$today_epoch" -gt "$eol_epoch" ]; then
    result="VULNERABLE"
    detail="$name $ver reached vendor EOL on $eol_date"
  else
    result="PATCHED"
    detail="$name $ver supported until $eol_date"
  fi
}

if [ -r /etc/os-release ]; then
  . /etc/os-release
  ID_LC=$(echo "${ID:-unknown}" | tr '[:upper:]' '[:lower:]')
  VER="${VERSION_ID:-unknown}"
  case "$ID_LC" in
    rhel|centos|rocky|almalinux)
      case "${VER%%.*}" in
        5) check_eol "RHEL-family" "$VER" "2017-03-31" ;;
        6) check_eol "RHEL-family" "$VER" "2020-11-30" ;;
        7) check_eol "RHEL-family" "$VER" "2024-06-30" ;;
        8) [ "$ID_LC" = "centos" ] && check_eol "CentOS" "$VER" "2021-12-31" || check_eol "RHEL-family" "$VER" "2029-05-31" ;;
        9) check_eol "RHEL-family" "$VER" "2032-05-31" ;;
        *) result="UNKNOWN" ;;
      esac ;;
    ubuntu)
      case "$VER" in
        14.04) check_eol "Ubuntu" "$VER" "2019-04-30" ;;
        16.04) check_eol "Ubuntu" "$VER" "2021-04-30" ;;
        18.04) check_eol "Ubuntu" "$VER" "2023-05-31" ;;
        20.04) check_eol "Ubuntu" "$VER" "2025-05-31" ;;
        22.04) check_eol "Ubuntu" "$VER" "2027-05-31" ;;
        24.04) check_eol "Ubuntu" "$VER" "2029-05-31" ;;
        *) result="UNKNOWN" ;;
      esac ;;
    debian)
      case "${VER%%.*}" in
        8) check_eol "Debian" "$VER" "2020-06-30" ;;
        9) check_eol "Debian" "$VER" "2022-06-30" ;;
        10) check_eol "Debian" "$VER" "2024-06-30" ;;
        11) check_eol "Debian" "$VER" "2026-08-31" ;;
        12) check_eol "Debian" "$VER" "2028-06-30" ;;
        *) result="UNKNOWN" ;;
      esac ;;
    sles|suse)
      case "${VER%%.*}" in
        11) check_eol "SLES" "$VER" "2019-03-31" ;;
        12) check_eol "SLES" "$VER" "2024-10-31" ;;
        15) check_eol "SLES" "$VER" "2031-07-31" ;;
        *) result="UNKNOWN" ;;
      esac ;;
    *) result="UNKNOWN"; detail="Unrecognized distro: $ID_LC $VER" ;;
  esac
elif [ "$(uname -s)" = "SunOS" ]; then
  REL=$(uname -r)
  case "$REL" in
    5.9)  check_eol "Solaris" "9"  "2014-10-31" ;;
    5.10) check_eol "Solaris" "10" "2021-01-31" ;;
    5.11) check_eol "Solaris" "11" "2034-11-30" ;;
    *) result="UNKNOWN" ;;
  esac
elif [ "$(uname -s)" = "AIX" ]; then
  REL=$(oslevel 2>/dev/null || echo unknown)
  case "$REL" in
    5.*|6.*) check_eol "AIX" "$REL" "2017-04-30" ;;
    7.1*)    check_eol "AIX" "$REL" "2023-04-30" ;;
    7.2*)    check_eol "AIX" "$REL" "2028-04-30" ;;
    7.3*)    check_eol "AIX" "$REL" "2033-04-30" ;;
    *) result="UNKNOWN" ;;
  esac
elif [ "$(uname -s)" = "Darwin" ]; then
  MAJ=$(sw_vers -productVersion 2>/dev/null | awk -F. '{print $1}')
  case "$MAJ" in
    10) check_eol "macOS" "$(sw_vers -productVersion)" "2020-11-01" ;;
    11) check_eol "macOS" "11" "2023-09-30" ;;
    12) check_eol "macOS" "12" "2024-11-30" ;;
    13) check_eol "macOS" "13" "2025-11-30" ;;
    14) check_eol "macOS" "14" "2026-11-30" ;;
    15) check_eol "macOS" "15" "2027-11-30" ;;
    *) result="UNKNOWN" ;;
  esac
fi

echo "[noisgate:33850] $result — $detail"
case "$result" in
  PATCHED)    exit 0 ;;
  VULNERABLE) exit 2 ;;
  *)          exit 1 ;;
esac
07 · Bottom Line

If you remember one thing.

TL;DR
Treat plugin 33850 as a fleet-wide lifecycle finding, not a single CVE. Monday morning: pull the full 33850 result set, join it to CMDB role tags, and split the population — hosts tagged domain controller, hypervisor, identity broker, backup server, CI/CD runner, or internet-facing edge appliance escalate to CRITICAL and enter the noisgate mitigation SLA window of ≤3 days (segment, EDR, credential rotation) with a noisgate remediation SLA target of ≤90 days for full migration. Everything else stays HIGH: apply compensating controls (segmentation, EDR, ESM/ELS contract) within the noisgate mitigation SLA of ≤30 days, and commit to full migration or extended-support enrollment within the noisgate remediation SLA of ≤180 days. Any host without a signed migration date at day 180 becomes a documented executive risk-acceptance — do not let EOL fleets grow silently in your exception register.

Sources

  1. Tenable plugin 33850 overview
  2. Tenable plugin 33850 dependencies
  3. Tenable plugin 33850 changelog
  4. Tenable Community — how to handle 33850
  5. NetApp KB — ONTAP flagged by plugin 33850
  6. endoflife.date — vendor EOL calendar
  7. CISA KEV catalog (for implied CVEs like pwnkit)
  8. Ubuntu Pro ESM overview
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.