CVE-2026-59693: Siemens Desigo DXR and PXC BACnet DoS — Detection, Mitigation, and Patching Guide for OT Defenders

CISA has published ICS advisory ICSA-26-225-08 covering CVE-2026-59693, a denial-of-service vulnerability in Siemens Desigo DXR and PXC building automation controllers. The flaw allows an unauthenticated, network-adjacent attacker to crash affected devices simply by sending malformed BACnet packets — and recovery requires a manual device reset or reboot to restore normal functionality.

For those of us who have responded to OT incidents, this class of vulnerability deserves more respect than a typical "DoS-only" rating suggests. Desigo controllers run HVAC, access control integration, lighting, and life-safety-adjacent systems in hospitals, data centers, airports, and commercial campuses. A sustained or repeated crash of these controllers can mean lost environmental controls in a server room, failed cooling in a pharmaceutical storage area, or degraded building operations during an emergency. There is no automatic recovery — a technician has to physically touch or remotely reboot every affected device.

Siemens has released fixed firmware for all affected product lines. This post breaks down what's affected, how to detect exploitation attempts on your building automation networks, and how to remediate safely in an OT change-control environment.

Technical Analysis

Affected Products and Versions

All versions prior to the listed fixed builds are vulnerable to CVE-2026-59693:

How the Vulnerability Works

The affected controllers expose BACnet/IP services on UDP port 47808 — the standard BACnet/IP transport. BACnet (Building Automation and Control Networks) is the lingua franca of building automation systems, and it was designed decades ago without authentication or integrity protections baked in.

The vulnerability is a classic improper input handling / parser robustness failure: the BACnet protocol stack on these devices does not safely handle malformed or out-of-spec packet structures. An attacker who can reach UDP/47808 on the controller can send a crafted BACnet frame that triggers a fault condition severe enough to take the device offline. Critically:

• No authentication is required — BACnet/IP has no native auth, and the flaw is in packet parsing, pre-authentication by definition.
• No user interaction is required — this is a pure network-triggered condition.
• Recovery is manual — the device does not self-heal; it requires a reset or power cycle. In a large campus with hundreds of distributed DXR/PXC controllers, this translates to significant operational downtime and truck rolls.

Exploitation Requirements

The attacker needs network reachability to the BACnet segment. In practice that means one of:

1. Flat network architecture — the most common root cause we see in OT assessments. If the BAS network shares a VLAN (or worse, a routable path) with the corporate IT network, any compromised workstation becomes a launch point.
2. Compromised engineering workstation or management server on the OT side (e.g., a Desigo CC management station or Desigo Control Point host).
3. Direct exposure — BACnet services inadvertently reachable from the internet or guest networks. A quick Shodan check for your ASN on UDP/47808 is worth doing today.

Exploitation Status

As of publication of ICSA-26-225-08, there is no confirmed in-the-wild exploitation and the vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. However, BACnet parser DoS conditions are trivially weaponizable once technical details circulate — BACnet fuzzing tooling is mature and publicly available — and the attack surface (building controllers in hospitals, data centers, and critical facilities) is attractive to both disruptive actors and ransomware affiliates looking for leverage. Treat this as patch-now, not patch-later.

Detection & Response

A candid note before the rules: BACnet parser attacks happen at layer 7 of the OT protocol, and most endpoint-focused telemetry won't see the malformed packet itself. The highest-fidelity detections are (a) network-level: unexpected sources speaking BACnet to your controllers, and (b) availability-level: controllers rebooting or dropping off the management platform. The rules below target those observable behaviors. Tune source/destination scoping to your documented BAS VLANs before deploying broadly — unscoped BACnet detection will fire on every legitimate Desigo CC poll in the environment.

Sigma Rules

---
title: BACnet Traffic From Non-BAS Source to Desigo Controller Segment
id: 3f8c2a14-7b61-4d29-9e5f-a1c4d8e20671
status: experimental
description: Detects BACnet/IP (UDP 47808) communication originating from hosts outside the authorized building automation VLAN or engineering workstation set, potentially indicating scanning or exploitation attempts against Siemens Desigo DXR/PXC controllers (CVE-2026-59693).
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-225-08
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.discovery
  - attack.t1046
  - attack.impact
  - attack.t1499
logsource:
  category: firewall
  product: network
detection:
  selection_port:
    DestinationPort: 47808
    Protocol: udp
  filter_authorized:
    SourceIp|cidr:
      - '10.40.0.0/16'   # Replace: authorized BAS VLAN(s)
      - '10.40.10.0/24'  # Replace: engineering workstation segment
  condition: selection_port and not filter_authorized
