CVE-2026-89147: Net-SNMP SMUX Module DOS Vulnerability

CVE-2026-89147 Overview

CVE-2026-89147 is a denial of service vulnerability in Net-SNMP through version 5.9.5.2. The flaw resides in the SNMP Multiplexing (SMUX) module, where smux_accept() performs an unauthenticated blocking read on newly accepted connections without any timeout. An unauthenticated remote attacker can open a TCP connection to the SMUX listener and send no data, which causes the single-threaded snmpd main loop to block indefinitely. All SNMP processing is suspended for the duration of the stall, disabling monitoring, alerting, and management operations that depend on the agent. The weakness is classified under CWE-400 (Uncontrolled Resource Consumption).

Critical Impact
A single unauthenticated TCP connection to the SMUX port halts all SNMP processing on the affected agent, blinding infrastructure monitoring systems.

Affected Products

Net-SNMP versions up to and including 5.9.5.2
Systems with the SMUX module compiled in and the SMUX listener enabled
Network devices, servers, and appliances embedding vulnerable Net-SNMP builds

Discovery Timeline

2026-09-11 - CVE-2026-89147 published to NVD
2026-09-15 - Last updated in NVD database

Technical Details for CVE-2026-89147

Vulnerability Analysis

Net-SNMP is a widely deployed SNMP agent used to monitor network devices, servers, and applications. The SMUX (SNMP Multiplexing) protocol, defined in RFC 1227, allows subagents to register with the main snmpd agent over TCP. The vulnerable code path lives in agent/mibgroup/smux/smux.c inside the smux_accept() function.

When a new TCP client connects to the SMUX listener, snmpd accepts the connection and issues a blocking read() call to retrieve the initial SMUX PDU. The read does not set a socket timeout and does not use non-blocking I/O with a poll loop. If the client never sends data, the read never returns.

Because snmpd runs as a single-threaded event loop, the stalled read blocks the entire agent. All queued SNMP GET, GETNEXT, GETBULK, SET, and trap operations are suspended until the client disconnects or the underlying TCP stack tears down the socket. Legitimate polling by network management systems fails during this window.

Root Cause

The root cause is missing input timeout handling on an unauthenticated network endpoint. smux_accept() trusts that a connecting client will promptly send a valid SMUX Open PDU, and it commits the main event loop to waiting on that read. No SO_RCVTIMEO, select(), or poll() gating is applied before the blocking call, so a slow or silent peer converts a single connection into a full agent stall.

Attack Vector

Exploitation requires only network reachability to the SMUX TCP port (default 199/tcp) on a host running a vulnerable snmpd with SMUX enabled. An attacker opens a TCP connection, completes the three-way handshake, and then sends nothing. The snmpd process enters the blocking read in smux_accept() and remains stalled. The attack is unauthenticated, requires no user interaction, and can be repeated or held open to sustain the outage. Public proof-of-concept material is referenced in the VulnCheck Advisory for Net-SNMP and a GitHub Gist PoC.

No verified exploit code is reproduced here. The mechanism is a TCP connect to port 199/tcp followed by silence on the wire, as described in the Net-SNMP Source Code advisory references.

Detection Methods for CVE-2026-89147

Indicators of Compromise

Unexpected inbound TCP connections to port 199/tcp from untrusted networks or non-SMUX peers.
Long-lived TCP sessions to the SMUX port with zero bytes transferred from the client after the handshake.
snmpd process appearing responsive to ps but unresponsive to SNMP polls from network management systems.

Detection Strategies

Monitor SNMP polling success rates and alert on sudden drops in successful GET responses from snmpd hosts.
Inspect network flow data for connections to 199/tcp originating outside the expected SMUX subagent inventory.
Correlate snmpd process CPU idleness with a pending connection state on the SMUX socket to identify stalled reads.

Monitoring Recommendations

Enable flow logging on segments where SNMP agents reside and baseline legitimate SMUX peers.
Track snmpd uptime, restart events, and poll latency in your observability platform.
Alert on any inbound TCP connection to 199/tcp from a source address that is not on the SMUX allow list.

How to Mitigate CVE-2026-89147

Immediate Actions Required

Disable the SMUX module in snmpd.conf if SMUX subagents are not in use by removing or commenting the smuxpeer directive and any smuxsocket binding.
Block inbound access to TCP port 199 at the host firewall and at network perimeter devices, permitting only authorized SMUX peers.
Restart snmpd after configuration changes and verify the SMUX listener is no longer bound with ss -ltnp or netstat -ltnp.

Patch Information

At the time of publication, upstream fix details are tracked through the Net-SNMP Repository and the VulnCheck Advisory for Net-SNMP. Administrators should upgrade to a Net-SNMP release later than 5.9.5.2 that introduces a socket timeout or non-blocking accept path in smux_accept(). Distribution-provided backports should be applied as they become available.

Workarounds

Bind the SMUX listener to 127.0.0.1 using smuxsocket 127.0.0.1 so remote attackers cannot reach the port.
Restrict TCP 199/tcp with host-based firewall rules (for example, iptables or nftables) to a strict allow list of subagent hosts.
Run snmpd behind a network segmentation boundary that prevents untrusted networks from initiating TCP connections to management services.

bash

# Configuration example: disable SMUX exposure in snmpd.conf
# 1. Bind SMUX to loopback only
smuxsocket 127.0.0.1

# 2. Or, if SMUX is not needed, ensure no smuxpeer entries exist
# (comment out any existing smuxpeer lines)
# smuxpeer .1.3.6.1.4.1.3.1.1 secret_password

# 3. Firewall the SMUX port at the host level
iptables -A INPUT -p tcp --dport 199 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 199 -j DROP

# 4. Restart the agent and verify the listener
systemctl restart snmpd
ss -ltnp | grep ':199'