ABB Won't Patch This KNX Bug. The Reason Why Is the Actual Story.
On 28 July 2026, the US Cybersecurity and Infrastructure Security Agency published an advisory on behalf of ABB about a flaw in its KNX Update Tool, the software technicians use to push firmware onto KNX field devices over the bus. Tracked as CVE-2026-12705, it lets someone tamper with a firmware image before it lands on a device, potentially bricking it or changing how it behaves.
The part that got attention wasn't the bug itself. It was ABB's answer to "when's the fix coming." There isn't one. Not delayed, not scheduled. The advisory says the missing security capability "cannot be delivered with a software update," full stop.
What the advisory actually says
The flaw sits in the ABB and Busch-Jaeger KNX Update Tool, versions through 2.0.175. It has no integrity check on the firmware images it installs, classified as CWE-353, Missing Support for Integrity Check. There's no cryptographic signature or hash to confirm a firmware file is genuine before it's written to a device. Researchers from several universities, Qiguang Zhang, Zhen Ling, Junzhou Luo, Chongqing Lei, Xinwen Fu and Yue Zhang, reported it. ABB rated it CVSS 6.4 (v3.1) and 5.9 (v4.0), both medium.
Two things matter more than the score. First, exploiting it requires physical access to the KNX bus the device sits on. This is not a remote, over-the-internet attack. Second, it only affects "classic" KNX devices, the ones built before KNX Secure existed. ABB's position is that those devices were never designed with the hardware root of trust a firmware signature check needs, so there's nothing a patch can retrofit. The only real fix is replacing the device.
Why "physical access required" is the detail to focus on, not skip past
I'll be straight about why I'm covering this one. It's not because it's alarming, it's because it's a clean, real-world illustration of an argument I make constantly: a wired bus is a fundamentally different attack surface to a Wi-Fi network or a cloud-dependent hub.
To exploit this, someone needs to physically be at your KNX bus, at a distribution board, a comms cabinet, a junction box, with the update tool running or the ability to intercept traffic between it and a device. That's a meaningfully harder bar to clear than scanning the internet for an exposed IP address, which is exactly how a lot of consumer smart home gear gets compromised. It's also why this bug doesn't undermine the case for KNX. If anything it confirms the shape of the actual risk: not "hackers on the internet," but "who has physical access to my building, and is my installer treating that seriously."
ABB's own advice backs this up. Limit physical access to the bus. Don't use classic (non-Secure) KNX devices for sensitive functions. They specifically flag hotel room access control as an example. Segment building automation networks from general IT networks, and never expose the bus or its engineering tools directly to the internet. Monitor for unexpected update attempts.
Classic vs Secure, and why you can't half-fix it
KNX Secure, the encrypted, authenticated version of the standard, has been around since 2017. I've written before about what's actually in it, AES-128 encryption, per-telegram authentication and freshness protection, over 1,000 certified devices behind it. This CVE is what happens on the other side of that line. A classic device wasn't built to verify anything about a firmware image, and that gap can't be closed in software after the fact.
One detail worth knowing if you've got an older KNX installation: you can't mix secured and unsecured traffic on the same group address. Adding a few KNX Secure devices into an existing classic installation doesn't automatically protect the classic ones sitting on the same logical segment. Security has to be designed in per group address, which means someone has to actually look at what's on your bus and make a call, room by room, function by function, not assume newer bits of kit are quietly covering the old ones.
It's also worth remembering this isn't the only KNX advisory this year. In May, CISA flagged a separate, higher-severity flaw in ABB's EIBPORT gateway, a session management issue in its web interface. That one has a straightforward fix: update to firmware 3.9.2 or later. The contrast is useful. Some KNX security issues are a firmware update away. Others, like this one, are a hardware decision.
What this means for a project brief
If you've got an older KNX installation, particularly one doing access control, gates, or anything security-adjacent, this is worth a conversation with whoever maintains it. Two questions are enough to start: are the field devices classic or KNX Secure, and is the comms cabinet actually locked, not just tidy. On new projects, it's part of why I spec KNX Secure on anything touching entry to the property and keep the IP backbone on its own segment, off the general network, from day one.
Just a conversation about what the project needs.
Wayne | KNX Logic wayne@knxlogic.co.za | 082 564 3982 | www.knxlogic.co.za
Comments