Security researchers have uncovered a chain of four vulnerabilities in popular Axis Communications surveillance systems, allowing an attacker to gain complete control over the central servers that manage entire fleets of cameras. The attack, developed by Claroty’s Team82, enables pre-authentication remote code execution, meaning a malicious actor could hijack, watch, or shut down camera feeds without needing any credentials. This discovery puts thousands of organizations, including schools, government agencies, and hospitals, at risk.
The target: Understanding the Axis ecosystem
Axis Communications, a Swedish company, is a prominent manufacturer of high-end IP cameras and physical security systems. Its products are deployed in enterprises, educational institutions, and government facilities worldwide.
To manage large numbers of cameras, often spread across multiple sites, Axis provides two key pieces of Windows-based software. The Axis Device Manager (ADM) is a centralized server that allows administrators to configure and maintain camera fleets. The Axis Camera Station (ACS) acts as a network video recorder, giving end-users a single interface to view their camera feeds.
These components communicate using a proprietary protocol named Axis.Remoting, which became the entry point for the researchers’ attack (more on this in a bit).
The impact: Who is at risk and what could happen
A successful exploit grants an attacker system-level access on the server, effectively handing them the keys to the entire surveillance network. This control extends beyond simply viewing or disabling feeds. Internet-connected devices like surveillance cameras are often headless and operate without direct human oversight, making them prime targets for covert exploitation.
A compromised camera can become a silent foothold inside a network or be co-opted into a botnet for use in large-scale distributed denial-of-service (DDoS) attacks, all without the owner’s knowledge.Â
Internet scans performed by the research team found the scale of the exposure. “Claroty saw 6,500+ SERVERS exposed online,” said Noam Moshe, Vulnerability Researcher Team Lead at Claroty, in comments to TechTalks. “While this number is not small by any means, we need to remember that the purpose of the server is to manage devices, each potentially managing thousands of IP cameras.”
The exposed servers are not randomly distributed. “Most of what we saw are located in the USA (almost 4,000 out of 6,700~),” Moshe noted. These systems are concentrated in sensitive environments. “We need to remember that these servers are veered towards being used by major cooperations in sectors such as education and medical institutions. As a result, if exploited, the impact could be critical,” he added.
The protocol itself also presents a risk. During its initial handshake, Axis.Remoting leaks the server’s hostname and any associated Active Directory domain. This allows attackers to perform reconnaissance and pinpoint specific organizations for highly targeted attacks.
The fix: Patching holes and hardening networks
Following a private disclosure from Team82, Axis Communications responded quickly to develop and release fixes. The company has published an urgent advisory and, as of its publication, has no knowledge of these vulnerabilities being exploited in the wild. If you have Axis Camera systems in your organization, make sure to install the patched versions of the software, which includes Axis Camera Station Pro 6.9, Axis Camera Station 5.58, and Axis Device Manager 5.32.
While applying these patches is the critical first step, this incident also highlights best practices for securing large IoT deployments. IT administrators can significantly reduce the blast radius of future vulnerabilities through network segmentation. By isolating surveillance systems on their own dedicated network, separated by firewalls from sensitive corporate resources, a breach of the camera system can be contained.
Furthermore, the principle of least privilege should be strictly applied. The service accounts running the management software should only have the minimum permissions required to operate the camera fleet, not broad administrative rights across the network. This prevents an attacker who compromises the server from immediately gaining access to other critical systems.
Technical deep-dive: deconstructing the exploit chain
The full attack required researchers to chain together several distinct flaws. The first step was to break the Axis.Remoting protocol’s security. Although it uses TLS encryption, the protocol relies on self-signed certificates and does not properly validate them. This weakness allowed researchers to set up a Man-in-the-Middle (MiTM) position to inspect the traffic (a MiTM attack happens when a malicious actor inserts themself in the middle of the traffic between two parties without them noticing).
They found that while the protocol used NTLM for authentication, it was missing a critical security feature: message signing. This opened the door for a “pass-the-challenge” attack, where an attacker can intercept a server’s authentication challenge, forward it to a legitimate client, and then pass the client’s valid response back to the server to gain access.
Once authenticated, the next vulnerability allowed for remote code execution (RCE). The Axis.Remoting protocol sends instructions as JSON-based objects that need to be deserialized by the application server. However, the implementation of the protocol used no sanitation of type checks, which allowed attackers to craft a malicious JSON payload that instructs the server to create an object that executes code upon its creation. Team82 used the ysoserial.net tool to generate such a payload and successfully achieved RCE on both the server and the client.
This attack still required an active user to be present for the MiTM part. But the researchers managed to find an unprotected entry to achieve a pre-authentication exploit, which means the attacker can compromise the target without having any server credentials. They found it in a fallback protocol that runs over HTTP. While the main endpoint of this service was properly secured, they discovered a “hidden” endpoint prefixed with _ that was misconfigured to allow anonymous authentication. This endpoint provided a direct, unauthenticated gateway to the Axis.Remoting services, allowing an attacker to send the malicious deserialization payload without needing to intercept a legitimate user’s connection. This was the key to achieving pre-auth RCE.
With complete control over the management server, the final step was to pivot to the cameras themselves. This did not require another exploit, but rather the use of an intended feature. Axis provides a software development kit (SDK) for creating custom packages, or “plugins,” for its cameras. The researchers simply used the SDK to build a malicious package containing a backdoor. Then, using their administrative access on the compromised ADM server, they could deploy this package to the entire camera fleet, achieving code execution on every device under its management.
Key takeaways for better security
This research is a powerful case study in how multiple, seemingly isolated flaws can combine to create a critical failure. According to Noam Moshe, the root of such issues often lies in a common but dangerous assumption developers make. “Developers believe that if one part of their ecosystem is manufactured and ‘controlled’ by them, they can trust it all,” he said. “On top of this, they wrongly believe that if it’s not a user interacting with their platform, but rather something they’ve produced, then there’s no risk.”
In this case, the deserialization vulnerability arose because of this inherent trust. The developers assumed that since the client application was their own, it would never send a malicious payload. “Developers focus on the ‘happy flow’ and assume the client or device will never be malicious,” Moshe said. This is not an isolated problem; he points to similar findings in past research on Western Digital NAS devices, where the system was built on the flawed assumption that a device on the network could always be trusted.
This mindset leads to several clear lessons for developers. First, never assume an internal or “hidden” endpoint is safe; enforce authentication and authorization universally. Second, treat all input with suspicion, especially when it comes to deserialization, and use sanitation, white-listing and other techniques to make sure malicious payloads don’t pass through. Avoid permissive settings and validate any data that dictates object creation. Finally, security must be layered. As Moshe concludes, “Users should understand the exact attack surface they create when exposing a service online, and recognize that even a fully encrypted and authenticated service can still be exploited.” Encryption is not a silver bullet; it must be paired with controls like message signing to ensure data integrity.