CVE-2025-59103: Access Manager 92xx Auth Bypass Vulnerability

CVE-2025-59103 Overview

CVE-2025-59103 is a critical hardcoded credentials vulnerability affecting Dormakaba Access Manager 92xx devices in hardware revision K7. This newer hardware revision transitioned from Windows CE embedded to a Linux-based platform, inadvertently exposing an SSH service on port 22 with weak, hardcoded user credentials that can be easily guessed or exploited by attackers.

Through firmware analysis, security researchers discovered that two user accounts exist with hardcoded and weak passwords. While the system is designed to randomize at least one user's password after initial deployment, this randomization only occurs if the configured date is prior to 2022. This creates multiple scenarios where the default weak credentials remain active, including when the device clock has never been set, the clock module battery has been replaced, the device has been factory reset without receiving a time update, or other time synchronization issues.

Critical Impact

Attackers with network access can authenticate to exposed SSH services using hardcoded or easily guessable credentials, potentially gaining full administrative control over physical access control systems.

Affected Products

• Dormakaba Access Manager 92xx (Hardware Revision K7)
• Linux-based firmware versions with exposed SSH service on port 22

Discovery Timeline

• 2026-01-26 - CVE-2025-59103 published to NVD
• 2026-01-26 - Last updated in NVD database

Technical Details for CVE-2025-59103

Vulnerability Analysis

This vulnerability stems from a fundamental security design flaw in the hardware transition from Windows CE to Linux-based firmware. The introduction of an SSH service on port 22 without proper credential hardening creates a direct network attack vector. The hardcoded credentials represent a classic example of CWE-1391 (Use of Weak Credentials), where default or easily guessable authentication values are embedded within the device firmware.

The conditional password randomization mechanism introduces additional risk. The system's reliance on a date check (requiring the date to be prior to 2022) to trigger password randomization creates a race condition where multiple real-world scenarios can prevent the security measure from activating. Devices deployed after 2022 with correct time settings, devices with battery failures in the clock module, or factory-reset devices without NTP synchronization will retain the original weak credentials.

Root Cause

The root cause is two-fold: first, the inclusion of hardcoded user accounts with weak, easily guessable passwords in the device firmware; second, a flawed password randomization mechanism that only activates under specific time-based conditions. The password randomization logic that checks whether the configured date is prior to 2022 creates a security gap where the protective measure fails to execute under common operational scenarios.

Attack Vector

This vulnerability is exploitable over the network by any attacker who can reach port 22 on the affected device. The attack requires no prior authentication or user interaction. An attacker can:

1. Identify exposed Access Manager 92xx devices through network scanning for port 22
2. Attempt authentication using the hardcoded default credentials
3. If credentials have not been randomized, gain SSH access to the device
4. Leverage access to manipulate physical access control systems

The exploitation is particularly straightforward because the passwords were designed to be weak and guessable, and firmware analysis has revealed the credential patterns. No sophisticated tooling or techniques are required beyond basic SSH client capabilities.

Detection Methods for CVE-2025-59103

Indicators of Compromise

• Unexpected SSH connections to Access Manager 92xx devices on port 22
• Authentication attempts using default or known weak credentials against the device
• Unusual administrative activity or configuration changes on access control systems
• Login events from unauthorized IP addresses in device logs

Detection Strategies

• Monitor network traffic for SSH connection attempts to Access Manager 92xx devices
• Implement network segmentation to isolate physical access control devices and alert on cross-zone SSH traffic
• Deploy honeypot accounts or connection alerts for SSH access attempts on these devices
• Review device authentication logs for successful logins using default accounts

Monitoring Recommendations

• Enable logging for all SSH authentication events on affected devices
• Configure SIEM rules to alert on successful SSH logins to access control infrastructure
• Perform regular network scans to identify devices with exposed SSH services on port 22
• Monitor for firmware or configuration changes on Access Manager devices

How to Mitigate CVE-2025-59103

Immediate Actions Required

• Identify all Dormakaba Access Manager 92xx devices with hardware revision K7 in your environment
• Change all default user passwords immediately to strong, unique credentials
• Restrict network access to port 22 using firewall rules or network segmentation
• Verify device clock settings are configured correctly with NTP synchronization
• Review access logs for any signs of unauthorized access

Patch Information

Consult the Dormakaba Security Advisory for official vendor guidance and firmware updates. Additional technical analysis is available from SEC Consult's DKAccess research and SEC Consult's Dormakaba analysis.

Workarounds

• Disable the SSH service if remote management is not required
• Implement network-level access controls to restrict SSH access to authorized management stations only
• Deploy a VPN or jump host architecture to prevent direct network exposure of device management interfaces
• Configure firewall rules to block inbound connections to port 22 on affected devices from untrusted networks

# Example: Block SSH access to Access Manager devices using iptables
# Replace 192.168.1.0/24 with your Access Manager network segment
# Replace 10.0.0.5 with your authorized management station IP

iptables -A INPUT -p tcp --dport 22 -d 192.168.1.0/24 -s 10.0.0.5 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -d 192.168.1.0/24 -j DROP