CVE-2023-4346

What it actually does

This vulnerability allows an unauthenticated attacker with network access to a KNX installation, or physical access to the KNX bus/device, to abuse KNX Connection Authorization Option 1 and the BCU key mechanism to lock devices. By purging devices that do not have additional KNX security protections enabled and then setting a BCU key, the attacker can make legitimate administrators unable to access, reconfigure, or reset affected devices without the current key. The primary impact is denial of service and loss of administrative control over building automation devices.

Why it matters to the business

Successful exploitation can disrupt building automation operations such as lighting, HVAC, access-related automation, metering, alarms, or other KNX-controlled systems, depending on what the affected devices manage. Recovery may require vendor intervention, manual reprogramming, replacement of devices, or site visits, which can create operational downtime and physical safety or comfort impacts. The vulnerability is listed in CISA KEV with active exploitation in the wild and a remediation due date of 2026-07-29, so organizations using KNX installations should treat exposed or weakly protected KNX networks as high-priority operational technology risk.

How an attack unfolds

An attacker first gains logical access to the KNX/IP network, commonly through an exposed KNXnet/IP interface, flat building automation network, compromised adjacent system, or remote access path. Alternatively, the attacker obtains physical access to the KNX bus or device programming interface. The attacker enumerates KNX devices and identifies devices using KNX Connection Authorization with Option 1 and lacking stronger KNX security protections. The attacker then sends management/programming actions to purge device configuration or otherwise reset accessible authorization state, and sets a new BCU key known only to the attacker. Because many implementations require the current BCU key to change or clear the key, legitimate operators can be locked out of device administration and may be unable to recover the device through normal reset workflows.

How to fix it

There is no single universal fixed version because this is a KNX implementation and configuration issue across affected devices. Consult each KNX device and gateway vendor for firmware updates, security advisories, recovery procedures, and supported secure configuration. Where supported, upgrade firmware and management tooling, migrate to stronger KNX security options such as KNX IP Secure and KNX Data Secure, and avoid relying on Connection Authorization Option 1 alone. Restrict KNXnet/IP access, especially UDP/3671, to dedicated management hosts and trusted building automation controllers only. Remove KNX gateways from direct internet exposure, require VPN or bastion-mediated administrative access, and segment KNX networks from corporate and guest networks. Configure unique, documented, controlled BCU keys before deployment, maintain secure offline backups of ETS/project files and device credentials, and verify that authorized administrators can recover or reprogram devices. Physically secure KNX bus access points, cabinets, gateways, and programming interfaces. For already locked devices, follow vendor recovery guidance; if the BCU key cannot be recovered or reset, replacement or vendor servicing may be required.

How to confirm the fix worked

Create an inventory of KNX devices, KNX/IP routers, gateways, and engineering workstations, and identify devices that support Connection Authorization Option 1. Validate that KNXnet/IP services are not reachable from the internet or untrusted networks and that UDP/3671 is allowed only from approved management systems. Confirm devices run vendor-recommended firmware and that stronger KNX security features are enabled where available. Review ETS/project backups to confirm BCU keys and recovery materials are available to authorized personnel. Perform controlled, non-disruptive administrative connection tests from approved engineering systems to verify legitimate access still works. Review firewall rules, NAC policy, and network scans to confirm only authorized hosts can communicate with KNX gateways. Where possible, test vendor-documented recovery procedures in a lab or maintenance window before relying on them operationally.

Typical attack path

1. Obtain access to the KNX/IP network, KNXnet/IP gateway, building automation segment, or physical KNX bus.
2. Discover KNX devices and determine which devices support KNX Connection Authorization Option 1 and lack stronger security options.
3. Use KNX management/programming functions to interact with target devices.
4. Purge or alter device authorization/configuration where allowed.
5. Set a new BCU key/password controlled by the attacker.
6. Prevent legitimate administrators from connecting, resetting, or reprogramming the device without the attacker-controlled key.
7. Force operational disruption until devices are recovered through known keys, vendor procedures, factory service, or replacement.

How to detect it

To determine whether exploitation already occurred, collect and review logs from KNX/IP routers and gateways, building management systems, ETS or engineering workstations, firewall and NetFlow records, VPN and remote-access systems, NAC logs, and physical access control records for areas containing KNX equipment. Look for unexpected KNXnet/IP traffic, especially UDP/3671 management or programming activity from unauthorized hosts, new or unusual engineering workstations, access outside maintenance windows, repeated connection authorization failures, device purge/unload operations, BCU key changes, unexplained loss of administrative access, and devices that suddenly require an unknown key. Compare current device configuration and BCU key state against known-good ETS/project backups. Investigate any correlation between unauthorized network access to building automation segments and subsequent device lockout, configuration loss, or inability to reset/reprogram KNX devices. If gateway logs are limited, use firewall/session metadata and packet captures to identify unexpected KNXnet/IP management traffic and preserve affected devices before attempting recovery.

• UDP/3671
• KNXnet/IP
• BCU key
• BCU key set
• Set BCU Key
• Connection Authorization Option 1
• authorization failed
• authentication failed
• access denied
• device locked
• locked by BCU key
• unknown BCU key
• purge device
• device purge
• unload device
• ETS programming
• KNX programming mode
• KNX management connection
• unexpected KNXnet/IP tunneling connection
• unauthorized KNXnet/IP connection

What your security team should do

• Immediately identify all KNXnet/IP gateways and block internet or untrusted-network access to UDP/3671 and other KNX management interfaces.
• Prioritize remediation because the issue is in CISA KEV, has active exploitation in the wild, and had a KEV due date of 2026-07-29.
• Coordinate with facilities, building automation, and OT teams to inventory devices using KNX Connection Authorization Option 1.
• Apply vendor firmware updates and configuration hardening guidance for each affected KNX device and gateway.
• Enable KNX IP Secure, KNX Data Secure, or equivalent stronger protections where supported.
• Segment KNX networks and permit management access only from approved engineering workstations or jump hosts.
• Securely escrow BCU keys, ETS project files, recovery documentation, and device configuration backups.
• Inspect for signs of unauthorized BCU key changes, device purges, unexpected reprogramming, or loss of administrative access.
• Physically secure KNX bus wiring, cabinets, gateways, and programming ports against unauthorized access.
• Prepare an incident response and recovery plan for locked KNX devices, including vendor support contacts and spare-device strategy.