ZoneMinder Security, What Security Engineers Need to Know About the Open Source CCTV Stack

ZoneMinder still matters because it sits at the intersection of three things defenders routinely underestimate: physical security, web application security, and infrastructure trust. It is a long-running open source video surveillance platform for Linux, built to manage IP, USB, and analog cameras through a web console and an API. That combination makes it useful, flexible, and deceptively easy to misclassify. Teams often treat it like a convenience utility for cameras. In practice, it behaves more like a business application with a web admin plane, a database, authentication logic, event processing, streaming paths, and code that can influence the host system. That is why ZoneMinder deserves to be assessed with the same seriousness you would apply to a self-hosted admin portal or an internal operations platform. (zoneminder.com)

The public record around ZoneMinder over the last few years reinforces that point. Recent disclosures are not random edge cases spread across unrelated modules. They show recurring pressure on the same broad trust boundaries: authentication, API handling, event workflows, SQL construction, log and language handling, and shell-adjacent execution paths. That pattern matters more than any single advisory title. When a product repeatedly accumulates vulnerabilities in the parts of the stack that face operators, scripts, or low-friction request parameters, defenders should stop asking whether one isolated CVE is exploitable in theory and start asking whether the whole admin surface is being treated as high-risk infrastructure. (GitHub)

That is also why the current state of the project matters. ZoneMinder’s GitHub releases page shows 1.38.1 as the latest release, and the project’s security policy says the team supports the latest stable and development releases, not old branches indefinitely. The official downloads page adds another operationally important warning: Ubuntu’s default repositories can lag behind, and the project explicitly advises users not to install ZoneMinder from outdated Ubuntu repo packages. For security teams, that is not a minor packaging note. It is one of the clearest signals in the ecosystem that “installed from distro repo” is not the same thing as “running a defensible version.” (GitHub)

What ZoneMinder actually exposes

A lot of security writeups talk about CCTV software as if the main issue were camera streams. That framing is too narrow. ZoneMinder’s official API documentation describes a RESTful API under /api that supports create, retrieve, update, delete, and other operations across monitors, events, frames, zones, config, and more. The same documentation explains that the API historically tied into session cookies and auth hashes, then evolved into a JWT-based token model with access tokens, refresh tokens, and revocation behavior. In other words, this is not just an interface for watching video. It is an administrative application surface with state, credentials, workflows, and data models that are attractive to both attackers and defenders. (zoneminder.readthedocs.io)

The authentication details in the official docs are especially revealing. ZoneMinder recommends the token-based v2 API model introduced in 1.34, requires a secret key for signing tokens, and documents that old-style auth and stateful session behavior can still exist for compatibility if legacy settings remain enabled. Its Ubuntu installation guide separately tells operators to verify that enabling OPT_AUTH causes API requests like /zm/api/host/getVersion.json to return Unauthorized until the user logs in. That is the project itself telling you the security boundary lives at the web and API plane. If those paths are reachable and authentication is not configured or enforced the way the documentation expects, you are no longer debating theoretical best practice. You are outside the vendor’s own safe operating assumptions. (zoneminder.readthedocs.io)

Once you look at ZoneMinder through that lens, the recent vulnerability history becomes easier to interpret. The problem is not that the project had “a bug.” The problem is that the same classes of trust failure keep showing up where requests meet sensitive state. That should change how you assess exposure. A single SQL injection bug in a blog CMS is serious. A SQL injection bug in a surveillance platform that stores event history, interacts with authentication, and may sit next to physical monitoring workflows is strategically different. A command injection in a toy service is bad. A command injection in an admin plane tied to camera infrastructure and alerting is a much bigger operational story. (GitHub)

The recent CVE pattern is the real story

One of the most important public findings in the ZoneMinder timeline is CVE-2023-26035. NVD describes it as an unauthenticated remote code execution issue affecting versions prior to 1.36.33 and 1.37.33. The root cause, according to the NVD description, was missing authorization checks on the snapshot action. The request flow expected an ID for an existing monitor but could instead be manipulated in a way that led to TriggerOn calling shell_exec on attacker-controlled data. NVD scores it 9.8 Critical. For defenders, the significance is not just the severity rating. It is the combination of unauthenticated reachability, authorization failure, and shell execution in a product that many teams expose more broadly than they should. (NVD)

