No malware, no ransom, no patch: the KNXlock case

One word changed in a database

On 15 July 2026, inside the record for CVE-2023-4346, one field went from none to active.

It is the SSVC vector CISA maintains for every vulnerability: the exploitation entry. Until 1 October 2024 it read none. Since Wednesday it reads active, and the CVE entered the Known Exploited Vulnerabilities catalog with a 29 July due date.

The curious part is that the attack that CVE describes happened in October 2021.

What actually happened

The account comes from Limes Security, the Austrian firm that handled the case and later reported the vulnerability to CISA. In October 2021 a German engineering company asks for help: they had designed the automation system of a mid-sized site on KNX, the most widespread building automation standard in Europe. Someone had gotten in over the internet and locked the owners out.

The building held several hundred KNX components. Three quarters of them no longer worked.

No malware was used. No exploit was used. The attackers did two things, both of them provided for by the protocol. First, they unloaded the devices — in KNX terms, the operation that removes the application from the device. Second, they set the BCU key, the 4-byte password the standard provides to prevent unauthorised changes to devices.

1. 01
   Network access

   the KNX bus was reachable from the internet
2. 02
   UNLOAD

   the application is removed from the device — provided for by the protocol
3. 03
   SET BCU KEY

   4 bytes, the password the standard offers to lock out changes
4. 04
   No reset

   the vendors: devices are to be considered bricked

The analogy Limes uses is precise: it is like wiping a computer's hard disk and then setting a password on the disk. The machine powers on and does nothing, and without that password you can never install anything on it again.

The building had lost its intelligence. Not only the complex systems: light switches and shutter control too. The engineer recounted that in the end they ran the entire building in manual mode, rewiring components to operate them from the circuit breaker panel.

The vendor response

This is where the case stops being an IT security story and becomes a design story.

The engineering company called the device manufacturers. More than one. The answer was unanimous: no reset is possible, the devices are to be considered bricked. The advice: rip out and replace everything. Between hardware, installation and verification, over one hundred thousand euros.

It was not a vendor mistake. The BCU key does exactly what it was designed to do: stop anyone from modifying a device without knowing the password. It worked perfectly. It just wasn't the owner who set it.

This is what makes the case different from the usual ones. There is no memory vulnerability, no unvalidated input, no wrong line of code. The assigned CWE is 645, Overly Restrictive Account Lockout Mechanism: the flaw is that the lockout mechanism is too effective. And indeed no patch exists. The CISA advisory does not say "update": it says to set the BCU key in every already-completed KNX project and hand it to the building owner with the documentation. The defence is to take the seat before someone else takes it.

Limes did recover the keys in the end, but by an unintended route: dumping memory directly from the device CPUs — possible only where CPU protection was not enabled — and brute-forcing only the region where the key was plausibly written. Brute-forcing the authentication directly had been discarded immediately: the devices respond so slowly it would have taken years.

The detail that says everything

The CVSS vector assigned by ICS-CERT is AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Base score 7.5.

Look at the last three letters.

Nothing is stolen. Nothing is altered. The building simply stops. It is the most unusual risk profile you will see in a CVE, and it describes with precision an attack that did not want data.

And the ransom? It never came. No demand, no contact. Limes offers two hypotheses, stated as such: either this was advanced digital vandalism, or the attackers could not work out from the internet who to address the note to. We do not know, and anyone telling you otherwise is guessing.

1. October 2021
   The attack

   A German engineering company loses control of the building. Three quarters of the components out of service.

2. March 2023
   The technique

   MITRE creates T0892 Change Credential. Contributor: Felix Eberstaller, of Limes.

3. August 2023
   The CVE

   CISA publishes ICSA-23-236-01. CVE-2023-4346, CVSS 7.5.

4. October 2024
   exploitation: none

   CISA's SSVC vector says: no exploitation observed.

5. 15 July 2026
   exploitation: active

   The CVE enters the KEV catalog. Due date: 29 July.

What we declare we do not know

A lot, in this case.

There is no attribution: no group, no nationality, no confirmed motive. CISA writes that it has received reports of active exploitation, but publishes no indicators, no victim counts, no time window. The figure of 16,000 potentially vulnerable systems in the DACH region comes from Alpha Strike Labs scans reported by Limes in August 2023: it is an exposure estimate, not a compromise count, and it is three years old. Above all we do not know why CISA flagged a CVE dormant since 2023 right now — whether there are new 2026 cases or whether this is a reclassification of known reports. The one documented fact is that Limes was still receiving attack reports in 2023, two years after the first case.

On the MITRE ID the ground is solid, and the chain is verifiable: T0892 Change Credential was created on 30 March 2023 in the ATT&CK for ICS matrix, the credited contributor is Felix Eberstaller — the same Limes researcher who reported CVE-2023-4346 to CISA — and the technique description cites "a chain of incidents occurred in Germany, where adversaries locked operators out of their building automation system (BAS) controllers by enabling a previously unset BCU key". This is not a reasoned mapping: it is the technique born from this case.

The only other example MITRE lists under T0892 is worth the trip on its own: during the 2025 Poland wiper attacks, the adversaries changed the password on Moxa NPort serial device servers to impede recovery. Different context, same idea. The lesson of KNXlock is not about KNX.

What to take away

Industrial control protocols are more powerful than most people imagine, and the protective features they contain do not know who the rightful owner is. They only know who got there first.

If you run a KNX installation: the BCU key must be set, in every project, and handed to the client with the documentation. A key you set is a key nobody else can set. The rest is the fundamentals CISA has been repeating for twenty years, and they matter more here than elsewhere because there is no patch to act as a net: control devices not reachable from the internet, automation network separated from the corporate one, remote access only through an updated VPN — remembering that a VPN is only as secure as the devices attached to it.

And if you have a backup of the configuration but not of the key, you do not have a backup.