falsepositives:
  - Misdocumented BAS subnets after network changes
  - Vendor remote support sessions routed over corporate VPN
level: high
---
title: High-Volume BACnet Packet Flood Toward Building Controllers
id: 9d17e5b3-2c84-4f1a-b6c3-58a0f2e9d437
status: experimental
description: Detects anomalous connection rates to BACnet/IP services consistent with fuzzing or malformed-packet DoS attempts against Desigo controllers. A single source generating sustained high-rate UDP/47808 flows is atypical for normal BAS polling patterns.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-225-08
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.impact
  - attack.t1499
logsource:
  category: netflow
  product: network
detection:
  selection:
    DestinationPort: 47808
    Protocol: udp
    FlowCount|gt: 500  # Per source, per 5-min window — tune to BAS polling baseline
  condition: selection
falsepositives:
  - BAS discovery sweeps during Desigo CC commissioning
  - Legitimate bulk point polling after controller reboot
level: medium

Deployment note: Replace the placeholder CIDR ranges with your actual BAS VLANs and engineering workstation subnets. If you don't know them, that's finding number one of this advisory for your environment.

Microsoft Sentinel / Defender KQL

This query hunts firewall or CEF-ingested network logs for BACnet traffic from unauthorized sources, and separately surfaces controller availability events (reboots/offline transitions) reported by syslog from OT monitoring or the Desigo management layer:

// Hunt 1: Unauthorized sources speaking BACnet/IP to controller segments
// Tune AuthorizedBasSources to your documented BAS VLAN / engineering hosts
let AuthorizedBasSources = dynamic(["10.40.0.0/16", "10.40.10.0/24"]);
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DestinationPort == 47808
| where not(ipv4_is_in_any_range(SourceIP, AuthorizedBasSources))
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            TargetControllers = make_set(DestinationIP, 50)
  by SourceIP, DeviceVendor, DeviceProduct
| where EventCount > 10
| sort by EventCount desc;

// Hunt 2: Controller reset/reboot events — potential post-exploitation indicator (CVE-2026-59693 recovery requires reboot)
Syslog
| where TimeGenerated > ago(24h)
| where Computer has_any ("dxr", "pxc", "desigo")
   or SyslogMessage has_any ("Desigo", "BACnet", "PXC", "DXR")
| where SyslogMessage has_any ("reboot", "reset", "restart", "watchdog", "crash", "offline", "device down")
| summarize EventCount = count(), SampleMessages = make_set(SyslogMessage, 5)
  by Computer, Facility, SeverityLevel
| sort by EventCount desc

If you ingest Palo Alto, Fortinet, or Zeek logs into Sentinel, adapt Hunt 1 to CommonSecurityLog fields already present (most firewall CEF connectors populate DestinationPort and SourceIP as shown). The reboot hunt only works if your controllers or the Desigo CC station forward syslog — if they don't, route Desigo CC alarm/event exports into your SIEM as a compensating data source.

Velociraptor VQL

Velociraptor can't interrogate the controllers themselves, but it's the right tool for hunting the origin: a compromised Windows engineering workstation or jump host that could be used to reach the BAS network. This artifact identifies hosts with live or recent connections to BACnet services:

-- Hunt for endpoint hosts with network connections to BACnet/IP (UDP 47808)
-- Relevant for identifying the origin host of malformed-packet attacks against Desigo controllers
SELECT Pid,
       Name,
       Path AS ProcessPath,
       Status,
       Laddr.IP AS LocalIP,
       Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP,
       Raddr.Port AS RemotePort
FROM netstat()
WHERE RemotePort = 47808
   OR LocalPort = 47808

Expected results: your Desigo CC management servers and authorized engineering workstations (e.g., hosts running Desigo engineering tools) will legitimately appear. Anything else — a finance workstation, a print server, a guest device — holding a connection to UDP/47808 is an immediate investigation priority. Pair this with a follow-on pslist() review of the owning PID to identify the process responsible.

Remediation / Verification Script

Use this Bash script from a management host to audit BACnet exposure across your networks and identify controllers still advertising on UDP/47808 — useful both for scoping the affected fleet pre-patch and for validating segmentation post-patch:

#!/bin/bash
# CVE-2026-59693 exposure audit — identify BACnet/IP services reachable from this network position
# Run from: (1) corporate IT network to test segmentation, (2) BAS VLAN to inventory controllers

TARGETS_FILE="bas_subnets.txt"   # One CIDR per line, e.g. 10.40.20.0/24
OUTFILE="bacnet_exposure_$(date +%Y%m%d_%H%M).csv"

echo "timestamp,target_ip,port,status,banner_hint" > "$OUTFILE"

