KNX Protocol Connection Authorization Option 1: Overly Restrictive Account Lockout Mechanism (CVE-2023-4346)

What is affected, what to do

KNX devices that use KNX Connection Authorization and support Option 1 are, depending on the implementation, vulnerable to being locked and users being unable to reset them to gain access to the device. The BCU key feature on the devices can be used to create a password for the device, but this password can often not be reset without entering the current password.

The vulnerability is being actively exploited; treat it as a priority. The available sources name no fixed version. Check the vendor guidance in the references below. Immediate actions, mitigation and detection rules are in the runbook below.

Affected

• KNX Protocol Connection Authorization Option 1 eq 0..0

Not sure whether and how you are affected? Ask a question about this vulnerability

Metrics

Response and mitigation

1. 01

   Runbook step 1

   Immediate response (0-24 h)

   • Remove KNXnet/IP exposure now: Block inbound UDP/TCP 3671 (KNXnet/IP tunnelling/routing) from the internet and from untrusted segments at the perimeter firewall. Check your public IP space with external scanning services for reachable KNX IP interfaces or routers. No vendor patch exists, because the weakness lies in the protocol and implementations of Connection Authorization Option 1. Check each manufacturer's advisory to see whether a firmware update can harden individual devices.
   • Set your own BCU keys before an attacker does: In ETS, assign a unique BCU key (device password) to every device that supports Option 1. Store the keys in your password vault, and back up the encrypted ETS project offline.
   • Cut remote access paths: Temporarily disable integrator VPN and cloud remote-maintenance access to KNX IP gateways, or restrict it to known ETS workstations. Rotate any shared credentials.
   • Inventory and back up: Enumerate all KNX lines, IP interfaces, line couplers and their ETS project files. Preserve the current project state, because without it you cannot reprogram devices after a purge.
   • Secure physical access: Lock distribution boards and cabinets that house KNX bus couplers, and review exposed bus wiring such as push buttons in public areas. The attack also works locally over the TP bus.
   • If devices are already locked: Isolate the affected devices and contact the manufacturer, because a reset is often only possible at the factory. Document the incident, and assess NIS2 reporting obligations: an early warning is due within 24 h for a significant incident.
2. 02

   Runbook step 2

   Mitigation layers

   • Network segmentation: Place KNXnet/IP in a dedicated BAS/OT VLAN with no routing to IT or guest networks. Permit UDP 3671 only from designated ETS engineering hosts to the gateways. Do not forward KNX routing multicast (224.0.23.12) across VLAN boundaries.
   • Enable KNX Secure: Deploy KNX IP Secure (authenticated, encrypted tunnelling) and KNX Data Secure wherever devices support them. Per the advisory, devices with additional security options enabled cannot be purged this way.
   • Harden remote maintenance: Route all access through a jump host with MFA and session recording. Avoid permanent port forwards to KNX IP interfaces, and grant integrator access only in time-boxed windows.
   • IPS/firewall rule: Add a Suricata rule on udp any any -> $KNX_GW 3671 that alerts on any source outside $ETS_HOSTS. Supplement it with a rate-based rule for bursts of TUNNELLING_REQUEST packets.
   • Configuration governance: Define contractually who holds the BCU keys and who may enter programming mode. The building operator, not only the integrator, must hold the keys.
3. 03

   Runbook step 3

   Detection rules

   • Network telemetry (Zeek/firewall): Alert on new source IPs talking to UDP 3671, e.g. with SPL: index=fw dest_port=3671 NOT src_ip IN (ets_hosts) | stats count by src_ip, dest_ip. Treat any internet-sourced session as critical.
   • KNX payload inspection (Wireshark knxnetip dissector, ICS NDR): Flag APCI services A_Key_Write, A_Authorize_Request, bulk A_Memory_Write and A_Restart, and unload sequences sent to many individual addresses outside approved maintenance windows.
   • Behavioural pattern: A tunnelling CONNECT_REQUEST followed by sequential addressing of many physical addresses within minutes indicates a scan or purge run. A reasonable threshold is more than 20 distinct target addresses per connection.
   • Operational indicators: Watch for simultaneous loss of lighting, shading or HVAC functions in the building management system. Also treat ETS errors such as "access denied" or an unknown BCU key on devices you never keyed as indicators.
   • Gateway logs: Where KNX IP routers and interfaces provide syslog or event logs, review them for tunnelling sessions from unknown clients and for occupied tunnel slots.

