CVE-2023-52163 Digiever DS-2105 Pro NVR Botnet Risk and Mitigation

CISA’s Known Exploited Vulnerabilities (KEV) catalog has been updated to include a vulnerability tied to the DigiEver DS‑2105 Pro network video recorder (NVR) — CVE‑2023‑52163 — a command‑injection flaw that security researchers have observed being weaponized by Mirai‑style botnets against exposed IoT devices, amplifying risk for organizations that still operate legacy or end‑of‑life (EOL) DVR/NVR equipment.

Background​

The vulnerability identified as CVE‑2023‑52163 was publicly recorded in early February 2025 and is described as a command injection via the device’s CGI endpoint (specifically the time_tzsetup.cgi parameter), which allows an attacker to cause the device to execute arbitrary shell commands when certain inputs are not properly authorized or sanitized. Multiple independent security vendors and researchers documented the technical details and proof‑of‑concept exploitation patterns in January–February 2025. CISA’s KEV catalog — established under Binding Operational Directive (BOD) 22‑01 — is designed to identify CVEs that are being actively exploited in the wild and to require accelerated remediation by Federal Civilian Executive Branch (FCEB) agencies. BOD 22‑01 requires agencies to remediate cataloged vulnerabilities according to specific timelines and encourages the private sector to prioritize KEV items as part of risk‑based patching.

---

What the vulnerability actually is​

Technical summary​

• Affected component: Digiever DS‑2105 Pro firmware (reported version 3.1.0.71‑11 and prior).
• Vulnerability type: Command injection via the CGI endpoint, with the exploitable parameter chain involving /cgi‑bin/cgi_main.cgi and the time_tzsetup.cgi function.
• Root cause: Missing authorization checks combined with unsanitized input to a backend command execution path (CWE‑862).

Independent vulnerability records list the CVSS v3.1 score at 5.9 (Medium); NVD mirrors the same description and lists CWE‑862 (Missing Authorization) as the weakness. Those scoring and classification details match records aggregated by established vulnerability databases.

How attackers use it​

Research teams that monitored global honeypots observed attacker payloads that match the proof‑of‑concept pattern: crafted HTTP POST requests that call /cgi‑bin/cgi_main.cgi?cgiName=time_tzsetup.cgi with an ntp parameter containing shell backticks or command separators to download a remote payload (often a Mirai‑variant binary) and execute it on the target. The Akamai Security Intelligence Response Team (SIRT) documented these payloads and tied them to active botnet activity starting in late 2024. A representative exploit string observed in the wild demonstrates the classic pattern: the attacker supplies an ntp value that includes commands to fetch a malware binary (via curl or wget), change file permissions, and execute it — effectively turning vulnerable NVRs into botnet nodes.

---

Evidence of active exploitation and attribution​

• Akamai SIRT observed active exploitation attempts against the vulnerable CGI endpoint in mid‑November 2024 and mapped the observed payload syntax to the public proof‑of‑concept described by researchers. This activity included downloads of Mirai‑style payloads and subsequent binary execution on compromised devices.
• TXOne Networks’ research (authored by Ta‑Lun Yen) discloses the original discovery and describes two related issues affecting DigiEver devices — including the command injection tracked as CVE‑2023‑52163 — and notes that one of those bugs was exploited in the wild. TXOne provides detection rules and recommended mitigations for defenders.

Multiple third‑party vendors (IPS/IDS and vulnerability aggregation platforms) have published detections and protections for the issue, indicating both community interest and real‑world exploitation pressure on exposed devices. Check Point, for example, built a protection signature to detect exploitation attempts targeted at the Digiever CGI command injection pattern.

---

Why this matters: risk and impact​

• Legacy IoT devices remain high‑value targets. Many DVR/NVR vendors used common codebases across models; when a command‑injection flaw exists in the shared CGI gateway, a broad class of devices can be vulnerable. The DigiEver DS‑2105 Pro is an example of an older product line that many organizations still operate, particularly in physical security deployments.
• EOL devices often lack vendor patches. Both the original researcher and subsequent advisories emphasize that affected DigiEver firmware versions are unsupported (EOL), meaning vendors may not issue fixes — leaving operators with limited remediation options beyond mitigation or device replacement.
• Rapid weaponization into botnets. The exploit pattern directly enables malware download and execution; that capability is ideal for Mirai‑style botnets that seek to grow their fleet and perform DDoS, scanning, or lateral movement tasks. Honeypot telemetry showed attackers using the flaw to drop Mirai variants using modern encryption routines (ChaCha20 + XOR).
• Operational and supply‑chain implications. Compromised NVRs can act as beachheads into supervisory networks, exfiltrate camera feeds, participate in DDoS campaigns, and complicate incident response — especially where CCTV management systems interconnect with broader IT or OT infrastructure.