The 2023 line did not stop there. ZoneMinder’s own GitHub advisory for the daemonControl() API issue explains that any authenticated user could construct an API command that executed shell commands as the web user, with fixes landing in 1.36.33 and 1.37.33. Around the same patch cycle, the project also published a security advisory for SQL injection in report_event_audit, שם minTime ו maxTime request parameters were not properly validated. Both disclosures reinforce the same defender lesson: a low-privilege or lightly constrained operator path in ZoneMinder may still be close enough to sensitive execution or data handling logic to matter a great deal. (GitHub)

A separate record, CVE-2023-31493, kept the RCE theme alive. NVD describes it as remote code execution through 1.36.33, where an attacker could create a new .php log file in the language folder with a crafted payload and escalate privileges to run commands on the remote system. The public scoring around that issue is less fully enriched than some other records, but the description alone is enough to make the operational point. If log handling, file placement, or localization-related code can become a route to code execution, then defenders should stop thinking about “the camera UI” and start thinking about a PHP application whose edge behavior can reach host-level impact. (NVD)

In 2024, the dominant theme shifted toward input handling flaws that still affected core admin workflows. GitHub’s official ZoneMinder advisory for CVE-2024-43360 describes a time-based SQL injection vulnerability with a CVSS v3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which is the classic profile of a remotely reachable, low-complexity issue with no privileges or user interaction required. The associated NVD record states that the issue was fixed in 1.36.34 and 1.37.61. That is not a cosmetic bug. It is the kind of flaw that makes version drift and external reachability matter immediately. (GitHub)

The same August 2024 disclosure cluster also included cross-site scripting issues. NVD records for CVE-2024-43359 describe an XSS vulnerability in the montagereview path through parameters such as displayinterval, speed, ו scale, fixed in the same 1.36.34 and 1.37.61 releases. Another advisory covered XSS in the filter view. On paper, XSS sounds less dramatic than unauthenticated RCE. In the real world, a surveillance admin interface is exactly the wrong place to dismiss it. Operators, administrators, and analysts use those views. That means successful XSS can become session theft, workflow hijacking, or privileged action abuse inside a console that often controls many cameras and stored events. (NVD)

Then came CVE-2024-51482, one of the most operationally relevant ZoneMinder flaws for current defenders because it hits the 1.37 line that many administrators still think of as “recent enough.” ZoneMinder’s official GitHub advisory states that versions 1.37.* <= 1.37.64 were vulnerable to boolean-based SQL injection in web/ajax/event.php, fixed in 1.37.65. The advisory assigns a critical profile, with low privileges required but high confidentiality, integrity, and availability impact once exploited. This is exactly the kind of issue that burns teams that patch selectively and assume “new enough” means “safe enough.” A 1.37.x deployment may still be exposed even if it has already crossed earlier 2024 fixes. (GitHub)

The 2026 records show that this pattern did not simply disappear with another point release. NVD’s CVE-2026-27470 entry describes a second-order SQL injection vulnerability in web/ajax/status.php within the getNearEvents() function. The important nuance is that values such as שם ו סיבה were safely stored first, then later retrieved and concatenated into SQL clauses without escaping. That means the risky step was not the original insert but the later reuse of trusted-looking data. The vulnerable range is especially revealing: versions up to 1.36.37 and versions 1.37.61 through 1.38.0 were affected, with fixes in 1.36.38 and 1.38.1. That is a direct reminder that newer branches can inherit different flaws even after earlier branches receive fixes for previous issues. (NVD)

The other 2026 record that should change how people talk about ZoneMinder risk is CVE-2025-65791, published in February 2026 and tied to command injection in web/views/image.php. NVD and the GitHub advisory database both describe the vulnerable behavior the same way: unsanitized user input passed directly to exec(). The GitHub advisory database marks it critical with a 9.8 score. Even where patch metadata is less complete than defenders might like, the security lesson is clear enough on its own. Any route from web request data to exec() inside an administrative surveillance application should be treated as emergency-tier exposure until proven otherwise. (NVD)

Why version numbers tell a more honest story than marketing labels

ZoneMinder’s own security policy says the project supports the latest stable and development releases and does not support “ancient” versions. That policy matters because the public vulnerability record shows that 1.36, 1.37, and 1.38 do not map neatly to “old,” “current,” and “safe.” Instead, they represent overlapping lines with different fix points. One branch may have closed one SQL injection while still remaining vulnerable to a later issue that was disclosed against a different endpoint or event-handling path. The result is a version landscape where lazy phrasing such as “we’re on the 1.37 branch” is operationally meaningless. (GitHub)

