CVE-2026-13336 & CVE-2026-13337: Schneider Electric NetBotz 5 750/755 Unauthenticated Code Execution — Detection and Remediation Guide

CISA has published ICS Advisory ICSA-26-260-05 covering multiple vulnerabilities in Schneider Electric's NetBotz 5 750 and 755 security and environmental monitoring appliances. The affected firmware — version 5.5.2 and earlier — is exposed to arbitrary and unauthenticated code execution over the local network, carrying a CVSS v3 score of 6.4. Successful exploitation could allow an attacker to manipulate the device and gain unauthorized access to the data it collects.

If you are thinking "it's just a temperature sensor," stop. NetBotz appliances sit inside data centers, network closets, healthcare facilities, and industrial environments precisely because they are trusted with physical security telemetry: door contacts, leak detection, smoke sensors, vibration, humidity, and — critically — video monitoring. An attacker who executes code on a NetBotz unit gains a foothold on a network segment that is frequently flat, rarely segmented, and almost never monitored by EDR. These devices also tend to have network reach into out-of-band management VLANs. That is a pivot point, a surveillance tool, and a persistence mechanism rolled into one unmanaged box on the wall.

Defenders need to act on three fronts immediately: identify every NetBotz 5 750/755 on your network, apply Schneider Electric's remediation, and start hunting for signs of interaction with these devices from anything other than your known management stations.

Technical Analysis

Affected Products

