CISA Advisory: Unauthenticated Access in India CCTV Cameras (CVE-2025-13607)

  • Thread Author
A cluster of India‑deployed CCTV cameras from three vendors has been flagged in a CISA industrial‑control‑systems advisory for a missing authentication defect that can disclose configuration data and account credentials — a vulnerability tracked as CVE‑2025‑13607 and scored in the high‑severity range, with D‑Link publishing a firmware update for at least one affected model while two local vendors did not coordinate publicly.

Hooded figure with a tablet exploits missing authentication in a dim alley under CCTV cameras.Background / Overview​

Networked surveillance cameras remain one of the most frequently exploited IoT categories: low‑cost hardware, convenience‑first provisioning, and cloud‑brokered remote access create recurring opportunities for attackers to bypass intended controls. The advisory at the center of this feature reports a Missing Authentication for a Critical Function vulnerability in multiple India‑market CCTV cameras from D‑Link (India Limited), Sparsh Securitech, and Securus CCTV. The only vendor and model publicly confirmed with an available patch is the D‑Link DCS‑F5614‑L1 (firmware versions v1.03.038 and prior are cited as affected). The advisory warns that an unauthenticated request to a specific URL on a vulnerable device can return sensitive configuration information, including camera account credentials.
This is not an isolated incident. CISA and independent researchers have repeatedly seen the same class of failure across camera ecosystems: unauthenticated ONVIF/RTSP endpoints, exposed management APIs, or brokered cloud tokens that can be retrieved or replayed. The operational consequence is immediate: remote viewing of live video, exfiltration of stored credentials, or unauthenticated configuration changes that can blind or tamper with monitoring systems.

What the advisory says (concise summary)​

  • Vendors listed: D‑Link (India Limited), Sparsh Securitech, Securus CCTV. D‑Link is the only vendor with an identified patched model in the advisory.
  • Affected D‑Link model: DCS‑F5614‑L1 — firmware v1.03.038 and prior. D‑Link has published a security advisory and released updated firmware; users are urged to apply the update and verify the installed version.
  • Vulnerability class: Missing Authentication for a Critical Function (CWE‑306).
  • Assigned identifier: CVE‑2025‑13607 (CISA published the advisory and assigned the CVE).
  • Severity and scoring: CISA reports very high scores — CVSS v3 base ~9.4 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:L) and CVSS v4 base ~9.3 — indicating network‑accessible, unauthenticated impact with significant confidentiality and integrity consequences.
  • Impact: Successful exploitation can disclose device configuration and camera account credentials, enabling remote viewing and configuration tampering.
  • Vendor coordination: Sparsh Securitech and Securus CCTV did not respond to CISA coordination requests; D‑Link did and provided a firmware update for the listed model. Users of the non‑responding vendors are advised to contact their vendor support for status and to assume the devices may be vulnerable until proven otherwise.

Why this matters: real operational risk​

Surveillance cameras are not just "cameras" — they are sensors, sometimes controllers, integrated into building‑management, access control, and safety systems. When an attacker can obtain admin credentials or configuration payloads, multiple impacts follow:
  • Confidentiality loss: live video streams and archived footage often contain personally identifiable information (PII), proprietary activities, or operational details. Unauthorized access is a privacy and compliance risk.
  • Integrity loss: an attacker with config access can change motion detection, recording schedules, or PTZ (pan/tilt/zoom) presets — effectively blinding monitoring when it matters most.
  • Availability risk: configuration changes or malicious firmware pushes can disrupt recording services and degrade incident response capability.
  • Lateral movement: cameras frequently share networks with NVRs (network video recorders), management servers, or Windows workstations used for VMS maintenance; compromised cameras can be reconnaissance nodes for broader compromise.
Mass scanning and automated exploitation are realistic here: the vulnerability requires no authentication and has low attack complexity, making internet‑facing or poorly segmented camera deployments particularly attractive targets.

Technical details and attack surface​

How attackers exploit a "missing authentication" endpoint​

  • The camera firmware exposes an HTTP(S) endpoint returning configuration metadata. This endpoint was intended for authenticated management or internal use but lacks access control checks.
  • A remote requester can call the endpoint and receive:
  • Administrative usernames (or account identifiers)
  • Password hashes or plaintext credentials (where firmware stores secrets insecurely)
  • NVR connection parameters and cloud pairing tokens
  • With retrieved credentials or tokens, the attacker can:
  • Log into the web UI or ONVIF services
  • Connect to RTSP streams
  • Modify PTZ, recording schedules, or event triggers
  • Create persistent accounts or modify firmware update sources
