Summary
- CVE-2023-4346 has been added to the US government’s exploited-vulnerability catalogue.
- The flaw can set a Bus Coupling Unit key on insufficiently protected KNX devices, preventing legitimate operators from resetting them normally.
- Building owners need accurate inventories, network isolation, controlled remote access, and tested recovery arrangements.
An actively exploited vulnerability in KNX building-automation systems can allow an attacker with network access to lock affected devices and prevent legitimate operators from restoring normal control.
CVE-2023-4346 concerns KNX devices that use weak connection-authorisation settings. An attacker able to communicate with an installation can set a Bus Coupling Unit key, after which authorised users may be unable to reset the device or regain access through expected management procedures.
The US Cybersecurity and Infrastructure Security Agency added the flaw to its Known Exploited Vulnerabilities catalogue on 15 July 2026. Inclusion confirms evidence of exploitation, although the agency has not disclosed the affected organisations, sectors, countries, or circumstances.
Belgium’s Centre for Cybersecurity issued a warning after the catalogue addition. The vulnerability has a CVSS severity score of 7.5, while the operational effect will depend on the devices involved and the building functions connected to them.
KNX is used to integrate lighting, heating, ventilation, blinds, access controls, energy management, and other building systems. Installations can be found in offices, hotels, hospitals, airports, public buildings, homes, and industrial sites.
Digital access can interrupt physical services
The flaw does not need to expose a business database to create disruption. Where KNX equipment controls ventilation, lighting, access, environmental conditions, or energy use, loss of management access can affect the safety and usability of the building.
Building-automation devices also differ from conventional office endpoints. They may remain in service for decades, depend on specialist engineering tools, and sit under facilities-management contracts rather than the direct ownership of an IT department. Replacement equipment and qualified engineers may not be available immediately.
Because legitimate operators can be locked out, recovery arrangements need to cover more than patch deployment. Owners should know which devices support the affected setting, whether configurations have been backed up, which engineers are authorised to intervene, and how building services will operate while equipment is unavailable.
Network reachability determines much of the exposure. Building controls are commonly connected to wider enterprise systems for remote monitoring, energy reporting, central management, and maintenance. Those connections create operational efficiencies, but they may also provide a route from ordinary corporate infrastructure into systems that alter the physical environment.
Access provided to integrators and maintenance companies requires comparable scrutiny. Shared accounts, permanent remote connections, unmanaged engineering laptops, and weakly monitored gateways can undermine segmentation even when a building network appears separate in an architecture diagram.
Ownership is distributed across property suppliers
Responsibility for a KNX installation may be divided among a property owner, tenant, facilities operator, systems integrator, manufacturer, and maintenance provider. Each organisation may possess only part of the asset inventory, network design, or configuration record.
That division slows vulnerability response. A security team may receive an advisory without knowing which buildings contain the equipment, while a facilities contractor may recognise the devices but lack authority to alter network access or investigate suspicious traffic.
European product-security and critical-infrastructure rules are increasing expectations that connected equipment remains supportable, documented, and capable of receiving security fixes. Existing buildings, however, contain substantial estates installed before those expectations became standard procurement requirements.
Immediate work should identify reachable KNX interfaces, restrict management access to approved systems, review remote-maintenance routes, and confirm whether stronger KNX security options are enabled. Unexpected configuration activity and devices that become inaccessible without an operational explanation require investigation.
Future procurement should define secure configuration, recovery procedures, support periods, configuration records, and incident responsibilities across the property supply chain. Building controls that cannot be inventoried, isolated, or restored create an operational dependency without a reliable recovery path.