Detection rules

No NEOSEC detection rule is available for this vulnerability yet.

Classification under NIS2 and CRA

Rule-based classification from exploitation status and severity. It does not replace a case-by-case assessment.

NIS2

NIS2 is EU Directive (EU) 2022/2555 to raise the level of cybersecurity across the Union. It substantially broadens obligations compared with the first NIS directive: more sectors, mandatory risk management, staged reporting duties and personal accountability of senior management.

Read in glossary

Actively exploited: treat the vulnerability as a priority in vulnerability handling under Art. 21(2)(e) NIS2. If it is exploited in your environment, check the reporting obligation under Art. 23 (early warning within 24 hours).

CRA

The CRA is EU Regulation (EU) 2024/2847 setting horizontal cybersecurity requirements for „products with digital elements“ — from industrial controllers and software to connected consumer devices. For the first time manufacturers must ensure security across the entire product lifecycle, handle vulnerabilities and provide security updates.

Read in glossary

Since 11.09.2026, manufacturers of affected products with digital elements must report actively exploited vulnerabilities under Art. 14 CRA, with an early warning within 24 hours via ENISA's single reporting platform.

ISO/IEC 27001

ISO/IEC 27001 is the internationally leading standard for an information security management system (ISMS). It describes a risk-based, process-oriented framework to systematically plan, implement, review and improve information security.

Read in glossary

Control A.8.8, management of technical vulnerabilities: assess relevance to your systems, plan remediation and keep evidence.

Description

KNX devices that use KNX Connection Authorization and support Option 1 are, depending on the implementation, vulnerable to being locked and users being unable to reset them to gain access to the device. The BCU key feature on the devices can be used to create a password for the device, but this password can often not be reset without entering the current password. If the device is configured to interface with a network, an attacker with access to that network could interface with the KNX installation, purge all devices without additional security options enabled, and set a BCU key, locking the device. Even if a device is not connected to a network, an attacker with physical access to the device could also exploit this vulnerability in the same way.

Source: cisa_ics_advisory, CISA KEV Catalog, NVD (NIST), cvelistv5

Weakness classes (CWE)

• CWE-645Overly Restrictive Account Lockout Mechanism

  Base

  The product contains an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.

  Entry at MITRE CWE-645

References & sources

• cisa.govnews-events/ics-advisories/icsa-23-236-01government-resource
• cisa.govknown-exploited-vulnerabilities-catalog?field_cve=CVE-2023-4346government-resource

Changes to this CVE

Who changed this CVE and when: NVD (analysis, affected products, CVSS), the CVE publisher (CNA) and additional providers such as CISA (ADP).

1. 15.07.2026CISA KEV entry updated9119a7d8…

   4 individual changes: Date Added, Due Date, Required Action, Vulnerability Name

   Show 4 original changes

   Individual changes of this event as published by NVD

   Type	Action	Before	After
   Date Added	added	—	2026-07-15
   Due Date	added	—	2026-07-15
   Required Action	added	—	2026-07-15
   Vulnerability Name	added	—	2026-07-15

   Source identifier: 9119a7d8-5eab-497f-8521-727c672e3725

2. 15.07.2026Record modifiedCISA ADP

   CISA assessment (SSVC): exploitation: active, automatable: yes

   New references:

   • https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-4346
   Show 2 original changes

   Individual changes of this event as published by NVD

   Type	Action	Before	After
   Reference	added	—	https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-4346
   SSVC assessment	changed	{"id":"CVE-2023-4346","role":"CISA Coordinator","options":[{"exploitation":"none"},{"automatable":"yes"},{"technicalImpact":"partial"}],"version":"2.0.3","timestamp":"2024-10-01T20:32:19.712035Z"}	{"id":"CVE-2023-4346","role":"CISA Coordinator","options":[{"exploitation":"active"},{"automatable":"yes"},{"technicalImpact":"partial"}],"version":"2.0.3","timestamp":"2026-07-15T17:34:25.185393Z"}

   Source identifier: 134c704f-9b21-4f2e-91b3-4a467353bcc0

Linked advisories

• @RISK®: The Consensus Security Vulnerability Alert: Vol. 26, Num. 28SANS @RISK23.07.2026