dormakaba evolo Service: unauthenticated SYSTEM RCE (CVE-2026-37719)
An attacker who reaches the internal network can run code as SYSTEM in dormakaba evolo Service, the access-control programming backend. No patch exists.
Who is affected
- dormakaba evolo Service, all versions: a Windows service based on .NET remoting
- dormakaba evolo Manager (KEM) installations that use CardLink update terminals, which require the service
- evolo Manager installations WITHOUT the evolo Service are not affected
How to fix
No fixed version exists; the vendor prescribes containment, not patching. If CardLink update terminals are not used, deinstall the evolo Service completely. If it is needed, run its host in a protected network with no external connectivity and enable a host firewall restricting inbound traffic to the exact CardLink terminals in use, per dormakaba advisory DKSA-26-31-031. Place the access-control server on a dedicated VLAN, isolated from corporate and guest networks, and inventory every host running the service.
What happened
Dormakaba advisory DKSA-26-31-031, published March 31, 2026, describes an unauthenticated remote code execution flaw in the dormakaba evolo Service, a Windows service built on .NET remoting. The service deserializes untrusted data (CWE-502), so any attacker who can reach its network port can execute arbitrary code with SYSTEM privileges. The advisory went out with the CVE left pending, and the CVE-2026-37719 identifier surfaced in the NVD only on October 5, 2026: 9.8 per NVD CVSS 3.1, 9.3 per the vendor's CVSS v4.0. All versions of the service are affected and no fixed version has been released.
Why it matters for a hotel
The evolo Service is a programming backend for electronic access control: it runs where evolo Manager (KEM) installations use CardLink update terminals. Owning this service at SYSTEM level means controlling the machine that programs locks and credentials: door configurations can be altered, access rights issued, and the host turned into a foothold toward operational networks. In practice, access-control servers are rarely segmented onto dedicated VLANs, which makes an internal foothold disproportionately damaging.
Who is affected
- Every dormakaba evolo Manager (KEM) property that uses CardLink update terminals and therefore runs the evolo Service.
- All versions of the evolo Service, on every Windows host where it is installed.
- Properties running evolo Manager without the evolo Service are not affected, and dormakaba states the service can be deinstalled when CardLink terminals are not in use.
- Per the vendor, exploitation is only possible from inside the internal network: an attacker first needs a foothold (a compromised workstation, an uncontrolled port, a guest network routed to the back office).
How to fix
- If CardLink update terminals are not used, deinstall the evolo Service completely. This is the vendor's recommended option.
- If the service is required, operate its host in a protected network with no external connectivity.
- Enable the host firewall and restrict inbound traffic to the exact terminals used as CardLink update stations; block everything else.
- Place the access-control server on a dedicated VLAN, isolated from corporate and guest networks.
- Inventory every host running the service, and monitor those hosts for unexpected child processes, new local accounts or unusual logins.
Context
The vendor published its advisory on March 31 with the CVE still pending; the CVE only appeared on October 5, six months later, which left the flaw invisible to CVE-based tooling for most of that window. No exploitation has been reported: the flaw is not in CISA KEV and no public proof-of-concept is known. The wider dormakaba advisory page also lists DKSA-26-23-101 (October 21, 2026, CVSS 9.2, PHP2Shell) covering the exos 9300, MATRIX, evolo Manager, evolo smart, exivo, resivo, B-COMM, skyra, EntriWorX, Keyscan, Ambiance and Community lines, which confirms PHP in access-control software lines affected by the October PHP campaign.