This attack chain mirrors other camera advisories where ONVIF, RTSP, or cloud‑broker APIs were exposed without proper authentication, enabling immediate confidentiality and integrity breaches.

Why ONVIF and RTSP matter​

  • ONVIF: an industry SOAP‑based interface used for discovery and camera control; if management methods (profile or configuration reads) are unauthenticated, an attacker can enumerate NVR connections and credentials.
  • RTSP: the streaming protocol; if streams are accessible without authentication, live video is trivially replayable.
  • Poorly segmented ONVIF/RTSP exposure is a common root cause in multiple CISA camera advisories and is central to the practical exploitability of this vulnerability class.

Verification and cross‑checks (what is confirmed and what needs caution)​

Verified facts:
  • CISA published an ICS advisory describing missing‑authentication risk for certain India‑market cameras and assigned CVE‑2025‑13607 as the tracking identifier. The advisory explicitly lists D‑Link (India Limited) and the DCS‑F5614‑L1 model as confirmed affected with firmware v1.03.038 and prior.
  • D‑Link maintains a Security Advisories / Security Bulletin program and has posted vendor security bulletins; D‑Link published an advisory and a firmware update for the affected model per the advisory’s guidance. Administrators should use D‑Link’s official bulletin pages to obtain and validate the update.
  • Independent vulnerability trackers and vulnerability‑database aggregators list prior vulnerabilities for the DCS‑F5614‑L1 model and indicate remediation activity in D‑Link firmware history, supporting the claim that D‑Link has previously issued fixes for this hardware family.
Points requiring cautious treatment:
  • Public indexing of CVE‑2025‑13607 in canonical CVE/NVD or MITRE databases may lag the agency advisory. Where public CVE registries do not yet mirror CISA’s assignment, treat the CISA advisory as authoritative for triage but confirm before automating remediation in large inventories. The advisory itself warns of this disclosure/coordination lag.
  • Sparsh Securitech and Securus CCTV did not respond to coordination requests; therefore, claims about exact affected models from those vendors remain unverified in the public advisory. Operators using those vendors must contact vendor support to confirm exposure.

Immediate triage: a short checklist (minutes → hours)​

  • Inventory and discovery
  • Discover all cameras (IP, MAC, model string, firmware) with network scans (Nmap, ONVIF discovery tools) and asset inventories.
  • Remove Internet exposure
  • Block inbound NAT/port forwards to camera management ports (HTTP/HTTPS), ONVIF, and RTSP. Do this at perimeter firewalls immediately.
  • Isolate vulnerable devices
  • Move cameras to a dedicated VLAN with restrictive egress rules. Deny camera VLAN access from general corporate workstations.
  • Disable or restrict RTSP/ONVIF
  • Temporarily disable RTSP/ONVIF on devices where it's not required, or restrict access to known management hosts.
  • Validate vendor patches
  • For D‑Link DCS‑F5614‑L1, obtain the published firmware from D‑Link's official security advisory page and validate checksums after download before applying. Always confirm the GUI reports the new firmware version post‑update.
  • Preserve forensic artifacts
  • Collect camera config exports, NVR logs, and any suspicious connection logs for investigation.
This rapid triage aligns with repeated CISA recommendations for camera advisories and yields the highest immediate reduction of risk.

Medium‑term remediation and hardening (24 hours → weeks)​

  • Apply vendor updates in a staged manner: pilot update → monitor → full rollout. Validate firmware signatures or checksums where the vendor provides them.
  • Where vendor updates are unavailable (Sparsh/Securus) or devices cannot be patched:
  • Replace high‑risk units installed on perimeter or public‑facing sites.
  • Implement proxying: put camera streams behind an authenticated gateway that enforces MFA and logs all access.
  • Credential hygiene:
  • Rotate all camera admin passwords and any NVR integration credentials.
  • Enforce unique credentials per device and store them in a centralized secrets manager.
  • Harden remote access:
  • Restrict management access to jump hosts with MFA and host‑based posture checks.
  • Avoid vendor maintenance tunnels that bypass corporate controls unless they are tightly controlled and logged.
  • Logging and detection:
  • Centralize camera and NVR logs to a hardened SIEM.
  • Add IDS/IPS rules to detect unauthenticated ONVIF/RTSP calls or discovery scans.
  • Alert on new or unusual egress from camera VLANs to unfamiliar cloud endpoints.

Practical guidance for Windows administrators and integrators​

