Critical Longwatch RCE CVE-2025-13658: Patch to 6.335 Now

A severe, unauthenticated remote code‑execution vulnerability in Industrial Video & Control’s Longwatch video surveillance and monitoring platform has been disclosed by CISA: an exposed HTTP endpoint in Longwatch versions 6.309 through 6.334 allows specially crafted HTTP GET requests to execute arbitrary code at SYSTEM privileges (tracked as CVE‑2025‑13658), and Industrial Video & Control (IVC) recommends immediate upgrade to Longwatch 6.335 or later. This is a high‑urgency ICS risk — CVSS scores published in the advisory put the flaw in the critical range (CVSS v3.1 9.8; CVSS v4 9.3), and CISA lists Energy and Water/Wastewater customers among likely deployers.

---

Background​

Industrial Video & Control (IVC) acquired Longwatch some years ago and maintains the Longwatch product line — a video management and video‑historian platform used in industrial SCADA/HMI environments, utilities, and process plants for both security monitoring and operational diagnostics. IVC’s Longwatch product family includes at‑edge Video Engine components and a centralized Video Control Center used by operators and HMIs. Public company material and industry press describe Longwatch as integrated into SCADA/HMI systems for process visibility and compliance monitoring. CISA and other ICS reporting channels routinely publish advisories aggregating and indexing vulnerabilities impacting industrial control systems; CISA’s advisory program is the primary government channel used to raise cross‑domain awareness for operational technology exposures, and it pairs vendor mitigation guidance with recommended network hardening measures. Review of recent CISA ICS advisories shows the agency’s long‑standing recommendations for minimizing internet exposure, network segmentation, and cautious use of VPNs for remote access — guidance echoed in the Longwatch advisory.

---

Executive summary of the Longwatch vulnerability​

• Affected products: Longwatch versions 6.309 through 6.334.
• Fixed version: Longwatch 6.335 or later (vendor advisory recommends upgrading).
• Vulnerability class: Improper control of code generation / code injection — unauthenticated HTTP GET requests can trigger code execution on the device.
• Impact: Unauthenticated remote code execution with SYSTEM‑level privileges (full control of the device and services).
• CVE: CVE‑2025‑13658 (CISA assigned and published in the CSAF advisory).
• Severity: CVSS v3.1: 9.8 (critical); CVSS v4: 9.3 (critical).
• Sectors of concern: Energy; Water and Wastewater Systems; worldwide deployments.
• Reported by: a concerned OT engineer, coordinated to CISA (per the advisory).
• Exploitation status: advisory reports no known public exploitation at the time of publication; this does not imply exploitation will not occur.

---

Why this matters: technical implications and attack scenarios​

The nature of the flaw​

Code‑injection via an unauthenticated HTTP GET means the product exposes an HTTP endpoint that accepts input and — due to missing execution controls or code signing and insufficient sanitization — interprets parts of that input as executable content. The advisory states this endpoint can be reached without authentication and that exploitation yields SYSTEM privileges on the host running the Longwatch service.
This combination is exceptionally dangerous in ICS contexts for several reasons:

• Unauthenticated remote access: attackers need only network reachability to the device (no credentials).
• Low attack complexity: a single crafted GET request can trigger the condition, enabling automation and rapid scanning at scale.
• Full system privileges: SYSTEM‑level control permits persistent backdoors, tampering with logs, capture of video streams (sensitive evidence), and use of the compromised device as a pivot for lateral movement.
• Operational placement: Longwatch is often integrated into control networks and HMI consoles, which can bridge OT and IT domains, increasing the blast radius.

Realistic exploitation vectors​

• Internet‑facing devices: if an operator or integrator has exposed management ports to the internet (common with remote monitoring deployments), automated scanners could find and exploit vulnerable endpoints.
• Business‑network pivot: attackers who compromise an IT workstation with access to the control network could reach Longwatch services and trigger RCE.
• Supply‑chain or managed service access: third‑party integrators or cloud bridges with privileged network connectivity could be abused to reach vulnerable units.
• Targeted attacks on utilities: because Longwatch is used in Energy and Water environments, adversaries targeting critical infrastructure may find this vulnerability attractive for sabotage, espionage, or staging further attacks.

---

Strengths and immediate positives in the response​

• Coordinated disclosure: the vulnerability was reported through responsible channels (researcher → CISA → vendor), and the advisory includes a clear remediation path (upgrade to 6.335+).
• Vendor remediation: IVC published a fixed version (6.335) — that’s the best practical mitigation and should be prioritized by operators.
• Government guidance: CISA’s advisory restates well‑tested ICS mitigations (minimize internet exposure, network segmentation, isolate control networks behind firewalls, use secure remote access). Those recommendations provide an immediate framework for defenders while patches are applied.

---

Risks, caveats, and unanswered questions​

• Public exploit availability: the advisory states no known exploitation reported to CISA at the time of publication. That is not equivalent to "no exploitation" — many intrusions go unreported, and weaponization of unauthenticated RCE vulnerabilities is common. Treat the advisory as urgent even without confirmed in‑the‑wild usage.
• Vendor bulletin visibility: at the time of this analysis, public vendor advisory pages and central CVE database entries (NVD/MITRE) were not consistently discoverable for CVE‑2025‑13658 in mainstream vulnerability portals. Administrators must validate the vendor release notes, firmware hashes, and distribution channels directly with IVC to ensure they obtain authentic, untampered patches. If vendor advisories are not accessible, coordinate through official support channels or local integrators. (Flag: this claim about absence of some third‑party index references is time‑sensitive and subject to change; operators should confirm current listings.
• Operational patching constraints: ICS environments often have strict maintenance windows and change control, slowing patch rollout. That delay increases exposure time and requires compensating controls until devices are updated.
• Long tail and unmanaged devices: many Longwatch installations are embedded in distributed infrastructure (pump stations, substations, remote telemetry sites). Tracking and updating every unit is operationally difficult and can leave gaps.

---

Practical, prioritized actions for system owners and Windows‑centric admins​

The following checklist is ranked: immediate emergency steps first, then short‑term compensations, then medium‑term remediation and monitoring.

Immediate (hours)​

• Confirm exposure and inventory:
• Identify all Longwatch hosts (versions 6.309–6.334) on your network. Use asset inventory, CMDB and network scans. Prioritize internet‑facing and DMZ units.
• Block external access:
• If any Longwatch device is reachable from the internet, block access immediately at edge firewalls and routers (deny inbound ports used by Longwatch management).
• Isolate vulnerable units:
• Move affected devices into a segmented management VLAN with no direct route to the internet or business networks. Use network ACLs to restrict traffic to only required operator consoles and trusted integrator IPs.
• Contact vendor and support:
• Open an incident case with IVC support and request authenticated patch packages and SHA256 checksums for Longwatch 6.335; obtain any vendor hardening guidance.

Short term (1–7 days)​

• Schedule emergency patching:
• Plan and test deployment of Longwatch 6.335 in a staging environment (if available). Validate that the update removes the vulnerable endpoint and that normal operational workflows continue.
• Apply compensating controls when patching cannot be immediate:
• Web application firewall (WAF) rules: block or filter suspicious GETs to the exposed endpoint if you can identify the endpoint path.
• Host‑level hardening: if feasible, disable unneeded Longwatch services or block HTTP management interfaces at the host firewall until patched.
• Tighten remote access:
• If remote access is required, place management access behind a hardened jump host (bastion) and enforce multi‑factor authentication (MFA) and EDR on the jump host.
• Increase logging and detection:
• Enable verbose logging for Longwatch services and collect logs centrally (SIEM). Create alerts for anomalous incoming HTTP GET requests and unexpected process launches on Longwatch hosts.

Medium term (2–8 weeks)​

• Full patch rollout:
• Apply Longwatch 6.335 to all affected units using change control; verify backups and rollback plans before mass rollout.
• Validate integrity:
• After patching, validate installed binaries against vendor checksums. Confirm service behavior and test operator workflows.
• Update incident response and playbooks:
• Add detection signatures for this vulnerability to your IR runbook. Ensure containment steps (isolation, memory capture, forensic images) are rehearsed for remote ICS hosts.
• Harden architecture:
• Revisit architecture to minimize need for direct device exposure: use collector nodes, aggregated relays, and readonly streaming proxies rather than open management endpoints.

---

Concrete Windows‑environment detection & hardening guidance​

Many operators run the Longwatch client or management consoles on Windows workstations or servers. Windows admins should take these steps:

• Endpoint protection:
• Ensure EDR/AV agents on Windows operator workstations are up to date and storing telemetry to a central system. Create alerts for suspicious child processes spawned by the Longwatch management console or for processes invoking cmd.exe or PowerShell unexpectedly.
• Restrict SMB and admin ports:
• Enforce network separation between Windows corporate desktops and OT zones. Apply strict firewall rules and use Windows Firewall Group Policy to block unnecessary outbound access to OT device ports.
• Harden jump hosts and consoles:
• If Windows jump hosts are used to manage Longwatch components, require MFA, restrict allowed users by AD groups, and run all management in a dedicated, monitored bastion host hardened to CIS benchmarks.
• Log correlation:
• Correlate Windows security logs (Event IDs for process creation, logon failures, scheduled task creation) with network indicators (new HTTP GET requests, unusual connections) in your SIEM to detect early lateral activity.

---

Detection heuristics and indicators of compromise (high level)​

• Network indicators:
• Repeated or abnormal HTTP GET requests to Longwatch management endpoints from external or unknown internal IP addresses.
• Unusual HTTP User‑Agents or long query strings in GET requests targeting video management hosts.
• Host indicators:
• Unexpected child processes launched by Longwatch services (especially cmd.exe, powershell.exe or unfamiliar binaries).
• New scheduled tasks, services, or persistence artifacts appearing on Longwatch hosts.
• Sudden configuration changes in Longwatch (new user accounts, changed streams, disabled logging).
• Log indicators:
• Gaps in video archives, deleted logs, or logs showing tampering or altered timestamps.
• Behavioral:
• Outbound connections from Longwatch hosts to unknown external IPs after presumed compromise.

Avoid public PoC scanning and never attempt exploit verification on production devices — treat suspicious activity as incident‑grade and follow containment steps.

---

Validation, verification, and supply‑chain caution​

• Always obtain updates through vendor‑sanctioned, authenticated channels. Verify cryptographic hashes (SHA256) before applying firmware or binary updates.
• If vendor advisory text or CVE entries are not present in public CVE/NVD indexes (a time‑sensitive status), confirm the advisory via vendor support and CISA channels, and document vendor‑provided artifacts and support ticket IDs.
• Because ICS networks sometimes contain legacy systems, test patches in a representative staging environment where possible and coordinate maintenance windows with uptime and safety teams.

Note: during verification for this article, mainstream third‑party vulnerability indexes and vendor security pages did not all show a consistent, discoverable listing for CVE‑2025‑13658 at the time of retrieval; administrators should not assume that central indexes fully reflect vendor advisories or internal CSAR/CSAF releases and must check vendor and CISA communications directly for the authoritative patch file and guidance.

---

Detection playbook — short step‑by‑step​

• Run immediate host discovery to enumerate Longwatch build versions (6.309–6.334).
• Block management ports at perimeter firewalls for any device with those versions.
• Capture full system images and network flow logs for any host showing suspicious GETs.
• Deploy a WAF rule to drop malformed GETs to known vulnerable endpoint paths (temporary).
• Patch to Longwatch 6.335 in a controlled test first; if successful, schedule measured rollout.
• Lock down admin credentials, rotate any service account secrets, and review access logs for credential theft.

---

Broader implications and lessons for ICS operations​

• Design for least privilege and assume devices will be found: ICS equipment should not rely on obscurity or network inaccessibility as the primary security control.
• Code signing and execution controls matter: the advisory specifically calls out the absence of code signing/execution controls as an enabling cause. Vendors building OT products should adopt strict code signing for update bundles and runtime execution policies to limit arbitrary code execution.
• Inventory and visibility are non‑negotiable: defenders can’t fix what they can’t find. Maintain accurate inventories tied to patch management systems and prioritize internet‑facing assets.
• Coordinate OT + IT teams: remediation and incident response must cross domain boundaries. Windows administrators, SOC teams, and OT operators need established, practiced channels for rapid patching and containment.

---

Conclusion​

CVE‑2025‑13658 in Industrial Video & Control’s Longwatch is a high‑severity, unauthenticated remote code‑execution vulnerability that demands immediate attention from operators and integrators. The vendor’s fix (Longwatch 6.335) is the definitive remediation; where immediate patching is not possible, strong network isolation, firewall blocks, WAF rules, and tighter remote access controls should be applied as stopgap defenses. Because Longwatch deployments sit at the intersection of security monitoring and process control, a compromise has outsized operational and safety implications — treat this advisory as urgent and execute the mitigation checklist with cross‑functional coordination between OT and Windows/IT teams. For maximum assurance, validate vendor update artifacts directly with IVC support, implement the compensating controls described here, and integrate new detection signatures into your SIEM and endpoint tooling while you patch.
(If vendor advisory pages, CVE registry entries, or public index listings are queried later, confirm current CVE/NVD/MITRE entries and vendor release notes before concluding an environment is fully remediated.

---

Source: CISA Industrial Video & Control Longwatch | CISA