CVE-2026-102537: bacnet-stack BACnet/SC node always accepts a self-signed hub cert, so an attacker can MITM it
BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to versions 1.4.6, 1.5.2, and 1.6.1, bwscliconnect() in ports/linux/websocket-cli.c loads the trusted CA cert into the libwebsockets context, then always sets LCCSCFALLOWSELFSIGNED in the connection flags. So lws accepts any self-signed hub certificate, whether or not it chains to the loaded CA. A BACnet/SC node finishes the TLS handshake to a rogue hub that presents a self-signed cert. It then hands the attacker its identity (VMAC, UUID) and all later BACnet traffic. This issue has been patched in versions 1.4.6, 1.5.2, 1.6.1, and 1.7.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
bacnet-stackto a version that resolves this vulnerability.Fixed in 1.4.6 - Upgrade
Upgrade
bacnet-stackto a version that resolves this vulnerability.Fixed in 1.5.2 - Upgrade
Upgrade
bacnet-stackto a version that resolves this vulnerability.Fixed in 1.6.1 - Upgrade
Upgrade
bacnet-stackto a version that resolves this vulnerability.Fixed in 1.7.0
Event History
Frequently Asked Questions
Which deployments are exposed?
BACnet/SC nodes using the affected bws_cli_connect() implementation in ports/linux/websocket-cli.c are exposed. Versions before 1.4.6, 1.5.2, and 1.6.1 are affected; the issue is patched in 1.4.6, 1.5.2, 1.6.1, and 1.7.0.
What does an attacker need to exploit this issue?
An attacker needs to impersonate a BACnet/SC hub and present a self-signed TLS certificate to the node. The node can complete the TLS handshake even when that certificate does not chain to the configured trusted CA.
What information and traffic can be exposed after exploitation?
After connecting to the rogue hub, the node provides its VMAC and UUID to the attacker. Subsequent BACnet traffic is also sent through the attacker-controlled hub.
Is configuring a trusted CA sufficient to prevent the issue in affected versions?
No. Although the client loads a trusted CA certificate into the libwebsockets context, it also enables acceptance of self-signed certificates, allowing an unrelated self-signed hub certificate to be accepted.