---

Verification and cross‑checking of key facts​

To ensure technical accuracy, the following claims were verified against multiple independent sources:

• The vulnerability is a command‑injection issue affecting time_tzsetup.cgi and is tracked as CVE‑2023‑52163 — corroborated in the TXOne disclosure and Akamai’s SIRT write‑up.
• The published CVSS score of 5.9 (v3.1) and the assignment of CWE‑862 (Missing Authorization) appear in the National Vulnerability Database (NVD) and in vulnerability aggregation sites.
• Active exploitation (botnet delivery of Mirai‑style payloads) was observed in honeypots prior to the public CVE assignment — documented by Akamai and referenced by other threat vendors.
• Vendor patch availability is not established; multiple advisories note the product is unsupported and lack a vendor fix, leaving mitigation and device replacement as the primary options.

Where direct vendor patch notices or an official Digiever security advisory would be the definitive source of remediation guidance, no public vendor patch advisory was found for the DS‑2105 Pro (the device appears to be EOL). That absence should be treated as a material condition: organizations must assume a lack of vendor patch and plan accordingly.

---

Immediate mitigation and remediation guidance (practical checklist)​

For Federal agencies subject to BOD 22‑01 and private organizations managing CCTV/IoT fleets, the following prioritized steps combine defensive hardening, detection, and replacement strategies.

Short term — immediate risk reduction (apply within hours to days)​

• Isolate the device from the Internet. Block inbound access to device management ports (HTTP/HTTPS and any CGI endpoints) at the network edge and via internal firewalls. If remote management is required, require access over an authenticated VPN jump host. This is the single most effective temporary control.
• Disable remote management interfaces. Where possible, disable web management or bind it to trusted management VLANs/subnets only. Replace any default or weak credentials; if default credentials were used, treat the device as already compromised until proven otherwise.
• Apply IDS/IPS signatures and network detection rules. Use vendor protections/patterns released by IPS/IDS vendors (examples: Check Point IPS protection, TXOne Snort rules). Install the latest protection updates to block the known exploit patterns.
• Implement network segmentation and egress controls. Prevent compromised devices from reaching arbitrary external hosts by enforcing allow‑listed egress destinations and limiting DNS and HTTP/HTTPS outbound flows.

Medium term — investigations and monitoring (days to weeks)​

• Scan for indicators of compromise (IoCs). Hunt for the Mirai‑style downloader hosts, unusual outbound connections to known C2 IPs, or the exploitation HTTP pattern calling cgi_main.cgi with time_tzsetup parameters. Use network telemetry and EDR logs where available. Akamai and TXOne published IoCs and Snort/Yara/Snort3 rules that accelerate detection.
• Patch or replace. If vendor patches for an affected model are eventually released, apply vendor‑provided updates per normal patching processes. If the device is EOL and no fix exists, replace the device with a maintained, security‑supported model as soon as practicable. Device replacement should be planned and budgeted immediately for EOL CCTV/NVR hardware.
• Conduct forensic triage for exposed assets. If a device was reachable from the Internet, perform forensic checks (file creation times, unexpected binaries, running processes, scheduled tasks) and consider full device rebuilds where compromise indicators are present. Assume compromise when direct exploitation patterns were observed.

Long term — strategic controls​

• Maintain an asset inventory that tracks device EOL status, firmware versions, and vendor support windows. BOD 22‑01 emphasizes asset inventory as crucial for triage and prioritized remediation.
• Implement a policy that prohibits Internet‑exposed management interfaces for security cameras and NVRs; require administrative access via jump boxes or bastion hosts with MFA.
• Adopt network micro‑segmentation for physical security systems, and enforce strict RBAC for camera management consoles.

---

Detection signatures and vendor protections (practical notes)​

• TXOne published Snort rules for both CVE‑2023‑52163 (command injection) and CVE‑2023‑52164 (arbitrary file read) — defenders can deploy these or translate them to other IDS formats to quickly detect exploit attempts on HTTP request bodies targeting /cgi‑bin/cgi_main.cgi.
• IPS vendors (including Check Point) have added protections to their signature libraries to detect the exploit pattern and block exploitation attempts; ensure IPS definitions are up to date and that policies are enabled to block (not only alert) by default for these signatures.
• Honeypot and telemetry companies (Akamai and others) documented IoCs such as fixed C2 IP addresses and download URLs used by the Mirai‑variant payloads; use those IoCs with caution — prioritize detection via behavior and request patterns rather than over‑reliance on static IPs.

---

Policy and compliance implications for federal and private sectors​

