Port 162 – SNMP Trap (SNMP Notifications)

Port 162 is the default UDP port an SNMP manager (trap receiver) listens on to catch traps — the asynchronous, device-initiated notifications an SNMP agent fires when something happens, like an interface dropping or a device rebooting. It’s the mirror image of SNMP polling on port 161: on 161 the manager queries the agent, while on 162 the agent pushes alerts up to the manager — and with SNMPv2c/v3 informs, the manager acknowledges them back. Because SNMPv1 and v2c carry those traps in cleartext with only a plaintext community string, an exposed port 162 lets an attacker forge alerts, sniff community strings, or feed a malformed trap straight into the monitoring console.

Why It’s Open

Every monitoring stack needs somewhere to send device alerts, and that somewhere listens on UDP 162. On Linux the receiver is usually Net-SNMP’s snmptrapd; commercial and open-source managers — SolarWinds, PRTG, Zabbix, LibreNMS, Observium, Nagios — run their own trap listeners on the same port. Agents on routers, switches, firewalls, UPS units, and IoT sensors are configured with a trap destination and fire notifications there whenever a threshold trips. Where 162 is listening, its relatives are usually nearby: SNMP polling on 161 for the query side, SMUX on TCP 199 for subagent multiplexing, and syslog on UDP 514 as the other big event-collection port on the same monitoring host.

Common Risks

• Spoofed / forged traps. SNMPv1 and v2c traps are unauthenticated UDP — the source IP can be spoofed, so anyone who can reach port 162 can inject fake alerts. That poisons the NOC console: it can bury a real incident under noise, trip false automation and paging, or wear out responders with alert fatigue.
• Cleartext community strings. In v1/v2c the community string and every varbind cross the wire unencrypted. Sniffing trap traffic hands an attacker a valid string they can replay against the agent on port 161 for full read (or write) access.
• Trap-receiver parsing bugs. A malformed trap can crash or exploit the manager itself. Net-SNMP’s snmptrapd carried a critical buffer overflow (CVE-2025-68615), and LibreNMS could be driven to remote code execution by a single spoofed trap (CVE-2022-4069).
• Information disclosure from verbose traps. Traps carry hostnames, interface indexes, error detail, and sometimes sensitive varbinds — useful reconnaissance for anyone sniffing the segment.
• Over-trusting the alert. Unlike the query side on 161, a trap is pushed, so it isn’t a classic amplification reflector — the real danger is a manager that trusts and acts on notifications it never authenticated.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Check whether a trap receiver is listening

nmap -sU -p 162 <target>          # open|filtered is normal for UDP — confirm with a real trap

Run a local trap receiver to observe traffic

snmptrapd -f -Lo -c /etc/snmp/snmptrapd.conf   # foreground, log every trap to stdout

Forge and send a test trap (SNMPv2c)

# Prove the manager accepts an unauthenticated trap from an arbitrary source
snmptrap -v2c -c public <manager> '' 1.3.6.1.6.3.1.1.5.3 \
  ifIndex i 2 ifAdminStatus i 1 ifOperStatus i 2   # a spoofable "linkDown"

Send an INFORM (acknowledged notification)

snmpinform -v2c -c public <manager> '' 1.3.6.1.6.3.1.1.5.3   # manager replies if it accepts it

Sniff traps on the wire

tshark -i eth0 -f "udp port 162" -Y snmp   # v1/v2c community string + varbinds are cleartext

Note: the standard Metasploit SNMP modules (snmp_enum, snmp_login, snmp_set) target the agent on 161 — there is no dedicated trap-send module, so use Net-SNMP’s snmptrap/snmpinform to test the receiver. Log every accepted forged trap and every community string you sniff so it lands in the pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

• CVE-2002-0012 — The classic PROTOS/OUSPG finding on the trap side: flaws in the SNMPv1 trap handling of a huge range of implementations allow denial of service or privilege gain. CVSS 10.0, published alongside CERT advisory CA-2002-03 after the PROTOS c06-SNMPv1 test suite broke nearly every SNMP stack in existence. Its sibling CVE-2002-0013 covers the request side handled on the port 161 agent.
• CVE-2025-68615 — A specially crafted packet to Net-SNMP snmptrapd triggers a stack buffer overflow. A “fast path” in the trap handler trusts the length of the snmpTrapOID varbind without checking its type, so a type-confused binding (an OCTET STRING where an OBJECT ID is expected) drives a memcpy past a 520-byte buffer. Unauthenticated, network-reachable, CVSS 9.8; fixed in 5.9.5 / 5.10.pre2.
• CVE-2022-4069 — LibreNMS ≤ 22.10.0. The HpFault trap handler copies an attacker-controlled value into the event type, which is then rendered unescaped in the eventlog. As Sonar documented, a spoofed SNMP trap plants a stored XSS payload that chains through the Alert Templates (Blade/PHP) feature to remote code execution. NVD classes it as XSS (CVSS 4.8); fixed in 22.11.0.

