SNMP agent vulnerabilities in embedded firmware: Net-SNMP and vendor agents, found and fixed

Two kinds, and they need different handling. Linux-based routers, gateways and many managed switches run Net-SNMP, which its own project page describes as a suite implementing "SNMP v1, SNMP v2c and SNMP v3" for monitoring "network equipment (eg. routers), computer equipment and even devices like UPSs." Its agent is snmpd, its trap receiver is snmptrapd, and both link against the libnetsnmp library. OpenWrt packages it, and vendor SDKs derived from OpenWrt inherit it.

PLCs, UPS network management cards, industrial switches and many RTOS-based devices instead compile a vendor SNMP stack, either in-house or licensed, into one monolithic firmware binary. There is no snmpd file to find and no upstream release notes to read; the stack's version is the firmware version, and fixes arrive only through the vendor's own advisories. The range of devices is wide. CERT/CC's 2002 note on SNMPv1 request handling, VU#854306, listed core network devices, broadband modems, printers, networked medical equipment, and "Manufacturing and Processing Equipment" among the places SNMP runs.

The same four classes recur across both kinds of agent. The table lists representative CVEs; the fixed version for Net-SNMP comes from the project's NEWS file or its GitHub security advisory.

Agent memory bugs. SNMP agents parse ASN.1/BER from the network, and that parser has been a source of bugs since the University of Oulu's PROTOS test suite found "denial-of-service conditions, format string vulnerabilities, and buffer overflows" across many vendors in 2002. CERT/CC's VU#854306 adds that "some vulnerabilities do not require the request message to use the correct SNMP community string." Net-SNMP's recent cases follow the same pattern. The advisory for CVE-2025-68615 says "a specially crafted packet to an net-snmp snmptrapd daemon can cause a buffer overflow and the daemon to crash," and lists all versions as affected, with 5.9.5 and 5.10.pre2 as the patched releases. This one is in the trap receiver, not the agent, so it matters only on devices that ship and run snmptrapd.

Default and hard-coded community strings. A community string is the only credential SNMPv1 and SNMPv2c have. Cisco's WAAS advisory shows why firmware analysis has to look inside the image, not at the device's visible configuration: the hard-coded read-only string sat "in the configuration file for the SNMP daemon," and was "not visible in the current operation configuration ('running-config') or the startup configuration ('startup-config')." CVE-2024-8450 describes a hard-coded SNMPv1 community on PLANET switches that gave read-write access. A device shipped with public and private is the same problem with a well-known string.

Cleartext SNMPv1 and SNMPv2c. This is a protocol property, not a bug. RFC 3410 states that SNMPv1 and SNMPv2c "support only trivial authentication based on plain-text community strings and, as a result, are fundamentally insecure," and that the SNMPv1 standard and the SNMPv2c specification were declared Historic for that reason. Anyone who can capture one request on the network has the community string and every value returned.

Write access abuse. Write access turns a monitoring protocol into a configuration channel. In Net-SNMP, CVE-2020-15862 meant SNMP write access to the EXTEND MIB "provides the ability to run arbitrary commands as root," per the NVD record; the fix commit makes "the extend mib read-only by default" and shipped in 5.9. Four of the six 2022 CVEs also need read-write credentials. A shared private community therefore gives an attacker the credential for those flaws as well.

In three places, and a device maker should watch all of them:

• Download page. The Net-SNMP download page lists 5.9.5.2 as the current supported release on 2026-11-13, 5.10.pre2 as the pre-release, and 5.8, 5.7.3 and older lines as end-of-line. The project's GitHub repository also carries a 5.10.rc1 tag dated 2026-11-07.
• NEWS file. The NEWS file names the CVE fixed in each release. It lists the six 2022 CVEs under 5.9.3, while the CVE records say "prior to version 5.9.2"; NEWS explains that 5.9.2 was "skipped due to a last minute library versioning found bug -- use 5.9.3 instead."
• GitHub security advisories. Newer issues are published as repository advisories, such as GHSA-4389-rwqf-q9gq for CVE-2025-68615, with the patched versions and a CVSS vector.

For the 2022 set, the 5.9.3 NEWS entry gives this guidance: "use strong SNMPv3 credentials and do not share them. If you must use SNMPv1 or SNMPv2c, use a complex community string and enhance the protection by restricting access to a given IP address range." For CVE-2025-68615, the advisory says "SNMP ports should never be open to public networks" and gives no other mitigation than firewalling snmptrapd or upgrading.

Vendor stacks publish fixes only through the vendor. Cisco's advisory for CVE-2025-20352 is a typical example. It lists "no workarounds" and a mitigation that excludes the affected OIDs from SNMP views. It also records that Cisco's PSIRT "became aware of successful exploitation of this vulnerability in the wild after local Administrator credentials were compromised."

Rank by reachability first: is the agent running, which interfaces does it listen on, and which credentials does the attacker need? Then use exploitation data, and the CVSS base score last. Exploitation data: CISA KEV catalog version 2026.11.10 and FIRST EPSS scores dated 2026-11-12.

On 2026-11-10 the KEV catalog listed eleven SNMP vulnerabilities. All were in Cisco's own SNMP code, in IOS, IOS XE and ASA, and none was a Net-SNMP CVE. That does not make Net-SNMP safe: EPSS rates CVE-2025-68615 in the 98.7th percentile. It does show that SNMP agent code is exploited in practice, and that the confirmed cases so far sit in vendor stacks, which only the vendor can fix. Our KEV and EPSS prioritisation guide covers how the two signals combine, and CVSS v4 vs v3.1 covers why base scores need environmental context.

