GPU VulnDB

Database/Control plane, storage & DevOps

KNX devices using KNX Connection Authorization Option 1 (BCU key): An attacker sets the BCU key on KNX devices

CVE-2023-4346Control plane, storage & DevOpsKnown exploitedcurated

Impact

An attacker sets the BCU key on KNX devices and permanently locks legitimate operators out - the device cannot be reset or reprogrammed without vendor intervention or physical replacement. This is in CISA's Known Exploited Vulnerabilities catalog, and it has been used in the wild to brick building-automation installations. Where KNX drives lighting, HVAC zone control or blinds in a facility, this is a denial of service you cannot recover from with a reboot or a firmware push: the devices are electronically bricked and the fix is a truck roll with replacement hardware, potentially across every affected device on the bus. In a datacenter context the exposure is usually peripheral rather than core cooling - KNX is more common in European commercial buildings than in purpose-built halls - but it appears in mixed-use and converted buildings, and in office and ancillary space attached to a datacenter. The operator-facing point is the recovery profile: unlike almost everything else on this list, there is no software remedy after the fact.

Who can reach it

Any device that can send telegrams on the KNX bus, or on a KNXnet/IP segment that routes onto it. KNX has no meaningful authentication in its classic form, so this requires only reachability. That means the building network, a KNX/IP router bridging segments, or physical access to the twisted-pair bus in an accessible space.

What to do

Prevention only - once devices are locked, recovery means vendor unlock procedures where they exist or hardware replacement. Set the BCU key yourself to a known value on every device during commissioning so an attacker cannot claim it, and record it securely. Isolate KNXnet/IP strictly: no route from tenant, corporate or internet networks to the KNX segment, and audit every KNX/IP router for whether it is bridging more than it should. Where the installation supports it, migrate to KNX Secure (KNX Data Secure / IP Secure), which adds authentication and is the actual fix - a device-by-device upgrade project. Given the KEV listing, treat any internet-reachable KNXnet/IP interface as an emergency.

References

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.