• Under BOD 22‑01, agencies must remediate KEV catalog vulnerabilities within prescribed windows (timelines differ based on when the CVE was assigned), and CISA uses the KEV list to set those remediation timelines. Organizations that manage federal systems must follow the BOD‑mandated processes for vulnerability remediation and reporting.
• For non‑federal organizations, the KEV list serves as priority guidance: while not mandatory, the list reflects active exploitation and should influence risk‑based patching and procurement decisions, particularly in environments that rely on EOL hardware for physical security.

---

Critical analysis: strengths and remaining risks​

Notable strengths in the public response​

• Rapid community disclosure and telemetry correlation: The chain from independent discovery (TXOne) through public disclosure (Akamai SIRT) to aggregation and signature creation by security vendors demonstrates an effective vulnerability‑research ecosystem that turned discovery into actionable detection capability quickly. That collaboration reduced time‑to‑detect for defenders.
• Operational detection artifacts published: TXOne’s Snort rules and Akamai’s IoCs give defenders concrete artifacts to deploy in IDS/IPS and SIEMs, enabling detection even where patching is unavailable.

Remaining risks and gaps​

• Vendor EOL and patch unavailability: The most consequential gap is that the affected DigiEver firmware is EOL and the vendor declined to provide a patch for the affected models — an industry‑wide problem where security support does not extend to long‑lived physical infrastructure. That forces organizations into mitigation or replacement, both expensive and time‑consuming.
• Scale of exposed devices: CCTV and NVR devices are often deployed in large numbers across campuses and multi‑site environments. Complete replacement or network segmentation campaigns can be logistically complex, increasing the window of exposure.
• Automated exploitation and botnet growth: Mirai‑like toolchains and botnet operators continue to adapt payloads and obfuscation, reducing the long‑term effectiveness of static IoC lists. Behavior‑based detection and robust network controls remain necessary.

---

Recommended checklist for Windows and IT administrators (quick action set)​

• Block external HTTP management access to all CCTV/NVR devices immediately.
• Update IDS/IPS rules to include TXOne Snort signatures and vendor IPS protections.
• Search network telemetry for HTTP POSTs to /cgi‑bin/cgi_main.cgi and identify devices making outbound connections to known C2 hosts described in public telemetry.
• Change any default credentials and audit for weak or shared admin passwords on camera and recorder devices.
• Schedule replacement of EOL devices and prioritize budgeting for supported hardware.
• For federal systems, log remediation status through CDM Federal Dashboard or CyberScope as required under BOD 22‑01.

---

Verification note and cautionary language​

Public advisories and telemetry from Akamai and TXOne documented exploitation and provided PoC payloads and IoCs. National vulnerability records (NVD) and mainstream security vendors list the CVE with a CVSS v3.1 score of 5.9 and classify the weakness as CWE‑862 (Missing Authorization). Those independent sources converge on the technical nature and active exploitation of the issue. A caveat: a CISA alert URL provided in initial reports could not be retrieved from the public CISA site at the specific Dec 22, 2025 URL at the time of verification (HTTP 403 on that resource). However, CISA’s KEV/BOD 22‑01 program and weekly vulnerability bulletins do include these DigiEver‑related CVEs in February 2025 vulnerability summaries and CISA’s KEV management processes validate why such a CVE would be added to the KEV list when reliable evidence of exploitation exists. Organizations should rely on the KEV catalog and their official CISA notifications for compulsory remediation timelines while treating any single blocked URL as an availability issue rather than proof the catalog entry does not exist.

---

Conclusion​

CVE‑2023‑52163 is a textbook example of how EOL IoT/physical‑security hardware becomes an attractive vector for automated exploitation and botnet recruitment. The chain of discovery (TXOne), validation and telemetry (Akamai), and subsequent vendor protections and KEV consideration underscores a functioning researcher‑to‑defender pipeline — but it also exposes the systemic problem: unsupported devices in production environments.
For immediate safety, network defenders must treat these devices as untrusted and apply aggressive containment (isolation, IPS/IDS rules, and replacement planning). For program managers and purchasing authorities, the incident reinforces the urgent need for asset lifecycle governance, procurement language that guarantees security support, and budgeted replacement cycles for end‑of‑life infrastructure.
Prioritize detection and containment now, plan device replacement as a near‑term capital project, and align reporting and remediation steps with BOD 22‑01 timelines where federal systems are involved. The combination of behavior‑based detection, network segmentation, updated IPS signatures, and replacement of unsupported hardware is the only defensible path to reduce the immediate and long‑term risk posed by this class of IoT vulnerabilities.

---

Source: CISA CISA Adds One Known Exploited Vulnerability to Catalog | CISA