A simple way to think about the public record is this. Versions before 1.36.33 and 1.37.33 were exposed to several 2023 issues, including unauthenticated RCE and authenticated command injection. Versions before 1.36.34 and before 1.37.61 remained vulnerable to the August 2024 SQLi and XSS set. Versions through 1.37.64 were still affected by CVE-2024-51482 until 1.37.65. And even after 1.37.61, the second-order SQL injection tracked as CVE-2026-27470 reached through 1.38.0, with 1.38.1 carrying the relevant fix. If you do not know your exact build, branch, and patch point, you do not know your ZoneMinder security posture. (NVD)

That is also why the official downloads guidance matters so much in practice. The project’s site warns that default Ubuntu repo packages can be out of date and recommends checking releases or using the maintained PPA. Security teams sometimes dismiss repo lag as a DevOps convenience problem. In self-hosted surveillance stacks, it is a risk multiplication mechanism. A lagging package source creates the exact condition attackers want: an environment that appears maintained because it still receives system updates, but continues running a vulnerable application branch because the security-critical application package is behind the project’s release cadence. (zoneminder.com)

The biggest risk is usually exposure plus misclassification

Most severe ZoneMinder incidents will not happen because an attacker spent weeks studying CCTV software in isolation. They will happen because defenders misclassified the application. A surprising number of organizations expose management surfaces more broadly than they realize, either directly on the public internet, indirectly through permissive VPN access, or internally on flat networks where too many users, contractors, or devices can reach them. If the application is then underpatched, using legacy auth settings, or missing strong reverse proxy controls, a published ZoneMinder CVE becomes a very short story. (zoneminder.readthedocs.io)

The official Ubuntu installation hints are revealing here in a small but important way. The documentation says that after enabling OPT_AUTH, an unauthenticated request to http://localhost/zm/api/host/getVersion.json should return Unauthorized, and only after logging in through the same browser should that request return version data. That example is mundane, but it encodes a security truth. ZoneMinder assumes that authentication gates the API. If your environment returns useful responses where the official guide expects rejection, then your environment has already drifted away from the documented security model. (zoneminder.readthedocs.io)

The API docs add a second warning sign: the platform still contains compatibility pathways for legacy auth and stateful sessions. The docs explain that legacy credentials may still be returned if OPT_USE_LEGACY_API_AUTH is enabled, and that cookies can also be used even though that is “not recommended as a general approach.” Backward compatibility is understandable. Operationally, though, it means defenders need to distinguish between what ZoneMinder can support and what they should actually keep enabled in production. The right security question is not “does it still work with older auth modes?” The right question is “why is older auth mode still enabled on a system that stores security video and administrative state?” (zoneminder.readthedocs.io)

A hardening model that fits the product

The first hardening rule for ZoneMinder is simple: upgrade by security reality, not by branch familiarity. Today, that means treating 1.38.1 as the clearest baseline because it is the current latest release and also the patched target referenced by the 2026 second-order SQL injection record for affected 1.37.61 through 1.38.0 deployments. If you remain on 1.37.x for operational reasons, 1.37.65 is the important minimum for CVE-2024-51482, but that should be treated as a branch-specific containment answer, not a long-term comfort zone. (GitHub)

The second rule is to treat authentication as mandatory infrastructure, not optional convenience. The official install guide explicitly says to enable OPT_AUTH, and the API documentation recommends the v2 token-based model introduced in 1.34, backed by a properly populated AUTH_HASH_SECRET. Those recommendations line up with the vulnerability history. A platform with repeated issues around API and request processing should never be left in a mode where broad anonymous reachability is tolerated just because the server sits behind a private IP. Internal-only is not a security control. It is a routing description. (zoneminder.readthedocs.io)

The third rule is to narrow network reach aggressively. Cameras, ZoneMinder servers, databases, and operator workstations should not all live on the same flat trust plane. Community guidance from the ZoneMinder forum includes operators discussing segmented PoE camera networks and firewall rules that constrain camera communication paths, which mirrors long-standing defensive best practice for surveillance environments. Even if the forum post is not normative documentation, the architecture it describes is sound: cameras should live on a restricted segment, the ZoneMinder host should mediate that traffic, and the admin interface should be separately controlled rather than inheriting the camera network’s reachability by accident. (forums.zoneminder.com)

