Is CVE-2023-4346 (KNX Association KNX Protocol Connection Authorization Option 1 Overly Restrictive Account Lockout Mechanism) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2023-4346 to its Known Exploited Vulnerabilities catalogue on 15 July 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. KNX Association KNX Protocol Connection Authorization Option 1 contains an overly restrictive account lockout mechanism vulnerability that could allow an attacker to purge all devices without additional security options enabled and set a BCU key to lock the device.

What “being exploited in the wild” means for this CVE

For a vulnerability already listed in CISA’s KEV catalogue, the practical answer is that the issue is not just theoretical. Active exploitation means defenders should treat exposure as urgent, confirm whether the vulnerable KNX Protocol connection authorization option 1 is present, and assume the attack path may already be known and repeatable. The key question becomes whether any connected devices still expose the vulnerable authorization behaviour.

Because CISA has placed this CVE in KEV, the right response is to follow the vendor advisory and CISA’s required action rather than rely on general patch cadence. For KNX environments, that usually means identifying which devices use the affected option, checking whether the additional security options are enabled, and validating whether any device can still be purged or locked through the faulty mechanism.

External context matters here: the national vulnerability record helps confirm the exact CVE entry, while the KEV catalogue is the authoritative signal that exploitation has moved beyond “possible” into “observed.” Readers should use the CVE Program for the identifier record and the CISA Known Exploited Vulnerabilities Catalog for the exploitation status and required remediation posture.

How to confirm exposure and reduce blast radius

The first practical step is to inventory KNX-connected devices and determine whether they are using the vulnerable authorization option. If the vulnerable option is deployed, exposure is not abstract, because the flaw can affect device integrity and availability in ways that are difficult to recover from once abuse begins. Confirm whether any management workflows still depend on legacy or default settings that leave the device open to purge or lockout abuse.

If patching or device replacement is not immediately possible, reduce the reachable surface around the affected systems. Restrict who can administer KNX devices, segment management access from general network traffic, and remove unnecessary paths that could let an attacker issue authorization-related commands. Where the platform supports stronger security options, enable them before assuming the device is safe to leave online.

The practical point is that this kind of flaw is not only about software versioning, it is about whether the deployment still allows the dangerous behaviour to be exercised. The NIST National Vulnerability Database is useful for tracing the record, while the vendor advisory should be used for the exact device and configuration guidance.

What to do if you cannot remediate immediately

When remediation must wait, assume the environment should be treated as potentially hostile until proven otherwise. Preserve logs, review management access, and look for unexplained device resets, configuration changes, or loss of device availability that could indicate misuse of the authorization path. If the devices support event logging, retain that evidence before making changes that could overwrite it.

In operational terms, this is the point to decide whether the risk is acceptable for business continuity. If the vulnerable function protects equipment that is safety-critical, production-critical, or difficult to rebuild, temporary compensating controls should be tighter than usual, and the exception should be time-bound. Do not let “we have not seen abuse” become the basis for delay once KEV has confirmed active exploitation.

For teams that manage many exposed systems, vulnerability triage should follow the same logic used for other actively exploited issues: use the KEV entry as the priority signal, then verify whether the vulnerable function is reachable in your environment. The FIRST EPSS can support prioritisation, but it should not override KEV when exploitation is already confirmed.

Risk and Threat Considerations

This CVE is operationally dangerous because the failure mode is not limited to leakage or minor misbehaviour. If an attacker can trigger the authorization weakness, they may be able to disrupt or purge connected devices, which turns a vulnerability in access control into an availability and integrity event.

Failure mechanism: The device accepts a weak or overly restrictive lockout path in a way that lets an attacker abuse authorization handling and force destructive actions without the extra protection that should prevent them.

Impact: The likely outcome is device disruption, loss of availability, and potential loss of trust in the affected KNX control plane, especially if the vulnerable function is reachable across multiple devices or sites.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires priority remediation and exposure tracking.
Recommendation — Prioritize and remediate KEV-listed vulnerable assets before routine backlog work.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Confirm exposure and track the vulnerable KNX devices in scope.
	SI-2 — Flaw Remediation	The CVE requires remediation or mitigation once active exploitation is confirmed.
Recommendation — Continuously identify and track vulnerable assets until exposure is removed. Apply vendor remediation or compensating mitigations as soon as exposure is verified.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	The answer depends on confirming which devices are exposed to the vulnerable option.
	PR.IR-01 — Networks and environments are protected from threats and vulnerabilities	Compensating controls reduce reachable exposure while remediation is pending.
Recommendation — Document exposed devices and the vulnerable configuration before assigning remediation priority. Segment and restrict access paths to limit attacker reach until remediation is complete.

Practitioner Guidance

What to prioritise: Treat KEV-listed exposure as a live remediation queue item, not a backlog item. Confirm whether any production KNX device still exposes the vulnerable option, then rank those systems ahead of routine hardening work.

What to verify: Verify the exact device model, deployment setting, and management path before assuming the issue is fixed. If the authorization option remains enabled anywhere in the fleet, assume the environment still needs compensating controls even after patching plans are in motion.

Practitioner takeaway: Once CISA has placed a CVE in KEV, the operational question is no longer whether exploitation is possible, but whether your environment still leaves the vulnerable behaviour reachable.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org