CVE-2026-89147 in Net-SNMP
Summary
by MITRE • 09/11/2026
Net-SNMP through 5.9.5.2 contains a denial of service vulnerability in the SMUX module where smux_accept() performs an unauthenticated blocking read without timeout on newly accepted connections. An unauthenticated remote client can connect to the SMUX listener and send no data, causing the single-threaded snmpd main loop to block indefinitely and suspend all SNMP processing.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in Net-SNMP versions through 5.9.5.2 represents a critical denial of service flaw within the Subagent Multiplexing protocol implementation. This issue specifically affects the SMUX module, which is responsible for managing connections between the main SNMP agent and external subagents that provide additional management information. The core technical defect lies in the smux_accept() function, which handles incoming connection requests from remote clients or subagents. When a new connection is accepted by this routine, it initiates an unauthenticated blocking read operation without implementing any timeout mechanism. This design oversight means that once a TCP connection is established with the SMUX listener port, the system expects immediate data transmission to proceed with the handshake and subsequent communication protocols defined by the SMUX specification.
An attacker can exploit this flaw by establishing a valid TCP connection to the targeted SNMP service on the designated SMUX port but deliberately withholding any further data transmission. Because the smux_accept() function waits indefinitely for input, it holds up the execution flow of the main snmpd process loop. In many standard configurations and default builds of Net-SNMP, the primary agent operates in a single-threaded or event-driven model where blocking on one connection prevents the processing of other pending requests. Consequently, this action effectively freezes the entire SNMP daemon, rendering it incapable of responding to legitimate management queries, configuration changes, or monitoring data collection from network management systems such as Nagios, Zabbix, or SolarWinds.
The operational impact of this vulnerability is severe for any infrastructure relying on Net-SNMP for centralized device management. Since the main loop becomes suspended, all SNMP traffic directed at that host ceases to be processed until the process is manually restarted or killed by an administrator with appropriate privileges. This results in a complete loss of visibility and control over the affected system within the network monitoring ecosystem. For critical infrastructure components such as routers, switches, servers, or industrial control systems managed via SNMP, this outage can lead to significant operational disruptions, delayed incident response capabilities, and potential cascading failures if dependent services rely on real-time health checks provided by the compromised agent.
From a classification perspective, this vulnerability aligns with CWE-400, which denotes Uncontrolled Resource Consumption, specifically manifesting as resource exhaustion through thread or process blocking. It also maps to MITRE ATT&CK technique T1499, Endpoint Denial of Service, where an adversary disrupts the availability of targeted components by consuming resources such that useful service is denied to legitimate users. The lack of authentication required for exploitation further exacerbates the risk profile, as it allows any remote actor with network access to the SNMP port to trigger this condition without needing valid credentials or prior compromise of the host system.
Mitigation strategies should prioritize immediate patching to a version of Net-SNMP that addresses this blocking behavior by implementing appropriate timeouts on SMUX connections. Administrators who cannot immediately apply patches can mitigate the risk by restricting network access to SNMP ports using firewall rules, ensuring that only trusted management stations and authorized subagents are permitted to connect to port 199 or other configured SMUX endpoints. Additionally, deploying the agent in a multi-threaded mode where available may isolate such blocking calls from the main event loop, although this depends on specific build configurations and is not guaranteed across all distributions. Regular auditing of SNMP access control lists and disabling unnecessary subagent services can further reduce the attack surface associated with this vulnerability.