KNX devices that use KNX Connection Authorization and support Option 1 are

KNX is the dominant fieldbus for European building automation — lighting, HVAC, shutters, access control. Devices that implement KNX Connection Authorization Option 1 rely on a shared BCU key (default 0xFFFFFFFF) that gates management operations. An attacker who reaches the KNX bus (TP1 twisted-pair, PL110 powerline, RF, or IP tunneling via KNXnet/IP routers) and knows or brute-forces the 4-byte key can issue a management command that overwrites the authorization key, effectively locking the device out of legitimate programming until a physical reset via ETS. Affected: any KNX device whose firmware implements the Connection Authorization scheme (Option 1) without rate limiting or key rotation — this covers a large fraction of the installed base from Siemens, ABB, Schneider (Merten), Gira, Jung, Hager, and others.

The vendor score of 7.5 (AV:N / no auth / A:H) is directionally right about impact but wrong about reachability. AV:N assumes any network attacker can reach the bus; in practice KNX is a segregated fieldbus and only becomes network-reachable when a KNXnet/IP router or interface is exposed to the routable LAN — or, in bad deployments, to the internet. Shodan consistently shows ~15,000–20,000 KNXnet/IP endpoints exposed globally, and once you're on the bus segment the attack is trivial and permanent-until-physical-reset. Call it a solid MEDIUM for typical enterprise smart-building deployments, HIGH if your facilities team has pushed KNX/IP onto the corporate VLAN or the internet.

Why this verdict

• Reachability is not AV:N in reality: KNX bus access requires physical port access, adjacent-VLAN position, or a misconfigured KNXnet/IP router. Vendor score assumes internet reachability that ~99% of installs don't have.
• Impact is genuine and expensive to recover from: rewriting the authorization key bricks devices until physical reset, and buildings with 100–1000+ KNX devices face days of facilities work per incident.
• Role multiplier: on residential/small-commercial KNX (typical role, ~90% of base) the blast radius is site-local nuisance. On enterprise campus / hospital / smart-office deployments (~10% of base), same chain still terminates at building-DoS — no domain, identity, or data plane impact. This is not an identity-tier or supply-chain-tier role, so the floor does not rise to HIGH.
• No KEV, negligible EPSS, no named campaigns — threat actor interest in building-automation DoS remains theoretical outside of hacktivism scenarios.
• Mitigation exists that doesn't require a firmware patch: setting per-device BCU keys via ETS or migrating couplers to KNX Secure closes the chain without vendor coordination.

Why not higher?

HIGH would require either fleet/identity-tier blast radius or realistic internet reachability across most of the installed base. KNX is neither — the bus is segregated by design, and even when locked, no data, credentials, or lateral movement follows. A building-DoS that requires bus-adjacent access does not clear the HIGH bar.

Why not lower?

LOW would ignore that ~17K KNXnet/IP endpoints are internet-exposed and that recovery is physical, per-device, and can take a facilities team down for days. For any org running KNX in a hospital, data center BMS, or large corporate campus, this is a real operational risk — MEDIUM, not backlog hygiene.

1. Segment KNXnet/IP off the corporate network — Put every KNXnet/IP router/interface on a dedicated OT VLAN with no route from user or DMZ networks. Block UDP/3671 at the perimeter and at inter-VLAN firewalls. Deploy within the noisgate 365-day remediation window — but if any KNXnet/IP endpoint is currently internet-reachable, treat that specific host as CRITICAL and firewall it within hours.
2. Rotate BCU keys off the default 0xFFFFFFFF — Use ETS to set a unique 32-bit authorization key per project (ideally per device). This alone defeats opportunistic attackers using default-key tooling. Coordinate with the facilities integrator; plan a maintenance window within 90 days.
3. Migrate to KNX Secure on new deployments and refreshes — KNX/IP Secure encrypts tunneling and routing; Data Secure encrypts management and group frames. Any device refresh should specify KNX Secure-capable hardware. This is the only durable fix — treat as a 12-month program aligned with the noisgate remediation SLA.
4. Instrument the OT network with a KNX-aware sensor — Nozomi Guardian, Claroty CTD, and Dragos Platform all parse KNXnet/IP. Alert on A_Authorize_Request bursts and any A_Key_Write from non-ETS sources. Provides the only real detection surface for this chain.
5. Physically secure TP1 terminals and unused ports — Lock BMS panels; disable unused USB/serial KNX interfaces in server rooms and public spaces. Removes the physical-access branch of the attack path.

Run this from an auditor workstation on the same VLAN as your KNXnet/IP routers (or on the OT jump host). It enumerates KNXnet/IP endpoints via SEARCH_REQUEST on UDP/3671 and checks whether any respond — the presence of reachable endpoints from an unexpected network segment is the vulnerable condition. No credentials required. Invoke: python3 knx_check.py 10.20.30.0/24.

#!/usr/bin/env python3
# knx_check.py -- noisgate reachability check for CVE-2023-4346
# Emits VULNERABLE / PATCHED / UNKNOWN
import socket, struct, sys, ipaddress

KNX_PORT = 3671
TIMEOUT = 1.5

# KNXnet/IP SEARCH_REQUEST (service 0x0201) with HPAI pointing at us on 0.0.0.0:0
def build_search_request(local_ip: str):
    header = bytes([0x06, 0x10, 0x02, 0x01, 0x00, 0x0E])  # ver, svc, total len 14
    ip_bytes = socket.inet_aton(local_ip)
    hpai = bytes([0x08, 0x01]) + ip_bytes + struct.pack('!H', 0)  # UDP HPAI
    return header + hpai

def probe(target: str) -> bool:
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    s.settimeout(TIMEOUT)
    try:
        pkt = build_search_request('0.0.0.0')
        s.sendto(pkt, (target, KNX_PORT))
        data, _ = s.recvfrom(1024)
        # SEARCH_RESPONSE service id is 0x0202
        return len(data) >= 4 and data[2] == 0x02 and data[3] == 0x02
    except socket.timeout:
        return False
    except Exception:
        return False
    finally:
        s.close()

def main():
    if len(sys.argv) != 2:
        print('usage: knx_check.py <cidr-or-host>', file=sys.stderr)
        sys.exit(2)
    target = sys.argv[1]
    hosts = []
    try:
        net = ipaddress.ip_network(target, strict=False)
        hosts = [str(h) for h in net.hosts()] if net.num_addresses > 1 else [str(net.network_address)]
    except ValueError:
        hosts = [target]

    responders = [h for h in hosts if probe(h)]
    if not responders:
        print('PATCHED: no KNXnet/IP endpoints responded on UDP/3671 in scope')
        sys.exit(0)
    print('VULNERABLE: KNXnet/IP endpoints reachable from this segment:')
    for h in responders:
        print(f'  - {h}:3671')
    print('Action: confirm each device runs KNX Secure OR has non-default BCU key OR is isolated on an OT VLAN.')
    sys.exit(1)

if __name__ == '__main__':
    try:
        main()
    except KeyboardInterrupt:
        print('UNKNOWN: interrupted')
        sys.exit(3)

Sources

1. NVD — CVE-2023-4346
2. KNX Association — Position Paper on Cybersecurity
3. Claroty Team82 — BOF (BUS Offensive Framework)
4. KNXmap — KNX/KNXnet/IP scanning tool
5. CISA ICS Advisory background on KNX authorization abuse
6. Shodan — KNXnet/IP exposure query (port:3671)
7. FIRST EPSS — CVE-2023-4346
8. MITRE CWE-645 — Overly Restrictive Account Lockout Mechanism