← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-20185 · CWE-122 · Disclosed 2026-05-06

Cisco SG350 and SG350X Series Managed Switches SNMP Denial of Service Vunerability

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a hidden reset button behind a locked closet door, not a street-facing break-in

CVE-2026-20185 is a heap-based SNMP parsing bug in Cisco SG350 and SG350X managed switches that can force an unexpected reload. Cisco says the known-affected population is narrower than the headline suggests: firmware 2.5.9.54 or 2.5.9.55, on listed SG350-28P / 28MP / 52P / 52MP and SG350X series devices, with two or more 60-watt PoE ports enabled, and with SNMP v1/v2c/v3 enabled.

Cisco's 7.7/HIGH baseline is technically fair for 'network-triggered outage on infrastructure gear,' but it overstates most enterprise exposure. The bug is authenticated-only, usually reachable only on the management plane, and gated by a specific hardware and PoE configuration; that makes it a post-initial-access, narrow-population DoS in real fleets. It still matters because a single successful trigger can bounce a branch or closet switch, and there is no vendor patch because the product line is past software maintenance.

"Real risk is post-auth SNMP on a narrow, EOL switch subset; serious for affected branches, not a broad internet fire."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Reach the SNMP management plane

The attacker needs Layer 3 reachability to UDP/161 on the target switch. In practice this means access from an internal management network, VPN, jump host, or already-compromised monitoring segment; the bug is not useful if SNMP is disabled or tightly ACLed. Typical tooling is nmap or a basic SNMP client to confirm the service is listening.
Conditions required:
  • Target is a Cisco SG350 or SG350X switch
  • SNMP service is enabled
  • Attacker can reach UDP/161 on the device
Where this breaks in practice:
  • Most enterprises keep switch SNMP off the public internet
  • Management VRFs, ACLs, NGFW rules, and jump-host design often isolate UDP/161
  • Branch switches may only answer SNMP from an NMS subnet
Detection/coverage: External attack-surface tools may find exposed SNMP, but generic CVE scanners cannot prove this bug without config context. Internal network scans can confirm SNMP exposure, not exploitability.
STEP 02

Obtain valid SNMP access

Cisco states exploitation requires valid SNMP credentials: a read-only or read-write community string for SNMPv1/v2c, or valid SNMPv3 user credentials. An attacker typically gets this from prior compromise, config backup theft, weak/default community practices, or credential reuse. Weaponized tooling here is usually snmpwalk, snmpget, or any SNMP library once credentials are known.
Conditions required:
  • Valid SNMPv1/v2c community string or SNMPv3 credentials
  • The credential is accepted by the target switch
Where this breaks in practice:
  • This is not unauthenticated remote exploitation
  • SNMPv3 with auth/privacy materially raises the bar
  • Credential vaulting, AAA hygiene, and config management reduce credential leakage
Detection/coverage: Authentication attempts may be visible in switch logs or on the NMS side, but many orgs do not centrally monitor SNMP auth failures well. Credentialed vuln scanners usually know only that SNMP is enabled, not that the exact trigger is present.
STEP 03

Hit the narrow affected configuration

The advisory adds a non-obvious gate: the device must be on 2.5.9.54 or 2.5.9.55 and have two or more 60W PoE ports configured. The vulnerable object is in the PoE MIB path, and Cisco's mitigation works by excluding the affected OID from SNMP views. Attackers can enumerate MIB support with standard SNMP tools before attempting the crash.
Conditions required:
  • Firmware version is 2.5.9.54 or 2.5.9.55
  • Model is in the vulnerable SG350/SG350X set
  • At least two interfaces are configured with power inline limit 60000
Where this breaks in practice:
  • This is a small subset of the already-EOL product family
  • Non-PoE or lower-power deployments do not meet the trigger condition
  • Cisco's OID-exclusion mitigation blocks the vulnerable MIB path even without a patch
Detection/coverage: This is where scanner coverage gets weak. You need CLI config inspection or a very product-aware audit check to validate the version plus PoE gate plus SNMP exposure.
STEP 04

Send the crafted SNMP request

Using a standard SNMP client or custom packet generation, the attacker sends the specific request that exercises the buggy parser path. Cisco says the issue is improper error handling when parsing response data for a specific SNMP request. A successful hit causes the switch to reload unexpectedly.
Conditions required:
  • All prior reachability, credential, and config prerequisites are satisfied
  • Target has not implemented the OID-exclusion mitigation