The fourth rule is to reduce database blast radius. ZoneMinder’s own install guide shows the application using a dedicated database and user, but the broader security point is least privilege. If an attacker lands an SQL injection, the difference between an app-scoped database account and an overpowered database identity is the difference between incident response and catastrophe. SQL injection in a surveillance application is never “just data disclosure.” It can mean user records, event metadata, tags, administrative logic, and potentially follow-on abuse if credentials or secrets are stored carelessly or reused elsewhere. (zoneminder.readthedocs.io)

The fifth rule is to front ZoneMinder with a hardened access layer. The project’s installation guide covers Apache configuration because the application depends on it, but production security requires more than “Apache is running.” A reverse proxy or gateway in front of /zm/ ו /zm/api/ should enforce TLS, origin restrictions, MFA or SSO where feasible, IP allowlisting for admin traffic, and high-quality request logging. This does not replace patching. It reduces the chance that a newly disclosed flaw becomes immediately reachable from an attacker’s preferred network path. (zoneminder.readthedocs.io)

The sixth rule is to stop treating event and audit workflows as benign. Several public advisories target event.php, status.php, report_event_audit, and other event-adjacent or reporting paths. That means security reviews should focus less on glamorous camera streaming features and more on the boring operator functions that accept timestamps, tag IDs, event names, cause strings, filters, and sorting inputs. In many self-hosted systems, the attack surface lives in the clerical parts of the application, not the headline feature. ZoneMinder’s public record fits that pattern unusually well. (GitHub)

A safe validation workflow for defenders

Because ZoneMinder has a meaningful vulnerability history, defenders should verify posture without reproducing exploit chains unless they have an authorized test program and a clear operational need. The good news is that much of the most important validation is boring and low-risk.

Start by identifying the exact running version through the UI, package manager, or deployment metadata. That sounds obvious, but many incidents begin with teams arguing over branch names instead of build numbers. Then verify that unauthenticated access to the admin and API paths behaves the way the official documentation says it should. A request for version data or other API metadata should not return useful information without a valid session or token if OPT_AUTH is properly enforced. (zoneminder.readthedocs.io)

A simple validation pattern looks like this:

# Check whether the admin plane is reachable
curl -I <https://your-zoneminder.example/zm/>
curl -I <https://your-zoneminder.example/zm/index.php>

# Check whether the API exposes version data without authentication
curl -s -i <https://your-zoneminder.example/zm/api/host/getVersion.json>

# Check installed package version on the host
dpkg -l | grep zoneminder || rpm -qa | grep -i zoneminder

These commands do not test exploitation. They test reachability, authentication behavior, and version awareness. That is where most organizations should begin. The official docs themselves use the getVersion.json behavior as a security check, so using that pattern for authorized self-assessment is aligned with the project’s own guidance. (zoneminder.readthedocs.io)

Once basic reachability is clear, verify whether legacy API auth remains enabled. The ZoneMinder API documentation explains that legacy and token credentials may both be returned when OPT_USE_LEGACY_API_AUTH is on. For many environments, that setting exists for compatibility with older clients. Security teams should inventory which integrations still rely on it and remove it when no longer necessary. Backward compatibility should be an exception with a retirement plan, not a permanent state. (zoneminder.readthedocs.io)

Then review internet exposure. This includes public DNS, reverse proxy rules, VPN-accessible admin paths, jump hosts, and cloud firewall policies. A surprising number of “internal” tools are functionally internet-adjacent because contractors, vendors, or remote staff can reach them from broadly trusted edges. For ZoneMinder, that matters more than usual because the public vulnerability record includes both unauthenticated and low-privilege attack paths. If a platform with that history is reachable from too many places, the exposure story is already bad before you test a single parameter. (NVD)

Finally, after patching, validate behavior again rather than assuming package upgrade success equals practical remediation. Public disclosures across 2023, 2024, and 2026 make one thing clear: ZoneMinder has had multiple fix milestones spread across branches. The only trustworthy posture is “we know which version is running, we know who can reach it, we know authentication is enforced, and we know the legacy pathways we still depend on.” Anything softer than that is just optimism with a camera attached to it. (GitHub)

Where modern validation platforms fit naturally

For teams managing many self-hosted applications, the hard part is rarely reading a CVE description. The hard part is turning that description into repeatable exposure checks across real environments. ZoneMinder is a good example because the risk is not confined to one parameter or one exploit class. You need to know which instances exist, which versions they run, which admin paths are exposed, whether authentication actually blocks unauthenticated access, whether older API modes remain enabled, and whether the patch you think you deployed is the patch the system is really serving. Those are validation problems, not just vulnerability intelligence problems. (zoneminder.readthedocs.io)