Mitigation

• Move notifications to SNMPv3. v3 authPriv adds authentication and encryption; use INFORM with engine authentication so the receiver actually validates the sender instead of trusting a spoofable v1/v2c trap.
• Firewall UDP 162 to known agents. Restrict the trap port with an ACL so only your monitored devices can reach the manager. Port 162 should never be exposed to the internet.
• Validate and rate-limit at the manager. Drop traps from unknown sources, rate-limit floods, and never auto-action (page, reboot, script) on an unauthenticated notification.
• Patch the trap receiver. Keep snmptrapd at 5.9.5 or later, LibreNMS at 22.11.0 or later, and any commercial NMS current — the receiver is code that parses hostile input.
• Encode trap contents before display. Never render raw trap fields into a console or eventlog without escaping, so a malicious varbind can’t become stored XSS.
• Block spoofed sources at the edge. Anti-spoofing (BCP 38) stops off-network hosts from forging traps that appear to come from a monitored device — the same hygiene that protects syslog on 514.

Real-World Example

In 2022, Sonar’s researchers showed how a single SNMP trap could take over a LibreNMS monitoring server (CVE-2022-4069). Because SNMPv1/v2c traps are unauthenticated UDP, an attacker who knew the address of any monitored device could spoof its source IP and send a crafted trap to the listener on port 162. The HpFault handler wrote the attacker’s data into the eventlog event type without encoding it, planting a stored cross-site-scripting payload. The moment an administrator opened the eventlog dashboard, that JavaScript ran in their session and abused LibreNMS’s Alert Templates — which compile Blade templates and can execute PHP — to drop a reverse shell. It’s the textbook port-162 case: no agent was breached and no password was guessed; the compromise started with the monitoring platform trusting a notification it never authenticated.

FAQ

What is port 162 used for?

Port 162 is the UDP port an SNMP manager (trap receiver) listens on to receive traps — asynchronous notifications an SNMP agent sends when an event occurs, such as an interface going down or a device restarting. It’s the alerting side of SNMP: devices push events to the manager on 162, rather than the manager polling them.

What is the difference between port 161 and 162?

Port 161 is where the agent listens and the manager polls it with GET/SET requests. Port 162 is where the manager listens for traps the agent pushes on its own when something happens. In short: 161 is manager-to-agent queries, 162 is agent-to-manager alerts. See the port 161 page for the query side.

Is port 162 TCP or UDP?

SNMP traps use UDP 162 by default, which is why a trap can be silently lost and why the source address can be spoofed. Some managers can be configured to receive traps over TCP 162, but virtually all real-world trap traffic is UDP.

What is an SNMP trap, and how is it different from an inform?

A trap is a fire-and-forget notification: the agent sends it and never knows whether the manager received it. An inform (SNMPv2c/v3) is an acknowledged notification — the manager sends a response, so the agent can retry if it’s lost. With SNMPv3, informs can also carry engine authentication, which is what makes them far harder to spoof than a plain v1/v2c trap.

Is port 162 dangerous?

It’s lower-severity than the query side on 161, but not harmless. If it accepts unauthenticated v1/v2c traps, an attacker can forge alerts to mislead or overwhelm the NOC, sniff community strings off the wire, and — against an unpatched receiver like snmptrapd (CVE-2025-68615) or LibreNMS (CVE-2022-4069) — crash or take over the monitoring host itself.

How do I secure or close port 162?

Move notifications to SNMPv3 authPriv and use authenticated informs, firewall UDP 162 so only known agents can reach the manager, drop and rate-limit traps from unknown sources, and keep the trap receiver patched. If nothing sends you traps, disable the listener and confirm with nmap -sU -p 162.

TL;DR

• Service: SNMP trap / notification receiver (snmptrapd, SNMP managers)
• Default port: 162/UDP (polling on 161, SMUX on 199)
• Biggest risk: forged/spoofed traps poisoning the NOC and cleartext v1/v2c community strings, plus trap-receiver parsing bugs (CVE-2025-68615, CVE-2022-4069)
• Mitigation: SNMPv3 authPriv + authenticated informs, firewall 162 to known agents, validate/rate-limit traps, and patch the receiver