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 · Compensating Control
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.
04 · Intelligence Metadata
The supporting signals.
| Finding type | Informational lifecycle detection, not a single CVE — plugin unsupported_operating_system.nasl v1.297 |
|---|---|
| Vendor severity / score | Tenable CRITICAL / CVSS 10.0 (policy placeholder, not measurement) |
| CVSS vector | CVSS: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 status | EOL Linux hosts are a favorite target of ransomware crews (Cl0p, LockBit, BlackCat) and initial-access brokers per Mandiant M-Trends 2025 |
| Proof-of-concept | N/A directly — but PoCs exist for every frozen CVE the OS can no longer receive (pwnkit, Dirty Pipe, regreSSHion, Baron Samedit, etc.) |
| EPSS | Not applicable — not a CVE; underlying CVEs like CVE-2024-6387 have EPSS >0.5 |
| KEV status | The 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) |
| Fix | Upgrade 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 updated | Published 2008-08-08, last updated 2025-09-23 |
Sources.
05 · The Call
Final Verdict
↓ DOWNGRADED to HIGH (8.5/10)
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.
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.
#!/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