while read -r SUBNET; do
  echo "[*] Scanning $SUBNET for UDP/47808 (BACnet/IP)..."
  # nmap UDP scan with BACnet service probe
  nmap -sU -p 47808 --open -Pn "$SUBNET" -oG - 2>/dev/null | \
  awk '/Ports: 47808\/open/ {
    ts = strftime("%Y-%m-%d %H:%M:%S");
    print ts","$2",47808,open,bacnet_ip" 
  }' >> "$OUTFILE"
done < "$TARGETS_FILE"

echo "[+] Results written to $OUTFILE"
echo "[!] Any host reachable on UDP/47808 from the CORPORATE network = segmentation failure. Remediate before patching."

# Verification of BACnet/IP responses (ReadProperty via BACpypes, if installed):
# python3 -c "
# from bacpypes.apdu import WhoIsRequest
# # Issue a BACnet Who-Is on the BAS VLAN only — confirms live controllers for patch inventory
# "

For Windows-based Desigo engineering stations, this PowerShell validates whether the host itself can reach controller BACnet services across segments — a quick segmentation test:

# Segmentation validation — test BACnet/IP reachability to controller subnet from this host
$ControllerSubnet = "10.40.20."   # Replace with your BAS controller subnet prefix
$Results = 1..254 | ForEach-Object -Parallel {
    $ip = "$using:ControllerSubnet$_"
    $udp = New-Object System.Net.Sockets.UdpClient
    $udp.Client.ReceiveTimeout = 800
    try {
        # BACnet Who-Is (BVLL Original-Broadcast-NPDU) probe
        $bytes = [byte[]](0x81,0x0b,0x00,0x0c,0x01,0x20,0xff,0xff,0x00,0xff,0x10,0x08)
        $udp.Connect($ip, 47808)
        [void]$udp.Send($bytes, $bytes.Length)
        $remote = New-Object System.Net.IPEndPoint([System.Net.IPAddress]::Any, 0)
        $resp = $udp.Receive([ref]$remote)
        [pscustomobject]@{ IP = $ip; Reachable = $true; ResponseBytes = $resp.Length }
    } catch { } finally { $udp.Close() }
} -ThrottleLimit 64

$Results | Format-Table -AutoSize
if ($Results) {
    Write-Warning "BACnet controllers reachable from this segment — verify this host is authorized to see them (CVE-2026-59693 exposure)."
} else {
    Write-Output "No BACnet responses — segmentation appears effective from this position."
}

Remediation

1. Apply the Siemens firmware updates. Siemens has released fixed versions for every affected product line — this is the definitive remediation:

• Desigo DXR2 and PXC3: update to 01.21.233.16-7862 or later
• Desigo PXC4, PXC5.E003, PXC5.E24, and PXC7: update to 02.21.194.36-2715 or later

In OT environments, stage firmware updates through your change advisory board and schedule them during maintenance windows. Prioritize internet-adjacent facilities, hospital clinical areas, and data center cooling controllers first — anywhere a loss of environmental control has immediate safety or availability consequences. Validate controller configuration backups (via Desigo engineering tools / ABT Site or Xworks Plus depending on generation) before flashing.

2. Enforce network segmentation — this is the compensating control that actually blunts the attack. Because exploitation requires only UDP reachability, proper segmentation reduces exposure to near zero:

• Place all BAS controllers on dedicated, non-routed VLANs with no path to corporate IT, guest, or internet networks.
• Permit UDP/47808 only between controllers and the Desigo CC management station / authorized engineering workstations, enforced by firewall ACL or industrial DMZ per IEC 62443 zone-and-conduit design.
• Block UDP/47808 at every network boundary. BACnet should never traverse the internet or business network.

3. Verify you're not exposed externally. Query Shodan/Censys for your public IP space on port 47808. If controllers are internet-reachable, treat that as a P1 remediation independent of this CVE.

4. Establish availability monitoring. Since recovery is manual, mean-time-to-detect directly determines downtime. Alert on controller heartbeat loss from Desigo CC, unexpected reboot events, and BACnet polling failures. Feed these into your SIEM so a controller crash during off-hours triggers an IR workflow, not a Monday morning surprise.

5. Inventory now, not during the incident. Many organizations cannot answer "how many DXR2/PXC5 controllers do we have, and at what firmware?" Build that asset inventory from Desigo CC exports or a BACnet Who-Is/I-Am sweep, and record firmware versions against the fixed builds above.

References:

• CISA ICS Advisory: https://www.cisa.gov/news-events/ics-advisories/icsa-26-225-08
• Siemens ProductCERT advisory (linked from the CISA advisory / CSAF) — consult for official firmware download channels

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub