ZoneMinder, the Open-Source CCTV Stack That Deserves a Real Security Review

For years, ZoneMinder has occupied an unusual place in the security ecosystem. It is often introduced as “open-source CCTV software,” which sounds almost quaint, as if it belongs to the same category as a webcam utility or a home lab side project. That framing undersells what it really is. ZoneMinder is a web-facing Linux application stack that captures, analyzes, records, indexes, and serves surveillance data across cameras, users, events, permissions, APIs, and storage backends. The official project describes it as an integrated surveillance solution for capture, analysis, recording, and monitoring of CCTV or security cameras, with support that spans analog and IP cameras, web access, mobile access, on-premises data control, and deployments ranging from small systems to multi-server environments. (zoneminder.com)

That combination is exactly why ZoneMinder still matters. People choose it because it is self-hosted, flexible, and not tied to a proprietary camera vendor. The project’s own feature pages emphasize that users can avoid camera lock-in, keep data on premises, access the system remotely through a web interface and mobile apps, and scale up from small installations to larger deployments. Even third-party users who are not particularly sentimental about the platform still tend to describe the same tradeoff: ZoneMinder remains capable and feature-complete, but it takes effort to deploy and operate well. Noah Bailey’s self-hosted writeup, for example, bluntly calls it “still by far the most capable and complete solution” for his use case while also noting that it is difficult to install and manage. That assessment is useful because it explains why ZoneMinder persists. It gives operators control that consumer cloud-camera ecosystems do not, but it also hands them the burden of owning security decisions those ecosystems often hide. (zoneminder.com)

Security engineers should care because ZoneMinder does not just process video. It exposes a management plane. It stores event metadata. It offers APIs. It mediates authentication. It supports PTZ control. It handles live streams and recorded playback. It can be reached through reverse proxies, mobile apps, and remote access patterns that administrators often configure under time pressure. Once you treat it as a real application rather than “camera software,” its risk profile becomes easier to understand. A compromise is no longer just about watching a feed. It can mean unauthorized access to surveillance records, manipulation of security events, theft of credentials or tokens, movement into the underlying Linux host, and, depending on network design, a pivot toward the cameras and adjacent operational systems themselves. (ZoneMinder Documentation)

What ZoneMinder really looks like in practice

The safest way to think about ZoneMinder is as a small surveillance platform made of several security-relevant layers. The first is the web UI, which administrators and operators use for configuration, event review, monitor management, storage decisions, and system-level settings. The second is the API layer, which the official documentation describes as a RESTful interface supporting CRUD operations for monitors, events, frames, zones, and configuration. The third is the authentication layer, which in older generations leaned on legacy auth mechanisms and, beginning with 1.34, added a token-based JWT-oriented model with access tokens, refresh tokens, and API revocation controls. The fourth is the monitor and event pipeline itself, where camera inputs, event generation, stream handling, storage, and later retrieval meet. The fifth is the host and network environment around it: web server, database, shared memory, filesystem, storage mounts, time synchronization, TLS termination, and the cameras or control systems it talks to. (ZoneMinder Documentation)

The official documentation is surprisingly candid about several security-sensitive realities. It recommends enabling authentication immediately. It documents that the default initial username is 管理者 and the default password is 管理者. It explains that users can be granted different levels of access across streams, events, PTZ control, monitors, groups, system settings, bandwidth, and API access. It also documents that there are multiple ways to pass authentication in requests, including JWT-based tokens and, less safely, credentials in URLs, while explicitly warning that usernames and passwords in URLs are not recommended because they can end up in server logs even when HTTPS is used. Those are not small details. They tell you, directly from the project’s own documentation, where operators make their first security decisions and where common mistakes tend to begin. (ZoneMinder Documentation)

The platform is also changing in ways that matter. As of March 2026, the official GitHub release page shows 1.38.1 as the latest release and 1.36.38 as a maintained 1.36 branch release. The 1.38 line adds more modern access-control and streaming features, including role-based access control, normalized permission tables, WebRTC-related support, protocol enhancements, and a redesign of the monitor function model for finer-grained control. That is a material architectural step forward because the older mental model of “one admin, one shared dashboard, one exposed web panel” is not enough anymore. The newer releases show the project acknowledging that deployments now need better permission boundaries and more modern protocol handling. At the same time, the installation docs warn that distribution packages can lag behind the latest release, which means many real-world ZoneMinder installations may remain on vulnerable or simply stale builds longer than administrators realize. (ギットハブ)

That package lag matters more than it would for a toy app. ZoneMinder often sits on systems that run for years, store large volumes of data, and are changed reluctantly because camera downtime is operationally painful. Surveillance stacks are notorious for becoming “set and forget” infrastructure. In practice, that means older branches, mixed upgrade states, customized reverse proxies, reused credentials, stale API clients, and unreviewed internet exposure. When a project with that deployment profile accumulates a history of SQL injection, RCE, auth flaws, and XSS, defenders have to assume that patching alone is not enough. They need evidence that their specific deployment really moved out of the vulnerable state. (寡黙)

The vulnerability history is not noise

ZoneMinder’s vulnerability history is broad enough that it should shape how the product is deployed, not just how it is patched. The most important recent lesson is not that one dramatic bug existed. It is that multiple classes of bugs have existed across auth, API, database query handling, event retrieval, and web UI surfaces. That is the signature of an application that needs disciplined exposure control and repeated validation. (NVD)

The most security-significant ZoneMinder issues from the last few years tell a coherent story. In February 2023, CVE-2023-26035 described an unauthenticated remote code execution flaw tied to missing authorization in the snapshot action. According to NVD and the project’s own advisory, the issue affected versions before 1.36.33 and 1.37.33, and the fix required both validation of Monitor ID and authentication before processing actions. The GitHub advisory rates it critical and notes patches that add those protections. This is a foundational warning sign because it is not merely a sanitization bug. It is a broken trust-boundary problem. When a snapshot-related path can become command execution without proper authorization checks, you are looking at management-plane logic that was too reachable for what it could do. (NVD)

The same February 2023 cluster also included CVE-2023-26032, where NVD describes SQL injection via a malicious JWT token in versions before 1.36.33 and 1.37.33. The summary is especially instructive: the Username field of the JWT token was trusted during an SQL query to load the user, meaning that if an attacker could determine the hash key, they could generate a malicious token and execute arbitrary SQL. Around the same time, CVE-2023-26039 documented OS command injection via daemonControl() in the API, allowing any authenticated user to construct an API command to execute shell commands as the web user. Read together, these flaws point to a recurring theme in older ZoneMinder code paths: trust attached too early to fields or actions that sat close to privileged operations. (NVD)

There were also multiple 2023 query-handling flaws beyond those headliners. GitHub’s GHSA-222j-wh8m-xjrx describes a blind SQL injection vulnerability in the filter[Query][terms][0][attr] parameter of /zm/index.php, affecting up to 1.36.32 and pre-1.37.33 builds. NVD additionally records CVE-2023-26037, where minTime そして maxTime request parameters were not properly validated and could be used to execute arbitrary SQL, and CVE-2023-26038, a local file inclusion issue via web/ajax/modal.php. The point is not to dump identifiers into a paragraph. It is to show pattern density. By early 2023, defenders already had enough evidence to treat ZoneMinder as a product that needed sustained scrutiny at the edges where UI parameters, tokens, API requests, and backend execution meet. (ギットハブ)

The 2024 record reinforced the same conclusion. In August 2024, NVD published CVE-2024-43360, a time-based SQL injection issue fixed in 1.36.34 and 1.37.61, and CVE-2024-43358 plus CVE-2024-43359, XSS issues affecting the filter view and montage review paths, also fixed in 1.36.34 and 1.37.61. GitHub’s advisory GHSA-9cmr-7437-v9fj states that the SQL injection impact could be severe enough to damage data and dump likely databases, and the 1.36.34 release notes show corresponding hardening, including restrictions on parameters and explicit fixes for the related advisories. That combination matters because it links the public advisory trail directly to the code and release cadence administrators must follow. (NVD)

Then came CVE-2024-51482, the ZoneMinder issue that many security teams now use as the shorthand reference for why older 1.37 systems should not be left alone. NVD and the project’s advisory both describe a boolean-based SQL injection in web/ajax/event.php affecting 1.37 builds up to 1.37.64, with the patch landing in 1.37.65. The GitHub advisory marks it critical. That matters for two reasons. First, the vulnerable path sits in an event-related web endpoint rather than an obscure plugin edge case, which means it overlaps with a normal operational surface. Second, the affected range is recent enough that many systems upgraded “within the branch” could still remain exposed if they stopped just short of the fixing release. For any team auditing older 1.37 deployments, this is one of the first version checks that should happen. (NVD)

The 2026 disclosures add another wrinkle: not every new CVE should be repeated uncritically. GitHub’s February 2026 advisory GHSA-r6gm-478g-f2c4, mirrored by NVD as CVE-2026-27470, describes a second-order SQL injection in getNearEvents() where event fields such as 名称 そして 原因 are stored safely at first but later concatenated into SQL clauses without escaping. That is the kind of bug that defenders sometimes overlook because first-order input validation appears correct. The release notes for 1.36.38 explicitly mention fixing this secondary-order issue, which is useful confirmation that the project addressed it in code. (ギットハブ)

By contrast, CVE-2025-65791 should be handled carefully. NVD currently marks it as disputed, noting that the supplier disputes the claim because there is “no unsanitized user input” to the cited image.php path. That does not prove the report is harmless, but it does mean responsible writing should not present it as settled fact. In a mature security program, disputed issues belong in a watchlist or verification queue, not in the same bucket as confirmed, patched flaws with maintainer acknowledgments and versioned fixes. That distinction matters because credibility matters. Security articles lose value when they collapse confirmed advisories and unresolved claims into a single blob of fear. (NVD)

What the bug history says about the real attack surface

If you zoom out from the CVE list, four risk themes stand out.

The first is parameter handling in web endpoints and event-related views. SQL injection and XSS issues in filters, event pages, watch paths, montage review, and status-related logic tell you that the browser-facing layer is not just a passive dashboard. It is a command surface that interacts with the database, rendering logic, and sometimes lower-level operations. When administrators expose ZoneMinder broadly for convenience, they are not only publishing a camera viewer. They are publishing a management application with a long history of mistakes in the places attackers test first. (NVD)

The second is authorization and privilege transitions. CVE-2023-26035 is the clearest example, but it is not the only clue. The official documentation spends a lot of time on permissions because ZoneMinder users are not all meant to be equal. Streams, events, PTZ control, monitor management, groups, system settings, bandwidth, and API use all have separate permission models. That is a strength, but it also means administrators have more ways to accidentally overgrant. The move to RBAC in 1.38.x is important because it reflects a project-level recognition that permissions must be normalized and easier to reason about. A legacy deployment with coarse privileges, old habits, and reused accounts is a fundamentally different security proposition from a modernized deployment with role separation and restricted monitor access. (ZoneMinder Documentation)

The third is API token hygiene. ZoneMinder’s API documentation shows a clear evolution from older session and auth-hash approaches toward JWT-based access and refresh tokens in 1.34 and later. The docs explicitly say the older MD5-based auth-hash approach is not secure or recommended, and they emphasize short-lived access tokens, refresh discipline, HTTPS usage, and token revocation. They also warn against transmitting usernames and passwords in URLs because credentials can show up in logs. That matters operationally because camera ecosystems often attract quick integrations, mobile clients, and copy-pasted scripts. The insecure pattern is obvious: somebody enables remote access, gets a stream working with user= そして pass= in the URL, ships it, and forgets the logs. That is the kind of local convenience that becomes a durable secret-handling problem. (ZoneMinder Documentation)

The fourth is the hidden blast radius of a “camera app.” ZoneMinder often sits at the edge of multiple trust zones: user browsers, mobile apps, reverse proxies, internal databases, storage mounts, and often cameras that themselves are weakly managed devices. The ZoneMinder feature pages advertise remote access from any internet-accessible device and freedom from proprietary camera lock-in. Both are attractive. Both also enlarge the boundary defenders must secure. If the NVR is exposed, or if the cameras are on a flat network, the surveillance stack stops being isolated. It becomes a foothold with sightlines into both physical monitoring and network topology. (zoneminder.com)

Why people still deploy it anyway

The right security conclusion is not “never use ZoneMinder.” The right conclusion is that ZoneMinder still solves a problem that many teams and operators genuinely have. Cloud-first consumer cameras are often expensive, proprietary, and invasive. Some users want to keep footage local. Others need a system that can mix camera types, sit on their own storage, integrate into Linux-heavy environments, or scale without a vendor tax. The official project messaging leans heavily on those exact points: camera flexibility, data control, web access, on-premises operation, and scalability. Third-party coverage aimed at NAS and homelab users highlights the same appeal, usually with a side note that the installation and tuning experience can be rough. That is why the conversation around ZoneMinder remains alive even as newer NVR stacks compete for mindshare. It is not still around by accident. (zoneminder.com)

For security teams, that means one practical thing: ZoneMinder will keep showing up. It may appear in small-business back offices, school facilities, warehouses, homes with “prosumer” setups, regional offices, and labs where someone wanted to escape proprietary cloud cameras. You should expect to encounter it in legacy conditions, mixed-version conditions, and internet-exposed conditions. The question is not whether the software is trendy. The question is whether it is installed, reachable, and still tied to physical or operational monitoring. If yes, it deserves review. (zoneminder.com)

A practical threat model for ZoneMinder

A useful threat model starts with three attacker goals.

One goal is unauthorized visibility: watching live streams, browsing stored events, or harvesting surveillance history. That objective aligns with weak auth, exposed dashboards, stolen API tokens, and SQL injection paths that can disclose data. Another goal is control: manipulating event handling, tampering with monitor states, abusing PTZ, changing settings, or causing denial-of-service through logs, storage consumption, or unstable queries. GitHub’s 2022 advisory GHSA-cfcx-v52x-jh74, for example, describes a log-based DoS path where users with view permissions could inject data into logs without rate control and degrade database performance or consume storage. The third goal is code execution or pivoting through the server. Confirmed command injection and missing-authorization RCE findings in the 2023 period show that this is not theoretical. Once the ZoneMinder host is owned, camera credentials, storage locations, network paths, and adjacent systems become part of the fallout. (ギットハブ)

A strong deployment assumes all three goals are plausible and designs around them. That means separating who can view versus who can administer. It means isolating cameras from the broader enterprise LAN. It means treating the web UI and API as privileged surfaces that should sit behind reverse proxies, authentication, IP controls, and preferably VPN or private access patterns. It means tracking the exact branch and patch level because ZoneMinder fixes are often version-specific. And it means checking whether convenience shortcuts crept in over time, especially around credentials in URLs, shared admin accounts, old mobile app behaviors, or direct internet exposure. (ZoneMinder Documentation)

What a hardened ZoneMinder deployment should look like

The most important security control is not a regex or a WAF rule. It is exposure discipline. A ZoneMinder server should not be casually published to the public internet just because the feature page says it can be reached from any internet-accessible device. “Can” is not the same thing as “should.” A modern deployment should prefer VPN access, private reverse proxying, zero-trust access brokering, or at minimum strict source-IP restrictions in front of the web UI and API. Publicly reachable login pages for systems with documented histories of auth, SQLi, and XSS issues are not a reasonable default. (zoneminder.com)

The next control is authentication hygiene, and the official docs hand defenders an easy checklist. Enable authentication immediately. Change the default admin/admin credentials immediately. Create a separate fully privileged user before removing or sidelining the default admin role. Use the permission model deliberately rather than leaving broad rights on every account. Restrict monitor access where possible. Only enable API access for users that actually need it. Those are ordinary controls, but they matter more in ZoneMinder because the UI and API expose so much operational capability. (ZoneMinder Documentation)

TLS is non-negotiable. ZoneMinder’s own API documentation explicitly says to use HTTPS, not HTTP, and even recommends Let’s Encrypt over self-signed certificates where possible. This is not just about browser padlocks. Tokens, session material, operator behavior, and mobile integrations all get safer when transport is strong and predictable. If you terminate TLS at a reverse proxy, make sure logs and upstream headers do not reintroduce secrets through debugging shortcuts or verbose request recording. (ZoneMinder Documentation)

Then comes version discipline. If you are running an old 1.37 deployment, you should know whether it is earlier than 1.37.65 because of CVE-2024-51482. If you are on an older 1.36 build, you should know whether it is earlier than 1.36.33 or 1.36.34 because that range intersects multiple serious 2023 and 2024 fixes. If you want the newest access-control and modernization work, you should understand what 1.38.1 brings and how its RBAC model changes operational practice. The docs also caution that distro repositories can lag behind releases, so “installed from the package manager” is not proof that you are on the right side of a fix. (ギットハブ)

Storage and shared memory deserve explicit monitoring too. ZoneMinder’s FAQ discusses mapped memory usage and warns that high Use% may require increasing the tmpfs allocation. That may sound like a performance note, but it is also a resilience issue. Surveillance systems fail badly when storage fills, tmpfs is undersized, or event retention behavior becomes unpredictable. Attackers do not always need a clean exploit chain if weakly rate-limited logs, event storms, or oversized requests can degrade an already fragile deployment. Good security in this context includes making the system boring under pressure. (ZoneMinder Documentation)

Example hardening patterns

A reverse proxy that enforces TLS and keeps the raw ZoneMinder service off the public edge is a good baseline. A minimal Nginx pattern might look like this:

server {
    listen 443 ssl http2;
    server_name zm.example.internal;

    ssl_certificate     /etc/letsencrypt/live/zm.example.internal/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/zm.example.internal/privkey.pem;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "no-referrer" always;

    location / {
        proxy_pass <http://127.0.0.1:8080>;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 300;
    }
}

This does not “fix” a vulnerable ZoneMinder version, but it reduces casual exposure, enforces transport security, and gives you a clean place to add upstream auth, IP allowlists, or VPN-only reachability. That aligns with the project’s own HTTPS guidance for API use. (ZoneMinder Documentation)

At the host firewall layer, the principle should be even simpler: only trusted administration networks should ever reach the web tier directly.

# Example with UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH only from management subnet
sudo ufw allow from 10.10.0.0/24 to any port 22 proto tcp

# Allow HTTPS only from VPN or reverse proxy subnet
sudo ufw allow from 10.20.0.0/24 to any port 443 proto tcp

# Deny direct HTTP from everywhere
sudo ufw deny 80/tcp

sudo ufw enable
sudo ufw status verbose

ZoneMinder is often deployed by people who are understandably focused on getting camera streams working. The firewall is where you enforce the opposite mindset: nobody reaches the UI because “it was easier that way.” (zoneminder.com)

For API consumers, the safest pattern is to use access tokens and refresh them correctly instead of passing usernames and passwords in URLs. The project documentation is explicit that credentials in URLs are not recommended and that access tokens should be used for normal API requests while refresh tokens are only used to obtain new access tokens. (ZoneMinder Documentation)

# Obtain tokens
curl -s -X POST "<https://zm.example.internal/zm/api/host/login.json>" \\
  -d "user=apiuser&pass=REDACTED"

# Use access token for subsequent requests
curl -s "<https://zm.example.internal/zm/api/monitors.json?token=ACCESS_TOKEN>"

# Refresh with refresh token before expiry
curl -s -X POST "<https://zm.example.internal/zm/api/host/login.json>" \\
  -d "token=REFRESH_TOKEN"

That is not just API neatness. It limits password reuse over the wire, makes revocation practical, and aligns your automation with the platform’s intended security model. (ZoneMinder Documentation)

A simple fail2ban layer in front of the reverse proxy or auth endpoint is also reasonable when remote access is unavoidable:

# /etc/fail2ban/jail.d/zoneminder-auth.local

enabled = true port = https filter = zoneminder-auth logpath = /var/log/nginx/access.log maxretry = 5 findtime = 10m bantime = 1h

The exact regex filter depends on your proxy and auth flow, but the principle is universal: management surfaces should not allow endless anonymous password spraying. It is notable that the 1.36.34 release notes mention fail2ban.rules updates, which at least signals that the maintainers view login abuse resistance as part of operational hardening rather than an afterthought. (ギットハブ)

How to read ZoneMinder findings during an assessment