Where this breaks in practice:
  • No public PoC was found in web or GitHub searches as of 2026-05-30
  • The exact trigger is not published in Cisco's advisory
  • Reliability outside lab-matched configurations is unproven publicly
Detection/coverage: Network IDS signatures are unlikely unless someone publishes a stable trigger. The most reliable detection is the device reload plus pre-reload SNMP activity from an unusual source.
STEP 05

Exploit the outage window

Impact is availability only: the switch reloads and traffic through it drops until recovery. On a branch core, closet aggregate, or PoE-heavy voice/camera switch, that can create a real local outage, but the blast radius is usually one device or one site rather than domain-wide compromise.
Conditions required:
  • Target switch is operationally important in the path
  • Reload causes service interruption for attached endpoints or uplinks
Where this breaks in practice:
  • No confidentiality or integrity impact is documented
  • Redundant uplinks, stack design, and resilient campus topology can blunt user impact
  • Many SG350 deployments are edge/branch rather than central data-center switching
Detection/coverage: NMS alerts, syslog, interface flaps, and device-up/down telemetry should catch the outage quickly. Availability monitoring is stronger here than pre-exploit prevention.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusCisco PSIRT says it is not aware of any public announcements or malicious use of this flaw, and I found no KEV entry as of 2026-05-30.
Public exploit / PoCI found no public GitHub PoC or weaponized write-up for CVE-2026-20185. Public coverage is mostly advisory aggregation and news summaries, not exploitation research.
EPSS0.00216 from the user-supplied intel block, which is a low exploitation-likelihood signal. Third-party mirrors around publication also showed EPSS in the same low band.
KEV / CISA statusNot KEV-listed. CISA's ADP enrichment on the CVE record marks Exploitation: none, Automatable: no, Technical Impact: partial.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H says network reachable with low complexity and high availability impact, but the important real-world suppressor is PR:L on the SNMP management plane.
Affected versionsCisco lists SG350-28P, SG350-28MP, SG350-52P, SG350-52MP, and SG350X series running firmware 2.5.9.54 or 2.5.9.55, with two or more 60W PoE ports enabled.
Fixed versionNone. Cisco says these products are past End of Software Maintenance Releases and will not receive software updates for this issue.
Mitigation pathCisco's mitigation is to create an SNMP view that excludes the vulnerable OID: snmp-server view SNMP_DOS iso included and snmp-server view SNMP_DOS rlPethPsePortTable excluded, then bind that view to all communities or SNMPv3 groups.
Scanning / exposure dataI found no product-specific Shodan/Censys/FOFA census for SG350/SG350X tied to this CVE. As a proxy, Censys reported 192,038 internet-accessible Cisco SNMP services for another Cisco SNMP advisory, which shows SNMP exposure exists broadly, but this exact flaw is still narrowed by valid SNMP auth and a specific EOL hardware/config match.
Disclosure / reporterPublished by Cisco on 2026-05-06. Cisco credits security researcher Ryan Moore for reporting the vulnerability.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.4/10)

The decisive factor is that exploitation requires valid SNMP access to the management plane, which usually implies prior credential theft or existing internal foothold rather than fresh internet compromise. The second big suppressor is the very narrow affected population: EOL SG350/SG350X hardware, two exact firmware builds, and a specific PoE configuration gate.

HIGH Affected-version and config prerequisites from Cisco advisory
MEDIUM Absence of public PoC or active exploitation evidence as of 2026-05-30
MEDIUM Enterprise exposure assumptions for SNMP isolation and credential hygiene

Why this verdict

  • Start from Cisco's 7.7/HIGH baseline because a crafted network request can hard-reload infrastructure gear and cause real availability loss.
  • Downgrade for attacker position: this is authenticated remote against the SNMP management plane, not unauthenticated edge exploitation. That implies prior compromise, stolen config/credential material, or legitimate management access.
  • Downgrade again for population narrowing: exploitation only applies to a small EOL subset of SG350/SG350X devices on 2.5.9.54/2.5.9.55 with two or more 60W PoE ports enabled.
  • Downgrade for threat signal: no KEV, no public PoC found, Cisco says no known malicious use, and EPSS is very low.
  • Keep it above LOW because impact is still operationally meaningful**: once the prerequisites are met, a single trigger can bounce a switch and knock out a branch, closet, phones, cameras, or attached users.

