CVE-2026-89147

What it actually does

Net-SNMP through 5.9.5.2 has a denial-of-service flaw in the SMUX module: smux_accept() issues an unauthenticated blocking read with no timeout on newly accepted sockets. Because snmpd is single-threaded, one idle TCP connection to the SMUX listener parks the main loop indefinitely, suspending SNMP query handling, trap processing, and related agent work until the connection drops or the daemon is restarted. Confidentiality and integrity of SNMP data are not affected; availability of the agent is fully impacted.

Why it matters to the business

SNMP-based monitoring, inventory, and alerting can go dark while snmpd still appears to be running, creating a silent operations outage rather than an obvious crash. Network and infrastructure teams lose live telemetry, miss capacity and fault signals, and may delay incident response. The issue is not listed in CISA KEV, is not associated with ransomware, and has a low, flat EPSS (~0.0049 over 30 days) with no public exploit maturity, so mass opportunistic exploitation is not currently indicated. Residual risk remains wherever SMUX is enabled and reachable from untrusted networks, especially on shared or internet-facing management planes. The advisory has been public for about a month, so unpatched agents should be treated as an availability debt, not an emergency ransomware event.

How an attack unfolds

An unauthenticated remote attacker who can reach the SMUX listener (commonly TCP/199) completes a TCP handshake and then sends no SMUX protocol data. The agent blocks in smux_accept() and stops servicing all SNMP clients. No credentials, malformed packets, or code execution are required. With exploit maturity reported as none and no named threat actors tied to this CVE, observed use would most likely be opportunistic disruption or a precursor to hiding other activity by blinding SNMP monitoring—not a known APT or ransomware playbook. Holding or repeating the idle connection keeps the outage in place until operators restart snmpd, kill the session, or block the source.

How to fix it

Prefer a vendor-fixed Net-SNMP build newer than 5.9.5.2 once your distribution or upstream publishes it; this input does not list exact patched package versions, so track distro security advisories and changelog notes for SMUX accept/timeout handling. If SMUX is not required, disable the SMUX module and stop listening on the SMUX port. Restrict remaining SMUX/SNMP management access to trusted management networks with host firewalls and ACLs (deny untrusted sources to TCP/199 and unused SNMP endpoints). Run snmpd with the least privilege and chroot/jail options your platform supports, and ensure process supervisors restart a wedged agent. Until a patch is installed, treat any host with SMUX enabled as availability-sensitive and keep it off untrusted networks.

How to confirm the fix worked

Inventory snmpd versions and confirm whether SMUX is compiled in and enabled (configuration and listening sockets, especially TCP/199). After upgrade or SMUX disablement, verify the daemon still answers authorized SNMP requests under load and that the SMUX port is closed or filtered. Review package changelogs for a SMUX accept/timeout fix rather than relying on version strings alone when distro backports are in use. Do not validate by attempting to stall production agents; use staging hosts, configuration review, and listening-port checks. Confirm firewall/ACL changes with policy tests that authorized management still works and unauthorized sources cannot complete a session to SMUX.

Typical attack path

1. Identify hosts exposing the SMUX listener (typically TCP/199) or otherwise running SMUX-enabled snmpd on a reachable network path.
2. Open a TCP connection to that listener as an unauthenticated client.
3. Withhold SMUX protocol data so the blocking read in smux_accept() never returns.
4. Leave the idle session established so the single-threaded snmpd main loop remains stalled and SNMP processing stays suspended.
5. Optionally maintain or re-establish idle connections after restarts or timeouts to prolong the monitoring outage.

How to detect it

Look for availability loss without a crash: snmpd remains in the process table but stops answering GET/WALK/traps while a TCP session sits idle on the SMUX listener (often port 199). Useful sources include host netstat/ss, firewall connection logs, packet captures showing a completed handshake with no SMUX payload, process state (blocked in accept/read), supervisor restart storms, and NMS/poller logs showing sudden timeouts to many agents from one source. There are no public in-the-wild campaigns or named actors for this CVE, so hunt for the behavior rather than actor-specific malware. Correlate first-seen idle SMUX connections with the start of SNMP polling failures. After recovery, preserve the remote IP, start time, and duration of the hanging socket.

• tcp dport 199
• SMUX
• smux_accept
• snmpd
• NMS timeout OR SNMP timeout OR polling timeout
• ss/netstat ESTABLISHED idle to *:199
• process snmpd blocked in read/accept
• connection to UDP/161 succeeding at TCP layer but agent not responding while snmpd PID alive

What your security team should do

• Immediately identify Net-SNMP/snmpd deployments through 5.9.5.2 and whether SMUX is enabled or TCP/199 is reachable from untrusted networks.
• Disable SMUX everywhere it is unused; firewall remaining SMUX listeners to management networks only.
• Patch to a vendor-fixed release newer than 5.9.5.2 as soon as packages are available; do not wait on KEV/EPSS given the trivial unauthenticated availability impact.
• Add monitoring for snmpd that is running but not answering SNMP, and for long-lived idle TCP sessions to the SMUX port.
• Prioritize internet-exposed or poorly segmented management planes; this is not a KEV/ransomware item, but it can blind detection and operations if left open.