That is the narrow, natural place for a platform like Penligent. Not as a magic answer to ZoneMinder itself, and not as a substitute for upgrading or segmenting the environment, but as a way to automate the parts defenders routinely skip: verifying management-plane exposure, checking authentication behavior, inspecting reachable endpoints, correlating version evidence, and retesting after fixes. In environments where self-hosted operational tools keep appearing faster than security teams can manually review them, that kind of AI-assisted verification is often more valuable than another static writeup. (Penligent)

A practical defender view of the risk

If you have to explain ZoneMinder risk to a security lead in one paragraph, say this. ZoneMinder is a legitimate and actively maintained open source surveillance platform, but it should be treated as a high-risk admin application, not as a passive camera viewer. Official documentation shows a meaningful API and authentication model. Official advisories and NVD entries show repeated issues involving missing authorization, SQL injection, XSS, and command execution paths across the admin plane and event workflows. The project’s own security policy emphasizes current supported versions, and its downloads guidance warns against stale packages. That combination tells a very clear story: the main threat is not “open source cameras are unsafe.” The main threat is that organizations deploy ZoneMinder like a utility while attackers approach it like an application server. (zoneminder.com)

For pentesters and red-teamers working under authorization, ZoneMinder should sit in the same review bucket as self-hosted IT portals, internal dashboards, and lightweight operations tools. Enumerate reachability first. Confirm authentication behavior second. Map exact version and branch third. Only then decide whether deeper testing is warranted. The public record says enough already: when a product repeatedly accumulates serious bugs in admin and API paths, exposure assessment becomes just as important as exploitability analysis. (zoneminder.readthedocs.io)

For defenders, the lesson is even simpler. Do not let the word “camera” fool you into lowering your standards. ZoneMinder stores sensitive operational data, brokers access to physical monitoring workflows, exposes an administrative web surface, and has a documented history of vulnerabilities that matter. If it is installed, it needs patch discipline. If it is reachable, it needs strict access control. If it is business-critical, it needs validation after every meaningful change. (zoneminder.com)

Version and CVE quick reference

Safe operational checklist

# 1. Identify version
dpkg -l | grep zoneminder || rpm -qa | grep -i zoneminder

# 2. Check whether unauthenticated API access is blocked
curl -s -i <https://your-zm.example/zm/api/host/getVersion.json>

# 3. Check whether the admin plane is externally reachable
curl -I <https://your-zm.example/zm/>
curl -I <https://your-zm.example/zm/index.php>

# 4. Review reverse-proxy and access rules
# Confirm that only approved networks or identities can reach /zm/ and /zm/api/

# 5. Review API auth mode in ZoneMinder settings
# Prefer token-based auth and retire legacy auth where possible

This checklist stays on the safe side of authorized validation. It does not reproduce exploits. It verifies the conditions that most often determine whether published vulnerabilities are likely to matter in your environment. That is usually the highest-value first move. (zoneminder.readthedocs.io)

Final thought

ZoneMinder is not dangerous because it is open source. It is dangerous when organizations forget what it really is. It is a web application with a camera mission, a database core, administrative workflows, and a documented history of serious flaws in the same places attackers naturally look first. Run it like infrastructure. Patch it like a business-critical service. Gate it like an admin console. Validate it like an exposed application, not like a “utility box” that just happens to display video. That is the conclusion the official documentation, official advisories, and current public vulnerability record all point toward. (zoneminder.com)

References and further reading

• ZoneMinder Home (zoneminder.com)
• ZoneMinder API Documentation (zoneminder.readthedocs.io)
• ZoneMinder Ubuntu Installation Guide (zoneminder.readthedocs.io)
• ZoneMinder Releases on GitHub (GitHub)
• ZoneMinder Security Overview and Advisories (GitHub)
• NVD, CVE-2023-26035 (NVD)
• ZoneMinder Advisory, daemonControl API command injection (GitHub)
• ZoneMinder Advisory, report_event_audit SQL injection (GitHub)
• NVD, CVE-2024-43359 (NVD)
• ZoneMinder Advisory, CVE-2024-43360 (GitHub)
• ZoneMinder Advisory, CVE-2024-51482 (GitHub)
• NVD, CVE-2026-27470 (NVD)
• NVD, CVE-2025-65791 (NVD)
• ZoneMinder v1.37.63 CVE — The Vulnerability Security Teams Are Actually Looking For (Penligent)
• Application Programming Interface Testing, A Comprehensive Guide to Functionality and Security (Penligent)