Why not higher?

This is not a perimeter-breaker. There is no unauthenticated path, no code execution, no data theft, and no integrity impact in the published advisory. Requiring valid SNMP auth plus a narrow hardware/firmware/PoE match makes the reachable population much smaller than a normal network-device HIGH.

Why not lower?

If you do run these EOL switches in branch or access roles, the blast radius at the site can still be painful: voice, cameras, APs, and users can all drop together when the switch reloads. The lack of a vendor patch also means affected estates carry a durable residual risk until they mitigate or replace.

05 · Compensating Control

What to do — in priority order.

  1. Exclude the vulnerable OID — Implement Cisco's SNMP view mitigation by excluding rlPethPsePortTable and bind that view to every SNMP community and SNMPv3 group. Because this is a MEDIUM finding there is no noisgate mitigation SLA; deploy it in the next approved network change window, then treat hardware replacement as the long-term fix.
  2. Restrict SNMP to the NMS only — Enforce ACLs or management-plane filtering so UDP/161 is reachable only from your monitoring platform and admin jump segments. There is no noisgate mitigation SLA for MEDIUM, but reducing reachable attack surface should still happen at the next routine network policy change.
  3. Retire SNMPv2c where possible — Move remaining estates to SNMPv3 and rotate any long-lived community strings that may exist in config backups or legacy tooling. For a MEDIUM verdict, schedule during normal credential-rotation cadence; this reduces the odds that a stolen read-only string becomes an outage trigger.
  4. Disable SNMP on non-managed switches — If a switch is not actively polled or trapped by an NMS, turn SNMP off entirely and remove the attack path. There is no noisgate mitigation SLA here; fold this into cleanup work and configuration standardization.
  5. Plan hardware replacement — Cisco will not ship a fix because SG350/SG350X are past software maintenance, so replacement is the only true remediation. For a MEDIUM finding, complete migration within the 365-day remediation window and prioritize sites where these switches carry PoE-heavy access roles.
What doesn't work
  • A WAF does nothing here because the path is SNMP over UDP/161, not HTTP.
  • Email security is irrelevant; this is a management-plane device flaw, not a user-delivered payload.
  • Vulnerability scanners alone are not enough because most will miss the exact trigger gate: firmware build plus model plus two 60W PoE ports plus SNMP exposure.
  • Upgrading the NMS does not fix the switch. The vulnerable parser is on the device itself unless you apply Cisco's OID-exclusion mitigation or replace the hardware.
06 · Verification

Crowdsourced verification payload.

Run this from an auditor workstation or jump host that can SSH to the switch CLI. Invoke it as python3 check_cve_2026_20185.py [email protected] or python3 check_cve_2026_20185.py [email protected] --ssh-opt=-i --ssh-opt=/path/key; read-only CLI access is sufficient because the script only runs show commands.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_20185.py
# Determine likely exposure to CVE-2026-20185 on Cisco SG350 / SG350X switches.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED(or not affected/mitigated), 1=VULNERABLE, 2=UNKNOWN

import re
import sys
import subprocess

USAGE = "Usage: python3 check_cve_2026_20185.py user@host [--ssh-opt=<value> ...]"


def run_ssh(target, cmd, extra_opts):
    base = ["ssh", "-o", "BatchMode=yes", "-o", "ConnectTimeout=10"]
    for opt in extra_opts:
        base.extend([opt] if opt.startswith("-") and " " not in opt else [opt])
    full = base + [target, cmd]
    try:
        p = subprocess.run(full, capture_output=True, text=True, timeout=25)
    except Exception as e:
        return None, f"ssh execution failed: {e}"
    if p.returncode != 0:
        err = (p.stderr or p.stdout or "ssh returned non-zero").strip()
        return None, err
    return p.stdout, None


