Latest Disclosure of Camera System Vulnerability Shows Evolution in Security Manufacturer’s Relationship with Researchers
No security solution is perfect. People make mistakes. Technology goes down. And software systems can be breached.
These vulnerabilities mean it is critically important for manufacturers of security technologies to regularly test their own products and have processes in place to respond to good faith researchers who identify problems in their devices so they can be fixed, quickly.
One of those processes has been working overtime during the past few months at Axis Communications. Earlier this year, researchers at Claroty’s Team82 notified the major Swedish manufacturer of four vulnerabilities in its video surveillance products.
The company responded almost immediately, ultimately developing patches and rolling them out to customers before Team82 publicly disclosed the vulnerabilities at a presentation at the Black Hat security conference in Las Vegas, Nevada, on 6 August.
“At the end of the day, everything has vulnerabilities,” says Noam Moshe, lead vulnerability researcher at Claroty, who spoke with Security Management before his Black Hat demonstration. “The only question is how the vendor makes sure to address them.”
The Vulnerabilities
Moshe says he was particularly interested in researching Axis because its products are “heavily used in all sorts of interesting and critical places,” including government agencies, educational institutions, airports, and Fortune 500 companies. He also wanted to look at how Axis IP cameras could be used as a pivot point into an organization’s network.
Axis cameras are traditionally used at an enterprise level—meaning an organization might have dozens if not hundreds of the devices deployed. The organization will use the software Axis Device Manager to manage its camera fleet via a centralized service. It will also use the Axis Camera Station, which allows end users to see their camera feeds. Communication between these systems is done using a proprietary protocol—Axis.Remoting—developed by Axis.
During the course of a few months earlier this year, Moshe says the team discovered four vulnerabilities in Axis’ products. The most critical was a remote code execution that affected Axis’s proprietary protocol that would allow attackers to execute code on endpoints and servers that communicate with the system using that protocol.
“Controlling the server is actually pretty critical because it means that A), you are controlling the server and you have code execution on a very strong server in a company’s network, and B), you are able to control all the different cameras that are controlled by the server,” Moshe explains. “It allows attackers to pivot away into the company’s network and also to control all the different Axis cameras in that organization.”
Along with that vulnerability, Moshe says Team82 also discovered an authentication bypass to circumvent the authentication protocol Axis had in place.
“We discovered a bypass, meaning we are able to execute code on the server without needing any source of prior knowledge—meaning the only thing we need is to be able to connect to it,” Moshe adds. “We are able to execute code on the server and control all the different cameras it manages.”
Moshe documented the vulnerabilities discovered and then submitted a report to Axis through its vulnerability management process.
The Response
Axis has a team of people from software development and the software security group who review submitted vulnerabilities. They received Moshe’s report, evaluated it, and concurred that it was a significant, says Wayne Dorris, CISSP, cybersecurity program manager, Axis Communications Americas.
The company then began developing patches for the vulnerabilities and worked with Team82 to establish a date—July 11—as a public disclosure day. The patches were ready and rolling out in May and June, well before that disclosure, Dorris adds.
“We have some customers that are hyper vigilant, and as soon as there’s new software, they just go ahead and deploy,” Dorris says. “The upside was that by the time we actually did the vulnerability announcement, they may have already patched.”
For those that hadn’t already patched, the public disclosure would serve as a firm recommendation to do so quickly because Axis had rated one of the vulnerabilities as critical—a 9 on a 10-point scale of severity.
“Anything in the 9 level, as a customer, would mean I need to patch this right away,” Dorris says.
Axis gave the vulnerability this level of a Common Vulnerability Scoring System (CVSS) rating because if exploited, an attacker could start running their own code on a device and prompt it to do something it was not authorized by the client to do.
Axis alerted its customers using an internal system, an announcement on its website, and through a vulnerability report to common vulnerabilities and exposures (CVEs) databases run by the National Institute of Standards and Technology (NIST) and MITRE. Team82 had discovered more than 6,500 servers exposing the protocol affected by the vulnerability. Axis is not aware of any exploits of the vulnerabilities, and it is unclear how many customers have since installed the patches to mitigate them.
“If we look at cybersecurity as a whole, that is the greatest challenge is getting people to update software,” Dorris says. “Unfortunately, my guess is we’ve probably had less people apply the patch than should.”
Building the Process
Back in 2015, a security researcher discovered a fairly large remote code execution vulnerability in one of Axis’s endpoints. At the time, however, the company—like many others—didn’t have a formal vulnerability reporting system that outside researchers could use, Dorris recalls.
Instead, the researcher found some contact information through the company’s website to submit their report that ultimately reached the right people at Axis to address the serious vulnerability, Dorris adds.
The interaction came at a moment where Axis was already working on two major projects to improve the security of its products throughout their lifecycle: creation of the Axis Security Development Model and becoming a certified naming authority (CNA). CNAs are organizations that can assign unique CVEs to vulnerabilities and publish that information in a CVE system.
Dorris says he pushed for Axis to become a CNA because this would allow it to report documented CVEs to the National Institute of Standards and Technology (NIST) database, so end customers of their products would always have the latest information on CVEs that affect their systems—even if they no longer had a relationship with the integrator that had installed their system.
Axis also wanted to have the ability to reward researchers who submitted vulnerabilities that affected their products. It worked with Bugcrowd to first create a private bug bounty program that was focused on Axis’s OS—the software that runs the company’s endpoint devices.
Axis paid out several bounties to researchers in the first six months of the program’s launch. Bugcrowd also helped match the company with researchers that specialize in embedded devices, growing Axis’s researcher pool from 200 to well over 2,000 in a year-and-a-half, Dorris recalls.
Since then, Axis has added its camera station software and created a public bug bounty program—still run with Bugcrowd—for Axis OS. The plan is to add more product lines over time to the bug bounty program so that products are continuously under test from outside researchers, along with Axis’s regular penetration testing efforts. The outside researchers help the company maintain the security of its products, while also reinforcing regular reviews of its development process.
For instance, after Moshe’s report was submitted and patches created to address the vulnerabilities, Dorris says the team went back to review its own processes to identify where it could improve.
“More importantly for us internally was to go back and look at why didn’t the development model pick this up?” Dorris says. “Where did we miss this? When we look at research from the bug bounty program, the whole intent of that is to go back and see ‘What are we missing? Is there something in this development model that meant we didn’t catch this?’
“That’s where the learning is—to go back and say, ‘How can we change the model in this way that we don’t have to worry about these types of vulnerabilities in the future?’” Dorris adds.
Researcher Reflections
Moshe has been disclosing vulnerabilities for the past five years and says that the goal is to make sure everything is protected.
“Axis made patches in a few weeks from when we disclosed the vulnerabilities to them and they worked to make sure all their customers are protected,” Moshe adds. “It’s a great experience to work with a company that puts their security in mind, to make sure the devices are as secure as possible.”
📰 @Claroty's Noam Moshe discussed #Team82's research on Axis Communications' video surveillance products at the @DarkReading news desk today at Black Hat. ⚠️ Read the technical blog: https://t.co/cBnY2sVUEH #LifeUninterrupted #BHUSA #BlackHatUSA #BlackHat #BHUSA25 pic.twitter.com/BUvXXquQkt
— Claroty (@Claroty) August 7, 2025
For other security companies who have or are considering a vulnerability disclosure program, Moshe recommends having a dedicated section on their company website for researchers to use to report vulnerabilities directly. This section should also explain the process for reporting vulnerabilities and the expected communication timeline for a response to that report.
Many more companies are creating these programs, complete with teams to support them, which Moshe says has been a positive trend.
“At the end of the day, if you discover a vulnerability in a certain product of a certain vendor, if you have no way of getting in contact with the people in that organization that are working to make sure their devices are protected, then it’s really hard as a researcher to get the information to the company,” Moshe adds.