Many VMS/NVR suites and camera management consoles run on Windows servers and workstations. Windows administrators should:
  • Treat engineering and operations workstations used to manage cameras as high‑risk endpoints: enforce EDR, full disk encryption, least privilege, and strict patching.
  • Avoid using general‑purpose admin laptops for camera maintenance; instead, use hardened jump hosts with recorded sessions and MFA.
  • Ensure that Windows servers hosting VMS or NVR software are patched, use dedicated service accounts with least privilege, and are isolated from general user networks.
  • Configure Windows firewall rules to restrict outbound access to known camera cloud endpoints and approved vendor IPs when vendor relays are required.
  • Audit backup and configuration export storage locations — configuration files often contain plain or weakly protected credentials; ensure they are access‑controlled and encrypted at rest.

Detection and hunting playbook​

  • Use ONVIF discovery tools to detect unauthenticated discovery responses on your network.
  • Search SIEM for repeated requests to cameras’ configuration endpoints, unexpected RTSP session initiations from unfamiliar external IPs, or sudden account‑creation events in camera logs.
  • For Windows hosts, look for:
  • Recent exports/imports of camera configuration files.
  • Unexpected network connections from management workstations to cloud relay IPs.
  • New scheduled tasks or services associated with VMS/NVR software.
  • Preserve packet captures for any suspicious RTSP/ONVIF traffic to enable reconstruction and attribution.

Vendor coordination and procurement implications​

  • Favor vendors that maintain an active security bulletin program, publish advisories, and provide signed firmware updates. D‑Link maintains a Security Bulletin portal; this is a basic procurement gating criterion for camera vendors.
  • Treat vendor non‑response as an operational risk: if a vendor does not coordinate on disclosures, plan for replacement or permanent isolation for any devices that cannot be independently shown to be patched or mitigated.
  • Include security requirements in procurement: mandatory disclosure timelines, secure boot/firmware signing, enforceable EOL policies, and update mechanisms.

Strengths and weaknesses of the advisory and remediation posture​

Notable strengths:
  • The advisory provides concrete affected models and firmware for the D‑Link camera and a high‑priority CVE assignment, enabling focused triage.
  • CISA’s remediation guidance — network isolation, firewalling, jump hosts/VPNs, and segmentation — are high‑leverage operational controls that rapidly reduce attack surface across camera fleets.
Operational weaknesses and risks:
  • Vendor non‑response from Sparsh Securitech and Securus CCTV creates unpatched device risk clusters that organizations must treat conservatively.
  • Public CVE registries and vendor advisories sometimes lag agency advisories; automation systems that rely solely on NVD/MITRE may not flag the risk immediately. The advisory itself warns of this timing mismatch.
  • Cameras are often deployed in heterogeneous estates with manual update cycles and limited central management, which complicates rapid remediation.

Final assessment and recommended next moves​

This advisory follows a well‑worn but still urgent pattern: network‑accessible cameras exposing critical configuration and credentials due to missing authentication. The immediate risk is high because the flaw is exploitable remotely with low complexity and yields high confidentiality and integrity impact.
Recommended prioritized actions:
  • Treat any exposed D‑Link DCS‑F5614‑L1 running firmware v1.03.038 or earlier as vulnerable until patched; obtain the D‑Link update and validate the firmware version via the device UI after upgrade.
  • Immediately block inbound camera management ports at the perimeter and isolate camera VLANs.
  • Assume non‑responsive vendor devices (Sparsh/Securus) are unpatchable in the short term and enforce strict network segmentation or replacement for high‑risk sites.
  • Harden Windows hosts that manage camera fleets with EDR, jump hosts, MFA, and least privilege controls.
  • Implement logging, detection rules, and an incident response playbook that includes preservation of camera config exports and NVR logs.
Organizations should treat this advisory as an operational priority: the pathway from an unauthenticated endpoint to exposed credentials is short, repeatable, and automatable. Remediation requires a mixture of vendor‑driven firmware updates where available, and robust network and operational controls where updates are absent or delayed.
Caution: some details reported in vendor‑agnostic vulnerability aggregators and public trackers may lag or differ from the CISA advisory’s assigned CVE and affected‑version strings. Verify the CVE and firmware targets against the CISA advisory text and the vendor’s official security bulletin before executing large‑scale automated changes. Conclusion: prioritize immediate network containment, validate D‑Link firmware installations, and treat other India‑market camera fleets from non‑responsive vendors as high‑risk assets requiring isolation or replacement until vendors provide confirmed fixes.
Source: CISA Multiple India-based CCTV Cameras | CISA
 

Back
Top