HID Mercury intelligent controllers sold by Carrier LenelS2 (LNL-X2210/X2220/X3300/X4420/4420

Impact

A full chain against the access-control panel generation that sits underneath a very large share of enterprise and datacenter badge systems, including Lenel OnGuard and S2 deployments: unauthenticated command execution via a crafted hostname, an unauthenticated buffer overflow in the update path, unauthenticated deletion of web-interface users, and authenticated path traversal and command injection. CISA's own summary is that an attacker gets device access, can monitor all communications to and from the panel, and can modify the onboard relays - the relays are the door strikes. So this is not badge-database tampering, it is direct electrical control of whether a door opens, plus visibility into every badge read at that panel. Someone who walks into your cage on the back of this can pull drives containing model weights and customer data, attach a console to a running node, or plug into the out-of-band switch and reach every BMC in the row. Because HID Mercury panels are OEM'd under multiple brands, many operators do not know they have them - check the board, not the badge software's vendor name.

Who can reach it

Unauthenticated network access to the panel for the worst of the set. Panels sit on the physical-security VLAN, usually in back-of-house electrical or comms closets, sometimes in the same closets tenants and contractors can reach. The multi-brand OEM situation widens exposure: a site can have Mercury boards behind three different vendors' software without a single asset record naming Mercury.

What to do

Firmware update from the OEM whose badge is on your panel - Carrier LenelS2 published fixed firmware, and other Mercury OEMs issued their own. Identify the actual board model first (LNL-X2210 and friends, S2-LP-*), because the fix tracks the board, not the head-end software. Applying it is a security-integrator engagement with doors in local fallback during the flash, so it needs security staff on site. After patching, assume any panel exposed during the vulnerable window may have had relays or user accounts manipulated: audit the badge database, the panel user list, and the relay configuration against a known-good baseline. Long term, put the physical-security VLAN behind a firewall with an explicit allow-list from the head-end only, and enable port security on the switch ports serving panels.

References