• Vendor: Schneider Electric
• Advisory: CISA ICSA-26-260-05 (https://www.cisa.gov/news-events/ics-advisories/icsa-26-260-05), with a vendor CSAF document referenced in the advisory
• CVSS v3: 6.4 (Medium)

What the Vulnerabilities Allow

Per the advisory, failure to remediate exposes the devices to arbitrary or unauthenticated code execution over the local network. Two important scoping notes for defenders:

1. Attack vector is adjacent/local network. The attacker must have layer-2/layer-3 reachability to the device. This is not directly internet-exploitable — but that is cold comfort. NetBotz units are typically deployed on the same management or facilities VLANs that an intruder reaches within hours of an initial compromise, and many organizations (incorrectly) expose these interfaces to corporate user subnets.
2. No authentication required. The unauthenticated code execution path means an attacker does not need to phish credentials or brute-force the management console. Any host that can reach the device's network services is a potential launch point.

Impact of a Compromised NetBotz Appliance

• Device manipulation: disabling or spoofing environmental alarms (temperature, leak, smoke, door contact). In a data center, suppressing a thermal alarm while attacking cooling is a real-world sabotage primitive.
• Unauthorized data access: these units record video and sensor history. Compromise means surveillance of physical spaces — who enters the server room, when, and what they do.
• Foothold/persistence: an embedded Linux appliance with no EDR, no logging pipeline in most environments, and uptime measured in years is an ideal staging host for lateral movement into management networks.

Exploitation Status

At time of writing, neither CVE-2026-13336 nor CVE-2026-13337 appears in CISA's Known Exploited Vulnerabilities catalog, and no public in-the-wild exploitation has been confirmed. The advisory is vendor-originated coordinated disclosure. Treat this as a pre-exploitation window: ICS/IoT advisories of this class historically see proof-of-concept development within weeks of publication, and the unauthenticated network-exploitable nature makes these attractive targets for both opportunistic and OT-focused actors. Patch before the PoCs land.

Detection & Response

Because NetBotz appliances are embedded devices that cannot host EDR agents, detection must happen at the network and log-aggregation layer. The defensive hypothesis is simple: NetBotz devices should only ever talk to a small, known set of management systems (your NetBotz central console, SNMP pollers, NTP, DNS, firmware update sources). Any other host initiating connections to a NetBotz management interface — especially on web (80/443), SSH (22), or SNMP-write — is anomalous and worth investigating.

Build an asset list of NetBotz IPs first (see the Bash script below), then tune these detections against your known management station addresses.

Sigma Rules

---
title: Unexpected Host Connecting to NetBotz Management Interface
id: 8f2a1c44-6d3b-4e91-a7c2-9b4e5f6a7d8c
status: experimental
description: Detects network connections to NetBotz management ports (HTTP/HTTPS/SSH/SNMP) from hosts that are not known management stations. NetBotz appliances should only receive management traffic from a small set of known systems; any other source may indicate exploitation attempts against CVE-2026-13336 or CVE-2026-13337.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-260-05
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/09/17
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: network_connection
  product: windows
detection:
  selection_dst_ip:
    DestinationIp|cidr:
      - '10.0.0.0/8' # REPLACE: scope to your NetBotz/management VLAN CIDRs
  selection_dst_port:
    DestinationPort:
      - 80
      - 443
      - 22
      - 161
  filter_mgmt:
    SourceIp:
      - '10.10.5.20' # REPLACE: NetBotz central console / NMS
      - '10.10.5.21' # REPLACE: SNMP poller / monitoring host
  condition: selection_dst_ip and selection_dst_port and not filter_mgmt
falsepositives:
  - Vulnerability scanners (add scanner IPs to the filter, do not disable the rule)
  - Newly deployed monitoring infrastructure not yet in the allowlist
level: high
---
title: NetBotz Authentication Failure or Configuration Change Events in Syslog
id: 3c7d9e15-2a48-4f6b-b1d3-5e8a9c0d2f4b
status: experimental
description: Detects repeated authentication failures, unexpected configuration changes, or web interface errors reported by NetBotz appliances via syslog. Bursts of failed logins or config modifications may indicate brute-force or post-exploitation activity related to CVE-2026-13336/13337.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-260-05
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/09/17
tags:
  - attack.initial_access
  - attack.t1078
  - attack.persistence
logsource:
  product: linux
  service: syslog
detection:
  selection_host:
    Host|contains:
      - 'netbotz'
      - 'NBWL'
      - 'NBRK'
  selection_event:
    Message|contains:
      - 'authentication failure'
      - 'Failed password'
      - 'configuration changed'
      - 'login failed'
      - 'unauthorized'
  condition: selection_host and selection_event
falsepositives:
  - Legitimate admin mistyping credentials (investigate single events; alert on bursts)
  - Misconfigured SNMP/NMS polling with stale credentials
level: medium

Both rules require tuning: replace the placeholder CIDRs and management IPs with your actual NetBotz VLAN scopes and NMS addresses. The first rule is intentionally scoped to management ports on device-facing segments — do not deploy it unscoped or it will drown your queue.

KQL (Microsoft Sentinel / Defender)

The following query hunts Syslog and CEF-ingested data in Sentinel for NetBotz device telemetry showing authentication anomalies or unexpected interaction, plus a network-layer hunt for hosts talking to NetBotz management ports. Adjust the device IP list and host naming patterns to your environment.

let NetBotzPorts = dynamic([80, 443, 22, 161]);
let MgmtStations = dynamic(["10.10.5.20", "10.10.5.21"]); // REPLACE: known NetBotz console / NMS / SNMP pollers
let NetBotzDevices = dynamic(["10.10.6.0/24"]); // REPLACE: NetBotz VLAN CIDR(s)
union isfuzzy=true
    (CommonSecurityLog
    | where ipv4_is_in_range(DestinationIP, tostring(NetBotzDevices[0]))
    | where DestinationPort in (NetBotzPorts)
    | where not(SourceIP in (MgmtStations))
    | summarize Connections=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Ports=make_set(DestinationPort)
        by SourceIP, DestinationIP, DeviceVendor, DeviceProduct
    | extend HuntNote = "Non-management host initiating connection to NetBotz management port"),
    (Syslog
    | where HostName has_any ("netbotz", "NBWL", "NBRK") or Computer has_any ("netbotz", "NBWL", "NBRK")
    | where SyslogMessage has_any ("authentication failure", "Failed password", "login failed", "configuration changed", "unauthorized")
    | summarize Events=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), SampleMessages=make_set(SyslogMessage, 5)
        by HostName, SourceIP = tostring(parse_json(AdditionalFields).src)
    | extend HuntNote = "NetBotz auth failure or config change event"),
    (DeviceNetworkEvents
    | where RemotePort in (NetBotzPorts)
    | where ipv4_is_in_range(RemoteIP, tostring(NetBotzDevices[0]))
    | where not(LocalIP in (MgmtStations))
    | summarize Connections=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Processes=make_set(InitiatingProcessFileName)
        by DeviceName, LocalIP, RemoteIP, RemotePort
    | extend HuntNote = "Endpoint initiating connection to NetBotz appliance")