Exposure decides the rest. An agent that answers on a WAN interface makes every credential-free bug internet-reachable. The same agent bound to an isolated management VLAN does not. Our guide to CISA BOD 23-02 covers why management interfaces should not face the internet.

SNMPv3 splits security into two models, and a device needs both configured.

USM authenticates and encrypts. The User-based Security Model in RFC 3414 defines three security levels: noAuthNoPriv, authNoPriv and authPriv. Ship authPriv. RFC 3414 itself defines MD5 and SHA-1 authentication and DES privacy; RFC 3826 adds AES, and RFC 7860 adds HMAC-SHA-2 authentication. USM also localises each key: the user's key is hashed together with the agent's snmpEngineID, so "the actual secrets shared between the user and each authoritative SNMP engine will be different." That protection holds only if engine IDs differ. Net-SNMP's snmpd.conf manual says the engine ID is normally built from "a (pseudo-)random number and the current time in seconds," and calls that "the recommended approach." Do not hard-code an engineID line into the image.

VACM decides what each user may see and change. The View-based Access Control Model in RFC 3415 maps users to groups and groups to read, write and notify views. It defines three initial configurations: "initial-minimum-security-configuration", "initial-semi-security-configuration" and "initial-no-access-configuration." In the minimum-secure option, the restricted view is the whole "internet" subtree. The no-access option, which has no initial configuration at all, is the right factory state for a product, with access created at commissioning.

In Net-SNMP, a minimal product configuration looks like this, with the user created per device during commissioning rather than baked into the image:

# Listen on the management interface only
agentaddress udp:192.0.2.10:161

# Read-only view of the subtrees the NMS actually polls
view monitor included .1.3.6.1.2.1.1
view monitor included .1.3.6.1.2.1.2
view monitor included .1.3.6.1.2.1.31

# SNMPv3 user, authPriv, read-only, restricted view
rouser -s usm nms_ro priv -V monitor

# No rocommunity / rwcommunity / extend / exec / pass lines

The address is a documentation example. Create the user with createUser in the persistent file or with net-snmp-config --create-snmpv3-user; the manual explains that the passphrase line is read once and then replaced with the localised key. The 5.9.5.2 manual source lists SHA-224 to SHA-512 as authentication options and adds that SHA authentication and DES or AES privacy "require OpenSSL to be installed and the agent to be built with OpenSSL support. MD5 authentication may be used without OpenSSL." On OpenWrt-based firmware, that means the snmpd-nossl variant cannot offer SHA authentication or any privacy at all.

Patch the agent, change the defaults, restrict exposure, then rebuild and re-scan to prove the result.

Patch. For Net-SNMP, move to 5.9.5.2, or to 5.9.5 as a minimum for CVE-2025-68615. A device on 5.8 or older also carries the 2022 set, CVE-2020-15862 and, below 5.8, CVE-2018-18065; at that point upgrading is usually less work than a backport stack. For a vendor stack, the fix is a firmware release from whoever owns the code, so ask your SNMP stack supplier for its advisory feed and fixed versions.

Harden the defaults. Each of these removes a whole class of risk:

Our hard-coded credentials guide covers per-device credential provisioning in general, and our memory corruption guide covers the parser bug class behind the agent CVEs.

Release with evidence. Regenerate the SBOM, confirm that the new Net-SNMP version or patch level is what actually shipped, and publish affected versions, fixed version and the CVE list. If your build never ships snmptrapd, say so, and mark CVE-2025-68615 "not affected" with that justification in a VEX statement; our CSAF and VEX for device makers guide shows the format. The same method applies to the other daemons that usually sit beside snmpd; see our guides on dnsmasq, BusyBox and OpenSSL in embedded firmware.

SoftWSP's automated scan unpacks a firmware image, catalogs the software packages in the extracted file system with their versions, and matches each one against CVE records, CISA's KEV catalog and FIRST's EPSS scores. On OpenWrt-style images, the opkg records for packages such as snmpd and libnetsnmp carry the Net-SNMP version, and the package revision is stripped before matching. This is deterministic code: the code scores, and AI narrates.

AI's part is the written explanation on top of that matching. It summarises which CVEs matched, which are KEV-listed or have a high EPSS score, and what the version evidence was, and every sentence cites the component, version and record it relies on. An engineer reviews every finding before the report is delivered. The judgements this guide describes as manual stay with that engineer: reading snmpd.conf for communities, write views and extend lines, searching the image for hard-coded strings, checking whether snmptrapd actually runs, confirming that a package such as snmpd maps to NVD's Net-SNMP product entry, and recognising a vendor SNMP stack compiled into a monolithic RTOS image, which version matching cannot see as a separate component.

For where SNMP review fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide, or device & firmware security services to have a specific image reviewed.

This guide draws on the Net-SNMP project page, download page, NEWS file, snmpd.conf manual, GitHub security advisory and commit history, RFC 3410, 3414, 3415, 3826 and 7860, CERT/CC VU#854306 and VU#107186, Cisco advisories cisco-sa-snmp-x4LPhte and cisco-sa-20180606-waas-snmp, OpenWrt's net-snmp package files, NVD, CISA's KEV catalog (version 2026.11.10) and FIRST EPSS data dated 2026-11-12, all read directly on 2026-11-13.