CVE-2023-4346: Active Exploitation of KNX Protocol Lockout Mechanism – Defense and Detection

As of July 15, 2026, CISA has added CVE-2023-4346 to the Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation in the wild. For Security Arsenal clients managing Operational Technology (OT) and building automation systems, this is a critical event. The vulnerability affects the KNX Association's KNX Protocol—specifically the Connection Authorization Option 1.

While CVE-2023-4346 was assigned in 2023, its addition to the KEV catalog today indicates that threat actors are actively leveraging it against current infrastructure. The flaw resides in an "overly restrictive account lockout mechanism." Paradoxically, the security feature intended to prevent brute-force attacks can be abused to deny service or purge device configurations, allowing attackers to set the BCU (Basic Coupler Unit) key and effectively lock out legitimate administrators.

This blog post provides the technical breakdown and defensive actions required to secure your KNX environments.

Technical Analysis

Affected Component: KNX Association KNX Protocol (Connection Authorization Option 1)

CVE Identifier: CVE-2023-4346

Vulnerability Class: Logic Error / Improper Authentication (Account Lockout)

The Attack Vector: The vulnerability lies in how the protocol handles connection attempts when Option 1 is enabled. The lockout mechanism is so restrictive that it can be triggered or manipulated in a way that allows an attacker to:

1. Trigger a Purge: Force the device to purge its existing configuration and authorization data.
2. Set the BCU Key: Once purged, the attacker can impose their own BCU key, seizing control of the device's authorization layer.
3. Lock Out Administrators: Legitimate users are unable to manage the device or revert the configuration without physical intervention or specialized reset procedures.

Exploitation Status: CONFIRMED ACTIVE. CISA has verified that this vulnerability is being exploited in the wild as of July 2026.

Risk: High impact on Availability and Integrity. In building automation contexts (HVAC, lighting, access control), this could result in facility lockouts or environmental control failures.

Detection & Response

Detection in OT environments requires monitoring network traffic for anomalies in KNXnet/IP communication, specifically looking for the behavioral precursors to a lockout-triggering attack or configuration purges.

Sigma Rules

The following rules target high-volume KNX connection attempts (indicative of brute-forcing to trigger the lockout) and anomalous service interactions.

---
title: Potential KNX Protocol Brute Force or Lockout Trigger
id: 8a5f1c22-9e4b-4d67-bc12-3e5a8f901234
status: experimental
description: Detects high frequency of connection attempts to KNXnet/IP port (3671/UDP), which may indicate an attempt to trigger the overly restrictive lockout mechanism in CVE-2023-4346.
references:
 - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
author: Security Arsenal
date: 2026/07/16
tags:
 - attack.initial_access
 - attack.t1190
logsource:
 category: network_connection
 product: os
detection:
 selection:
 DestinationPort: 3671
   Protocol|contains: 'udp'
 condition: selection | count() > 50
 timeframe: 1m
falsepositives:
  - Legitimate KNX network discovery or re-indexing events
level: high
---
title: KNX Configuration Management Anomaly
id: 9b6g2d33-0f5c-5e78-cd23-4f6b9g012345
status: experimental
description: Detects specific KNX service codes associated with device memory purging or BCU key manipulation often seen in CVE-2023-4346 exploitation.
references:
 - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
author: Security Arsenal
date: 2026/07/16
tags:
 - attack.persistence
 - attack.t0843
logsource:
 category: firewall
 product: fortinet
detection:
 selection:
  dst_port: 3671
  service: 'KNXnet/IP'
  action: 'accept'  # Focus on successful traffic that could carry payload
 filter:
  src_ip:
    - '10.0.0.0/8'  # Filter out known internal management subnets
    - '192.168.0.0/16'
 condition: selection and not filter
falsepositives:
  - Authorized engineering workstations from unknown subnets
level: medium

KQL (Microsoft Sentinel / Defender)

Use this query to hunt for spikes in KNX traffic across your network logs ingested via Syslog or CEF.

let KNXPort = 3671;
let TimeFrame = 1h;
let Threshold = 100;
CommonSecurityLog
| where DestinationPort == KNXPort
| where TimeGenerated > ago(TimeFrame)
| summarize Count = count() by SourceIP, DestinationIP
| where Count > Threshold
| extend Timestamp = now()
| project Timestamp, SourceIP, DestinationIP, Count, Alert = "High volume KNX traffic detected - Potential CVE-2023-4346 exploit attempt"

Velociraptor VQL

Hunt for processes or network connections associated with KNX management tools that might be performing bulk operations.

-- Hunt for processes establishing connections to standard KNXnet/IP ports
SELECT Name, Pid, Cmdline, Exe
FROM pslist()
WHERE Cmdline =~ '3671'
   OR Name =~ 'ETS'
   OR Name =~ 'knx'

-- Hunt for active network connections on KNX ports
SELECT Fd, Family, RemoteAddr, RemotePort, State
FROM listen_sockets()
WHERE RemotePort = 3671

Remediation Script (Bash)

Since KNX devices are often embedded or Linux-based gateways, use this script to verify network isolation (a primary compensating control) and check for basic firewall rules on management servers.

#!/bin/bash
# Remediation/Harden Script for KNX Exposure (CVE-2023-4346)
# Checks if KNX port (3671) is inadvertently exposed to untrusted networks.

KNX_PORT=3671

echo "[+] Checking for firewall rules allowing KNX traffic (UDP $KNX_PORT)..."

# Check iptables for specific allows on KNX port
if command -v iptables >/dev/null 2>&1; then
    RULES=$(iptables -L -n -v | grep -i "$KNX_PORT")
    if [ -z "$RULES" ]; then
        echo "[!] No specific rules found for port $KNX_PORT."
    else
        echo "[+] Found existing rules:"
        echo "$RULES"
    fi
else
    echo "[!] iptables not found."
fi

# Check if any process is listening on the KNX port (local gateway management)
echo "[+] Checking for processes listening on KNX port..."
LISTENING=$(ss -ulpn | grep ":$KNX_PORT")
if [ -n "$LISTENING" ]; then
    echo "[WARNING] Process listening on KNX port detected. Review below:"
    echo "$LISTENING"
    echo "[ACTION] Ensure this service is not exposed to the WAN."
else
    echo "[+] No processes listening on KNX port."
fi

echo "[+] Remediation Recommendation:"
echo "1. Restrict UDP 3671 to known Engineering Workstation subnets ONLY."
echo "2. Disable Connection Authorization Option 1 if possible, per vendor guidance."
echo "3. Enable KNX IP Security (IPsec/Data Security) if supported."

Remediation

1. Apply Vendor Patches: Contact your KNX device/gateway vendors immediately to obtain firmware updates that address CVE-2023-4346. If patches are not available, enforce strict network segmentation.
2. Network Segmentation: Ensure UDP port 3671 is blocked at the perimeter firewall. Traffic should only be allowed between trusted engineering workstations and the KNX gateways/controllers.
3. Disable Option 1: If your operational environment permits, disable "Connection Authorization Option 1" and migrate to a more secure authentication mechanism (e.g., Option 2 with IPsec or individual device authentication) as recommended by the KNX Association.
4. CISA BOD 26-04 Compliance: Per CISA Binding Operational Directive (BOD) 26-04, this vulnerability requires remediation by the deadline specified in the KEV catalog. Confirming this update meets your federal compliance obligations if applicable.
5. Forensics Triage: If you suspect exploitation, isolate affected gateways immediately and preserve volatile memory and logs for forensic analysis to determine if the BCU key was altered.

Related Resources

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