| order by LastSeen desc

Run this on a 7–14 day lookback first to establish your baseline of legitimate scanners and monitoring traffic, allowlist those, then schedule it as an analytics rule for ongoing alerting.

Velociraptor VQL

If you have Velociraptor deployed on endpoints (particularly jump boxes and engineering workstations in OT environments), this artifact hunts for live connections to NetBotz management services — useful during an IR sweep to find which host an attacker used as a launch point against the appliances.

-- Hunt for endpoint connections to NetBotz management interfaces
-- Scope TargetCIDR to your NetBotz VLAN(s) before deploying
LET TargetCIDR <= '10.10.6.0/24'  -- REPLACE: NetBotz device VLAN

SELECT Pid,
       Name,
       Exe,
       Username,
       CommandLine,
       netstat.Family AS Family,
       netstat.LocalAddr AS LocalAddr,
       netstat.LocalPort AS LocalPort,
       netstat.RemoteAddr AS RemoteAddr,
       netstat.RemotePort AS RemotePort,
       netstat.Status AS ConnStatus
FROM netstat()
WHERE netstat.RemotePort in (80, 443, 22, 161)
  AND netstat.RemoteAddr =~ '10\\.10\\.6\\.'  -- REPLACE: regex matching TargetCIDR
  AND netstat.Status = 'ESTABLISHED'

Pair the results with pslist() on the matching Pid to pull full process ancestry, then collect the process binary for triage. A browser or NMS agent is expected; nc.exe, python.exe, or an unsigned binary holding an established session to a NetBotz unit is not.

Remediation & Verification Script

The script below does three things: (1) discovers candidate NetBotz devices on target subnets via SNMP sysDescr, (2) attempts to fingerprint the firmware version so you can flag anything at or below 5.5.2, and (3) checks whether management ports are reachable from the host running it — a quick way to validate that segmentation controls are working from segments that should NOT reach the appliances. Run it from a management jump host with SNMP read access; run it again from a user VLAN (expecting discovery and port checks to fail) to validate segmentation.

#!/bin/bash
# NetBotz 5 750/755 (CVE-2026-13336 / CVE-2026-13337) discovery and exposure audit
# Requires: snmpwalk (net-snmp), nmap
# Usage: ./netbotz_audit.sh 10.10.6.0/24 public

SUBNET="$1"
COMMUNITY="${2:-public}"
FIXED_VERSION="5.5.3"   # REPLACE with the fixed version from Schneider Electric's CSAF if different

if [ -z "$SUBNET" ]; then
  echo "Usage: $0 <subnet-cidr> [snmp-community]"
  exit 1
fi

echo "[*] Discovering hosts with open SNMP (161/udp) on $SUBNET ..."
nmap -sU -p161 --open -oG - "$SUBNET" 2>/dev/null | awk '/161\/open/{print $2}' > /tmp/snmp_hosts.txt

echo "[*] Querying sysDescr / model info ..."
while read -r HOST; do
  DESCR=$(snmpwalk -v2c -c "$COMMUNITY" -t 2 -r 1 "$HOST" SNMPv2-MIB::sysDescr.0 2>/dev/null | cut -d: -f4-)
  if echo "$DESCR" | grep -qiE 'netbotz|750|755'; then
    echo "[+] NetBotz candidate: $HOST — $DESCR"
    echo "$HOST" >> /tmp/netbotz_devices.txt
  fi
done < /tmp/snmp_hosts.txt

if [ ! -s /tmp/netbotz_devices.txt ]; then
  echo "[*] No NetBotz devices identified via SNMP. Trying HTTP banner grab for NetBotz web UI ..."
  nmap -p80,443 --open -oG - "$SUBNET" 2>/dev/null | awk '/open/{print $2}' | while read -r HOST; do
    TITLE=$(curl -sk --max-time 3 "https://$HOST/" | grep -oiE '<title>[^<]*' | head -1)
    echo "$TITLE" | grep -qi netbotz && { echo "[+] NetBotz web UI: $HOST — $TITLE"; echo "$HOST" >> /tmp/netbotz_devices.txt; }
  done
fi

echo "[*] Checking management-port exposure for identified devices ..."
while read -r DEV; do
  for PORT in 22 80 443 161; do
    (echo > /dev/tcp/"$DEV"/"$PORT") 2>/dev/null && echo "[!] $DEV port $PORT reachable from $(hostname)"
  done
done < /tmp/netbotz_devices.txt

echo "[*] Done. Cross-reference /tmp/netbotz_devices.txt against firmware <= 5.5.2 and remediate per Schneider Electric CSAF."
echo "[*] Target fixed version: >= $FIXED_VERSION"

Key operational notes: run the audit from at least two vantage points (management VLAN and a standard user VLAN). Devices reachable from user subnets are your priority — that is the exploitation path these CVEs require, and closing it is a compensating control even before firmware is updated.

Remediation

1. Inventory first. You cannot patch what you have not found. Use the discovery script above, your CMDB, and DHCP/NAC records to enumerate every NetBotz 5 750 and 755. These devices are frequently purchased by facilities teams and never registered with IT — assume shadow deployments exist.
2. Apply the vendor fix. Schneider Electric has published remediation guidance in its CSAF document referenced by CISA ICSA-26-260-05: https://www.cisa.gov/news-events/ics-advisories/icsa-26-260-05. Upgrade all NetBotz 5 750/755 units running firmware 5.5.2 or earlier to the fixed release specified in the vendor advisory. Verify the running version post-upgrade via the web console or SNMP.
3. Segment the devices. NetBotz appliances belong on a dedicated, access-controlled management VLAN. Enforce ACLs/firewall rules so that only your NetBotz central console, SNMP pollers, and designated admin jump hosts can reach ports 22, 80, 443, and 161 on those devices. This directly removes the "local network" attack vector for the vast majority of your estate and is the single most effective compensating control.
4. Disable unused services. If you do not use the web interface, SSH, or SNMP write access on a unit, disable them from the management console. Reduce the attack surface the unauthenticated flaw can reach.
5. Rotate credentials on remediated devices. If a device was running vulnerable firmware and was reachable from broadly accessible segments, treat credentials stored on or used to manage it as potentially compromised. Change local admin passwords and any SNMP community strings (and move to SNMPv3 with authPriv if you have not already).
6. Ship the logs. Configure NetBotz syslog forwarding to your SIEM if it is not already. Authentication events and configuration changes on these appliances should be as visible as they are on your domain controllers. Deploy the KQL analytics rule above after baselining.
7. Validate physical-security alerting integrity. Because these CVEs allow device manipulation, confirm that environmental alarm paths (thermal, leak, door contact) have an independent verification channel — e.g., alerts that traverse your central monitoring platform rather than relying solely on the appliance's local state.
8. Track to closure. Add CVE-2026-13336 and CVE-2026-13337 to your vulnerability management queue with an owner and a due date. ICS/IoT remediation slips when it is treated as "facilities' problem." It is not — it is a network-resident, unauthenticated code execution risk and belongs in your standard SLAs.

Final Thoughts

A CVSS 6.4 will not light up a dashboard the way a 9.8 does, and that is exactly how appliances like NetBotz stay vulnerable for years. The score understates the operational reality: an unauthenticated code execution flaw, on an unmanaged embedded device, sitting on networks that touch your most sensitive physical spaces. There is no public exploitation yet — use that window. Inventory today, segment this week, patch on your next maintenance cycle, and put detection in place so that if someone gets there first, you see it.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub