A Lockout With No Key: CVE-2023-4346 on the KNX Building Automation Bus

CISA added a three-year-old KNX flaw to its Known Exploited Vulnerabilities catalog on July 15, 2026, after confirming active exploitation. This is not a data breach or a remote code execution. It is a lockout: an attacker who can reach the bus can purge the devices that run a building and set a password no legitimate operator can remove. Here is how it works, why an availability-only bug belongs on an OT watch, and what to do about it.

What the vulnerability is

KNX is the international open standard for home and building control. It runs the lighting, heating, ventilation, air conditioning, shading, energy management, and access control in a very large share of commercial and institutional buildings, particularly across Europe, where the standard originated. The devices on a KNX installation talk over a shared bus, and that bus can be bridged onto an IP network through KNXnet/IP gateways so the building can be managed remotely. That convenience is also the exposure.

CVE-2023-4346 is classified as an overly restrictive account lockout mechanism, CWE-645. The root cause is a design property, not a memory bug. KNX devices that use Connection Authorization and support Option 1 can be protected with a BCU key, which functions as a device password. The problem is that once a BCU key is set, many implementations provide no way to reset it without already knowing the current key. There is no spare, no backdoor, and no vendor reset code. That is a reasonable anti-tamper stance right up until an attacker is the one who sets the key.

The affected population is broad. CISA lists all versions of KNX devices using Connection Authorization Option 1 in which no BCU key is currently set. A device left in its default, unkeyed state is exactly the device an attacker can key first.

How the lockout works

The attack does not require a login, and it does not even strictly require the network. If the KNX installation is reachable over a connected IP network, an attacker on that network can interface with the bus directly. If it is not networked, an attacker with physical access to the wiring or a device can do the same thing on the wire. In both cases the sequence is the same: enumerate the installation, purge the devices that have no additional security options enabled, and then write a BCU key. From that moment the legitimate integrator, facility manager, or building owner is locked out of their own controllers, and because the key cannot be reset without itself, there may be no clean way back.

The security feature is the weapon. An attacker does not have to break the lock on the door, they just have to be the first one to set it, and then throw away the key.

CISA's own assessment underscores why this made the exploited list. The agency's decision-support record marks exploitation as active and the flaw as automatable, meaning the steps can be scripted and repeated at scale rather than requiring bespoke effort per target. The technical impact is recorded as partial, which fits an availability-only outcome: nothing is stolen or altered, but the system stops answering to its rightful operators.

Why this hits OT and critical infrastructure

It is tempting to file a building automation bug under facilities rather than under operational technology. We would push back on that. Building management systems are OT, and in many critical settings they are load-bearing OT. Hospitals depend on climate control for operating theaters, isolation rooms, and pharmacy storage. Data centers depend on cooling to stay online. Transport hubs, government buildings, and manufacturing plants depend on KNX-controlled lighting, ventilation, and physical access control to function and to stay safe. CISA maps this vulnerability to the Critical Manufacturing sector, and the same logic reaches well beyond it.

The distinctive thing about this flaw is that it attacks availability directly, which is the property OT operators guard above all others. Most of the edge and appliance bugs we write about, the Citrix, FortiGate, SonicWall, and Cisco cases, are dangerous because they let an attacker reach in and pivot. This one is different. It does not steal a foothold, it denies control. Loss of control and loss of availability are the two outcomes an OT risk model fears most, and CVE-2023-4346 produces both in a single, scriptable move, with a recovery path measured in truck rolls and manual re-commissioning rather than a reboot.

What we see from our sensors

We run a fleet of honeypots and edge decoys, so we went looking for this in our own data, and we want to be precise about what we found and what we did not.

We did not capture exploitation of CVE-2023-4346. Our decoys do not currently emulate a KNX device or a KNXnet/IP gateway, so an attacker interacting with a real KNX bus would not find a matching surface on our sensors, and we are not going to claim otherwise.

What we do see is the reconnaissance that precedes this kind of activity. Building automation and industrial protocols exposed to the public internet are scanned constantly, and KNXnet/IP, which listens on UDP 3671, is part of that background noise on our internet-facing decoys alongside Modbus, BACnet, and the other protocols that should never have been reachable from the open internet in the first place. The uncomfortable truth this CVE highlights is how many building automation buses are one exposed gateway away from an attacker who does not need a zero-day, just reachability and the willingness to set a key.

What to do

• Set the BCU key yourself, before someone else does. The KNX Association's guidance is to set the BCU key in every KNX project, both those already commissioned and those still to come, so that no device is left in the unkeyed state that this vulnerability preys on. Hand the key over as part of the project documentation so the building owner is never locked out of their own installation.
• Follow the KNX Secure Checklist. KNX Association points integrators, installers, ETS users, and end customers to its Secure Checklist and to standard IT security hygiene. Treat that checklist as the baseline for both new commissions and existing installs.
• Get the bus off the public internet. CISA is explicit: minimize network exposure for all control system devices, and ensure they are not accessible from the internet. A KNXnet/IP gateway reachable from the open internet is the single biggest amplifier of this flaw.
• Segment building automation behind firewalls. Locate control system networks and building automation behind firewalls and isolate them from the business IT network, so that a foothold in IT does not become direct access to the bus.
• Use secure remote access when it is required. When remote management is genuinely needed, put it behind a VPN, keep that VPN patched to its current version, and remember that a VPN is only as secure as the devices connected to it.
• Meet the federal deadline and treat it as a floor. The BOD 26-04 required action is due July 29, 2026. For everyone outside the federal mandate, that date is a sensible target rather than a legal one, and the mitigations above apply regardless of sector.

Indicators and references