Breaking Physical Access Control: Exploiting the Paxton Net2 Ecosystem

TLDR: Researchers at BSides London 2025 demonstrated a series of critical vulnerabilities in the Paxton Net2 access control system, including unauthenticated remote code execution and authentication bypass. By reverse-engineering the proprietary communication protocol and custom encryption, they gained full control over door controllers and credential management. This research highlights the danger of relying on security through obscurity and hardcoded cryptographic keys in physical security hardware.

Physical security systems are often the forgotten stepchild of enterprise security. While we spend thousands of hours hardening cloud infrastructure and patching web applications, the hardware controlling the literal doors to our data centers often runs on decades-old, poorly audited protocols. The recent research presented at BSides London 2025 on the Paxton Net2 system proves that these devices are not just vulnerable; they are often wide open to anyone with a basic understanding of network traffic analysis.

The Anatomy of the Failure

The researchers focused on the communication flow between the Net2 server and the door controllers. Most security professionals assume that physical access control systems use robust, industry-standard encryption. Instead, they found a proprietary protocol that relies on security through obscurity. The system uses a combination of Base64-encoded XML and custom encryption routines that are easily bypassed.

By using Wireshark to capture traffic, the team identified that the server communicates with controllers over TCP port 10001, while configuration tasks occur over UDP port 30718. The most alarming discovery was that the system uses hardcoded cryptographic keys to protect its communication. Once these keys were extracted via Ghidra, the entire encryption scheme collapsed.

Exploiting the Protocol

The research identified four distinct vulnerabilities, cataloged as CVE-2024-45950, CVE-2024-45948, CVE-2024-45949, and CVE-2024-45951. The most severe of these allow an attacker to bypass authentication entirely. Because the system trusts any command sent from a recognized IP address, an attacker can simply spoof the server or interact directly with the controller to issue commands like Unlock Door or Lockdown.

The team developed a proof-of-concept tool, which they have published on their GitHub repository. The tool demonstrates how to interact with the Net2 server to dump all stored credentials or inject new ones. If you are performing a physical security assessment, this tool is now the baseline for testing Net2 deployments.

The Danger of Hardcoded Credentials

Perhaps the most egregious finding was the presence of hardcoded credentials for the embedded SDK user account. This account, intended for third-party integrations, grants full administrative permissions over the system. Because this account is often enabled by default, any attacker with network access to the server can authenticate as the SDK user and gain complete control over the facility's access logs, user database, and door states.

This falls squarely into the OWASP A07:2021-Identification and Authentication Failures category. When hardware manufacturers bake credentials into their SDKs, they are essentially handing the keys to the kingdom to anyone who bothers to decompile their binaries.

Remote Code Execution via MSSQL

The Net2 server relies on an MSSQL backend to store its configuration and logs. The researchers found that the server exposes this database to the network, and because they had recovered the hardcoded credentials, they could authenticate as the sa account. This provided a direct path to T1059-Command and Scripting Interpreter exploitation. By enabling xp_cmdshell within the SQL server, they achieved full remote code execution on the underlying Windows host.

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
EXEC xp_cmdshell 'whoami';

This is the ultimate "game over" scenario for a physical security system. Once you have shell access on the server, you aren't just opening doors; you are controlling the entire security posture of the building.

Defensive Realities

Defending against these types of attacks requires moving away from the "set it and forget it" mentality that plagues physical security. First, isolate your access control network. These systems should never be reachable from the general corporate LAN, let alone the public internet. If you are using Net2, ensure that the SDK user account is disabled if you are not actively using it for third-party integrations.

Furthermore, audit your database configurations. If your access control server is running an MSSQL instance, ensure that the sa account is not accessible over the network and that the service account running the SQL process has the least privilege necessary. Finally, keep your firmware updated. While patching physical hardware is often a logistical nightmare, the risk of leaving these systems unpatched is no longer theoretical.

Physical security is only as strong as the software managing it. If your door controller is running on a protocol that can be decoded with a few lines of Python, you don't have a security system; you have a false sense of security. Start by scanning your internal networks for these ports and verifying that your controllers are not exposed to unauthorized segments. If you find a Net2 server, treat it with the same level of scrutiny you would apply to a domain controller. The physical world is just as hackable as the digital one, and it is time we started treating it that way.