CVE-2023-4346

What is KNX?

KNX is an open standard for building automation, used to control lighting, HVAC, shutters, alarms, and energy management across commercial buildings, hospitals, airports, and government facilities — predominantly in Europe. It runs over twisted-pair bus wiring, IP, RF, or powerline, and is implemented by dozens of independent manufacturers (Siemens, ABB, Schneider Electric, Gira, Hager, Jung, MDT, and others) building interoperable devices to the same specification. KNX Data Secure and KNX IP Secure are extensions added to the standard to provide authentication and encryption for device commissioning and communication, addressing the original protocol's lack of built-in security. Because KNX controls physical building systems, availability disruptions can have real-world operational consequences — locking building managers out of lighting, access, or climate control.

Overview

CVE-2023-4346 is a design-level flaw (CWE-645, Overly Restrictive Account Lockout Mechanism) in the "Connection Authorization Option 1" handshake used by KNX Secure devices. Unlike the other CVEs in this batch, this is not a single vendor's product bug — it affects any device implementing this option of the KNX specification's security handshake. CISA published ICS advisory ICSA-23-236-01 in August 2023; the CVE was added to the KEV catalog nearly three years later, in July 2026, indicating CISA identified confirmed exploitation activity well after the original advisory.

Affected Versions

Because this is a protocol-level issue rather than a single-vendor bug, there is no single "fixed version" — remediation depends on guidance published by the KNX Association and firmware updates from individual manufacturers implementing that guidance.

Technical Details

KNX Secure's Connection Authorization process includes an account lockout mechanism intended to slow brute-force attacks against device authentication. According to CISA's advisory, this lockout mechanism is "overly restrictive": an attacker who repeatedly sends invalid connection authorization requests to a device can trigger the lockout logic itself, causing the device to purge all paired devices (where additional security options are not enabled) and set the Bus Coupling Unit (BCU) key to a locked state. This turns a security control meant to prevent credential guessing into a remotely triggerable denial-of-service and device-state-reset primitive. The CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects an availability-only impact reachable over the network with no authentication or user interaction required — consistent with a lockout/DoS mechanism rather than data exposure or code execution.

Discovery

CISA's advisory does not credit a specific named researcher; ICSA-23-236-01 was coordinated through CISA's standard ICS vulnerability disclosure process with the KNX Association.

Exploitation Context

At the time of the original 2023 ICS advisory, no known public exploitation was reported. CISA's addition of CVE-2023-4346 to the KEV catalog in July 2026 indicates the agency later confirmed active exploitation, though public reporting on the specific campaign or threat actor involved is limited — building automation and OT-adjacent vulnerabilities frequently see delayed, low-volume, and less publicly documented exploitation compared to enterprise IT flaws. Given KNX's prevalence in building management systems, successful exploitation would primarily manifest as loss of control over lighting, HVAC, or access systems rather than data theft.

Remediation

1. Check with your KNX device manufacturer for firmware updates or configuration guidance addressing this account lockout behavior — since this is a specification-level issue, fixes are distributed per-vendor rather than through a single patch.
2. Segment KNX/building automation networks from general IT networks and the internet; KNX IP interfaces should never be directly internet-reachable.
3. Monitor for repeated failed connection authorization attempts against KNX Secure devices, which may indicate an attacker deliberately triggering the lockout condition.
4. Have a recovery plan for locked devices: since exploitation can require manual/physical intervention to restore devices whose BCU key has been locked, ensure facilities staff know the vendor-specific recovery procedure before an incident occurs.
5. Review KNX Association guidance on securely configuring Connection Authorization and consider migrating to security options less susceptible to this lockout abuse where supported by your devices.