During a real assessment, one of the easiest mistakes is to overfocus on exploitability and underfocus on deployment state. For example, a SQL injection advisory matters differently depending on whether the UI is public, whether auth is enabled, whether API users are overprivileged, and whether the server sits behind a proxy with IP restrictions. A vulnerable version with no internet exposure and strict administrative access is still a problem, but a different one from a public dashboard with default credentials. The findings need context, but not excuses. (ZoneMinder Documentation)

The second mistake is to assume a single fixed CVE “solves” the environment. A team that patched CVE-2024-51482 on 1.37.x may still have poor token hygiene, overly broad user privileges, weak reverse-proxy settings, exposed camera networks, or a stale mobile client workflow that still leaks secrets to logs. ZoneMinder security is not only a version problem. It is a posture problem with versioning as one important part. (ギットハブ)

The third mistake is trusting claims that are not yet settled. As the disputed status on CVE-2025-65791 shows, defenders should track new claims without flattening them into confirmed reality. For engineering teams, that means triage and reproduction standards matter. For writers, it means separating confirmed history from unresolved allegations. For operators, it means the safest habit is simple: if the claim overlaps your version and exposure model, test your environment; if it is disputed, keep the label visible until you know more. (NVD)

ZoneMinder is one of those products that makes an uncomfortable amount of sense for automated validation. Not because an automated platform replaces patching or architecture changes, but because surveillance stacks are notoriously easy to “half-fix.” A team upgrades the package, forgets the reverse proxy rule, leaves a legacy API client in place, or never retests the web surface that mattered most in the advisory. The natural role for an AI-assisted validation workflow is not to dramatize exploitation. It is to close the gap between “we think it is fixed” and “we have evidence that exposure, auth behavior, reachable endpoints, and version indicators now line up with the safer state.” That is exactly the narrow problem space where a platform like Penligent can be useful. (寡黙)

For a ZoneMinder environment, that kind of workflow is most valuable in four moments: before internet exposure, after an upgrade, after reverse-proxy or auth changes, and during recurring posture reviews. The platform value is not mystical. It is operational. It helps teams verify management-plane exposure, inspect auth behavior, correlate visible version evidence, test whether sensitive paths are still reachable, and retest after changes without relying on memory or one-off shell history. In environments where surveillance is business-critical, that repeatability matters more than one flashy finding. (寡黙)

The bottom line

ZoneMinder is not obsolete just because it is old, and it is not insecure just because it is open source. It remains relevant because it gives operators a rare combination of camera flexibility, local data ownership, and deployment control. The problem is that those same strengths move security responsibility back onto the operator. The official documentation, the recent 1.38 modernization work, and the project’s vulnerability history all point to the same conclusion: ZoneMinder should be treated as a real application platform with a privileged management plane, not as a harmless camera accessory. (zoneminder.com)

If you are defending a ZoneMinder deployment today, the practical priorities are straightforward. Know your exact branch and patch level. Enable auth and replace default credentials immediately. Use least privilege for users and API access. Keep the UI and API off the public internet wherever possible. Prefer token-based API usage over credentials in URLs. Terminate TLS properly. Segment cameras from the rest of the environment. Monitor storage and memory health so the system fails predictably instead of chaotically. And after every meaningful change, validate the posture again rather than assuming the config you intended is the config you have. (ZoneMinder Documentation)

That is the right way to think about ZoneMinder in 2026. Not as a curiosity. Not as a shortcut to cheap surveillance. As a Linux-hosted surveillance stack that can absolutely serve serious use cases, but only if it gets the same security respect you would give any other web application with credentials, tokens, data, remote access, and a meaningful history of vulnerabilities. (寡黙)

Quick reference table, the ZoneMinder issues that matter most

Further reading

• ZoneMinder official features page
• ZoneMinder official documentation
• ZoneMinder API documentation
• ZoneMinder Getting Started guide
• ZoneMinder GitHub releases
• GitHub advisory for CVE-2023-26035
• NVD entry for CVE-2024-51482
• NVD entry for CVE-2024-43360
• CISA vulnerability bulletin, August 12 2024
• ZoneMinder Security, What Security Engineers Need to Know About the Open Source CCTV Stack
• ZoneMinder v1.37.63 CVE — The Vulnerability Security Teams Are Actually Looking For