def main():
    if len(sys.argv) < 2:
        print("UNKNOWN - " + USAGE)
        sys.exit(2)

    target = sys.argv[1]
    extra_opts = []
    for arg in sys.argv[2:]:
        if arg.startswith("--ssh-opt="):
            extra_opts.append(arg.split("=", 1)[1])
        else:
            print(f"UNKNOWN - unrecognized argument: {arg}")
            sys.exit(2)

    commands = {
        "version": "show version",
        "snmp_community": "show running-config | include snmp-server community",
        "snmp_group": "show running-config | include snmp-server group",
        "snmp_user": "show snmp user",
        "poe": "show running-config | include interface|power inline limit 60000",
        "view": "show running-config | include snmp-server view",
    }

    out = {}
    for key, cmd in commands.items():
        data, err = run_ssh(target, cmd, extra_opts)
        if err is not None:
            print(f"UNKNOWN - failed '{cmd}': {err}")
            sys.exit(2)
        out[key] = data or ""

    version_text = out["version"]
    model_match = re.search(r"\bSG350X?[-A-Z0-9]*\b", version_text, re.IGNORECASE)
    version_match = re.search(r"\b2\.5\.9\.(54|55)\b", version_text)

    if not model_match:
        print("PATCHED - target does not appear to be an SG350/SG350X switch")
        sys.exit(0)

    model = model_match.group(0).upper()
    affected_version = bool(version_match)

    snmp_v12 = "snmp-server community" in out["snmp_community"].lower()
    snmp_v3 = ("snmp-server group" in out["snmp_group"].lower()) and ("user name:" in out["snmp_user"].lower())
    snmp_enabled = snmp_v12 or snmp_v3

    poe_60w_count = len(re.findall(r"power inline limit 60000", out["poe"], re.IGNORECASE))
    poe_gate = poe_60w_count >= 2

    view_text = out["view"]
    oid_excluded = bool(re.search(r"snmp-server view\s+\S+\s+rlPethPsePortTable\s+excluded", view_text, re.IGNORECASE))
    view_created = bool(re.search(r"snmp-server view\s+\S+\s+iso\s+included", view_text, re.IGNORECASE))

    # Try to identify whether a mitigated view is actually applied.
    applied_to_v12 = bool(re.search(r"snmp-server community\s+\S+\s+view\s+\S+\s+RO", out["snmp_community"], re.IGNORECASE))
    applied_to_v3 = bool(re.search(r"snmp-server group\s+\S+\s+v3\s+\S*\s*read\s+\S+\s+write\s+\S+", out["snmp_group"], re.IGNORECASE))
    mitigation_present = oid_excluded and view_created and (applied_to_v12 or applied_to_v3)

    reasons = []
    reasons.append(f"model={model}")
    reasons.append(f"affected_version={'yes' if affected_version else 'no'}")
    reasons.append(f"snmp_enabled={'yes' if snmp_enabled else 'no'}")
    reasons.append(f"60w_poe_ports={poe_60w_count}")
    reasons.append(f"mitigation_present={'yes' if mitigation_present else 'no'}")

    if not affected_version:
        print("PATCHED - not on firmware 2.5.9.54/2.5.9.55; " + ", ".join(reasons))
        sys.exit(0)

    if not snmp_enabled:
        print("PATCHED - SNMP not enabled; " + ", ".join(reasons))
        sys.exit(0)

    if not poe_gate:
        print("PATCHED - fewer than two 60W PoE ports configured; " + ", ".join(reasons))
        sys.exit(0)

    if mitigation_present:
        print("PATCHED - Cisco OID-exclusion mitigation detected; " + ", ".join(reasons))
        sys.exit(0)

    print("VULNERABLE - SG350/SG350X on affected firmware with SNMP enabled and >=2 60W PoE ports, no mitigation detected; " + ", ".join(reasons))
    sys.exit(1)


if __name__ == "__main__":
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: pull an inventory of SG350/SG350X switches, identify anything on 2.5.9.54/2.5.9.55 with SNMP enabled and two or more 60W PoE ports, and apply Cisco's OID-exclusion mitigation at the next network change window. Because this is a MEDIUM reassessment and there is no active exploitation evidence, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in this case remediation means replace the EOL hardware within 365 days, since Cisco has said there will be no patch. If you discover any of these switches are internet-reachable or their SNMP credentials are broadly shared, compress that work immediately even though the formal noisgate remediation SLA is still 365 days.

Sources

  1. Cisco advisory
  2. NVD entry
  3. Vulnerability-Lookup mirror of Cisco CSAF / CISA ADP enrichment
  4. Cisco 350 Series EOL notice
  5. Cisco 350X Series EOL notice
  6. CISA Known Exploited Vulnerabilities Catalog
  7. SecurityWeek coverage
  8. Censys advisory on Cisco SNMP exposure proxy data
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.