A coordinated advisory published for the Zenitel TCIV-3+ intercom — attributed to Claroty Team82 researchers Nir Tepper and Noam Moshe and distributed via government channels — warns of multiple
critical, remotely exploitable vulnerabilities including several OS command‑injection flaws, an out‑of‑bounds write (crash) and a reflected cross‑site scripting (XSS) flaw; the vendor’s recommended remediation is to upgrade affected devices to firmware Version
9.3.3.0 or later, and operators should treat these findings as high‑priority for immediate triage and mitigation.
Background / Overview
The TCIV‑3+ is Zenitel’s IP/SIP video intercom designed for door‑entry, access control and public‑facing communications in buildings and industrial sites. The device supports HD video, RTSP/ONVIF streaming and integrates with Zenitel’s management platforms and SIP environments. Its deployment profile — often on perimeter walls, building entrances and in distributed sites — makes any remote code execution or denial‑of‑service vulnerability especially serious because affected units may be reachable from less‑trusted networks or traverse enterprise‑OT boundaries. The advisory being analyzed explains five distinct CVE assignments covering three OS command injection variants (each scored at the top of severity scales), one out‑of‑bounds write (crash/DoS) and one reflected XSS. According to the advisory, the command‑injection CVEs carry maximum CVSS severity strings under a CVSS v4 recalculation and are exploitable remotely without authentication, placing them in the highest risk class for internet‑facing devices.
These findings were disclosed to coordinated government channels and published as part of an ICS/OT advisory, consistent with past coordinated disclosures for critical industrial devices; the researchers credited in the advisory are members of Claroty’s Team82, a recognized ICS/OT research group with a track record of high‑impact vulnerability disclosures.
What the advisory says (concise technical summary)
- Affected product: Zenitel TCIV‑3+ — all versions prior to 9.3.3.0 (vendor and advisory text recommend upgrading to 9.3.3.0 or later).
- Vulnerability types and impact:
- Multiple OS command injection vulnerabilities (unauthenticated, remote) — CVE‑2025‑64126, CVE‑2025‑64127, CVE‑2025‑64128. Each is reported with an extremely high severity rating (CVSS v3 ≈ 9.8 / CVSS v4 = 10.0 in the advisory), meaning successful exploitation could yield full system command execution and device compromise.
- An out‑of‑bounds write allowing remote crashing of the device — CVE‑2025‑64129 (CVSS v3 ≈ 7.6; CVSS v4 ≈ 7.0).
- A reflected cross‑site scripting (XSS) vulnerability allowing JavaScript execution in a victim’s browser — CVE‑2025‑64130 (CVSS v3 ≈ 9.8; CVSS v4 ≈ 9.3).
- Risk summary: Successful exploitation could permit arbitrary command execution, persistent access/backdoors, lateral movement into management networks, or cause Denial‑of‑Service to the device and services that depend on it.
- Reporter: Nir Tepper and Noam Moshe of Claroty Team82 are listed as the researchers who reported the issues.
- Vendor mitigation: Zenitel recommends upgrading to version 9.3.3.0 or later. The advisory also repeats standard ICS mitigation guidance: minimize Internet exposure, segment and firewall control networks, and use secure remote access methods when required. This mirrors the standard CISA guidance used for ICS advisories.
Why this matters — exposure and operational impact
Many TCIV‑3+ installations are physically exposed and installed for direct public interaction (door intercoms, access control panels, site entryways). A remote, pre‑auth command injection on these devices is consequential for several reasons:
- Pre-auth remote RCE is a high‑value capability for attackers. An unauthenticated attacker with a network path to a vulnerable TCIV‑3+ can run arbitrary OS commands and potentially install persistent tooling or pivot into back‑end systems.
- Perimeter placement + weak segmentation = lateral movement risk. Devices installed at building perimeters commonly interact with lodging HMI systems, visitor management platforms and sometimes enterprise networks. A compromised device can be a foothold into internal systems.
- Operational safety and reputation risk. If intercoms are used in safety or access control, attackers could deny service (lock out personnel, block audio/video) or perform deceptive access manipulations.
- Scale and automation. The reported low attack complexity and lack of required privileges make script‑based scanning and mass exploitation realistic if proof‑of‑concept code or exploit modules appear in the wild.
This advisory therefore elevates priorities for both OT teams that manage intercoms and IT teams responsible for network perimeter and jump hosts.
Technical analysis — what appears to be root cause and exploitation model
The advisory breaks the failures down into classic web/embedded device weaknesses:
- Command injection variants: all three command injection CVEs are described as arising from insufficient input validation/sanitization where user‑supplied parameters are incorporated directly into shell or OS command invocations. This pattern typically maps to CWE‑78 (improper neutralization of special elements used in an OS command). Depending on the input sink, attackers can append command separators, backticks or parameter expansions to run arbitrary commands.
- Out‑of‑bounds write: indicates a memory safety issue in a parsing/processing routine that allows writing beyond intended buffers, producing crashes and potentially enabling code‑execution in lower‑hardened environments. This is often a CWE‑787 class problem.
- Reflected XSS: insufficient encoding of user‑controlled data within HTML/javascript content served by the device’s web UI, enabling script execution in browsers of users who visit crafted URLs.
Exploit preconditions reported by the advisory (and typical for these classes of flaws):
- Network reachability to the vulnerable endpoint (HTTP/HTTPS/web UI or other exposed management APIs).
- For the command‑injection and XSS issues the advisory states no authentication is required (pre‑auth). For the OOB write the exploit vector is likewise network‑accessible.
- Attackers benefit from automated discovery — internet scanning tools can enumerate exposed endpoints and attempt automated payloads.
Note: several of the advisory’s scoring statements and CVE identifiers are high severity; however, independent public databases (NVD/MITRE) should be checked by defenders for canonical CVE entries and updates. At the time of preparing this article, general CISA vulnerability bulletins and Claroty Team82 research pages corroborate the seriousness and research provenance, but direct NVD enrichment for these specific CVE numbers could not be located via public trackers; organizations should confirm CVE/NVD entries and vendor release notes before concluding exact scoring thresholds.
Immediate mitigation checklist (what defenders must do first)
Apply the following prioritized actions in the order shown. These are practical, short‑term measures to reduce risk while planning permanent remediation.
- Upgrade firmware:
- Verify device inventory and firmware versions of all TCIV‑3+ units.
- If any unit is running a version earlier than 9.3.3.0, schedule an immediate upgrade to 9.3.3.0 or later using vendor‑supplied release notes and signed firmware. (Do not install unofficial builds.
- Block external access:
- Ensure TCIV‑3+ management interfaces and ports are not directly reachable from the Internet. Block and monitor all Internet‑facing management ports at perimeter firewalls and NGFWs.
- Network segmentation:
- Move intercom devices onto an isolated VLAN or OT management network with strict firewall rules and allow‑lists for only required management hosts and NMS/HMI systems.
- Harden remote access:
- Replace direct remote access with secure, monitored jump hosts or VPNs employing multi‑factor authentication (MFA) and endpoint posture checks. Treat VPNs as compensating controls and keep them up to date.
- Monitor and detect:
- Deploy IDS/IPS rules and web‑application monitoring to detect suspicious command injection payload patterns, unusual process launches on devices or repeated malformed requests to the web UI.
- Log and forward device logs to a central SIEM; enable alerting for unexpected reboots, new user creation events or firmware‑related anomalies.
- Temporary workarounds (if patching is delayed):
- Disable or restrict the vulnerable web management interface if the device permits.
- Apply application‑layer filtering (WAF) for HTTP-based management endpoints to strip or reject suspicious payload characters where feasible.
- Containment policy:
- If a device is suspected of compromise, isolate it from the network, capture memory/flash dumps if feasible, preserve logs, and perform forensic triage before restoring from known‑good firmware.
These steps align with the defensive posture advocated in coordinated ICS advisories and authoritative guidance for industrial systems.
Detection and investigation — practical guidance for Windows/IT teams
- Inventory and discovery:
- Use network scans and asset‑management tools to produce a definitive list of TCIV‑3+ endpoints and their firmware versions.
- Inspect firewall logs and VPN session logs for any unusual traffic to device management ports from unexpected hosts.
- Look for exploitation indicators:
- Unexpected shells, processes, or scheduled tasks on devices; unusual HTTP POSTs containing shell metacharacters; sudden reboots or crashes (OOB write symptom).
- Browser‑based alerts or reports of injected scripts (for XSS) from helpdesk or user reports.
- Forensic capture:
- Preserve network captures (PCAP) around suspected exploitation windows.
- Export device configuration and system logs (securely) before applying upgrades or reimaging.
- Windows host hygiene:
- Ensure engineering workstations and jump hosts that communicate with TCIV‑3+ devices are hardened: patched OS, up‑to‑date EDR, MFA on remote access, remove unnecessary admin credentials from stored profiles.
Vendor and industry responsibilities — what Zenitel (and integrators) should do
- Publish clear, signed firmware release notes and changelogs that map CVEs to fixed builds and provide SHA256 or other integrity checks for firmware images.
- Provide detection signatures: example suspicious request patterns and recommended IDS/IPS rules for common SIEM vendors.
- Supply temporary configuration workarounds (e.g., disable web UI, require local admin only, configuration options to restrict interfaces) for customers that cannot patch immediately.
- Conduct a secure code review and supply a root cause statement explaining how user input reached shell invocations without sanitization, and what hardening steps were taken in the 9.3.3.0 code base.
- Coordinate with national CERTs and maintain an easily accessible security advisories section (the vendor library is a step in that direction but some technical documents require login). Operators should validate release notes and download artifacts directly from vendor portals.
Critical analysis — strengths, gaps and potential risks
Strengths worth noting
- The advisory flags a highly actionable, high‑impact class of vulnerabilities (pre‑auth command injection) which elevates the urgency for defenders and drives immediate mitigations.
- Researchers credited (Team82) have a reputable disclosure history, which adds confidence in the technical quality of the findings.
- Vendor remediation guidance is clear and immediate: a recommended firmware upgrade (9.3.3.0 or later) provides a specific operational action to close the issue.
Gaps and limitations to be mindful of
- At the time of preparing this article, canonical CVE/NVD entries for each CVE number listed in the advisory were not broadly searchable in public NVD mirrors; defenders should treat the published advisory as authoritative but verify CVE records and NVD enrichment for automated vulnerability management systems. If NVD/CVE records remain unavailable, integrate vendor advisory identifiers directly into vulnerability systems. This is a cautious call to validate the metadata in your ticketing/scan systems.
- The advisory does not always list precise exploit proof‑of‑concepts (PoCs) or exact vulnerable API endpoints in public text; while this is responsible for coordinated disclosure, it complicates rapid local detection without vendor‑supplied indicators.
- Some ICS advisories over time show differences in scoring between CVSS v3 and recalculated CVSS v4 vectors; defenders should not rely solely on the numeric score to prioritize — rather, use the exploitation conditions (pre‑auth remote RCE) and exposure to drive urgency.
Potential risk scenarios
- Mass scanning and automated exploitation against internet‑facing TCIV‑3+ devices could result in rapid compromise waves similar to past IoT/OT incidents.
- Compromised devices used as staging points to attack engineering jump hosts or to harvest credentials for remote management platforms.
- Supply chain and integration vendors that embed TCIV‑3+ into larger managed services could be affected if customer fleets are not patched rapidly.
Recommended 30/60/90‑day action plan (operational playbook)
- 0–7 days (Contain & Triage)
- Complete an inventory of all TCIV‑3+ devices and firmware versions.
- Block all public access to management interfaces; isolate devices into a management VLAN.
- Schedule immediate firmware upgrades for internet‑exposed or high‑risk devices.
- 7–30 days (Remediate & Harden)
- Apply vendor firmware 9.3.3.0 or later to all affected devices; validate in a test environment first.
- Implement stricter allow‑lists for device management and enforce least privilege on jump hosts.
- Deploy detection signatures and log aggregation for web UI endpoints and unusual process activity.
- 30–90 days (Validate & Normalize)
- Conduct penetration testing or red‑team validation to confirm that RCE and OOB vectors are closed.
- Update asset and patching inventories to include TCIV‑3+ devices in regular maintenance cycles.
- Require vendors/integrators to provide firmware update automation or managed‑service options to keep fleets current.
Final assessment and guidance for decision makers
The advisory for the Zenitel TCIV‑3+ identifies a set of vulnerabilities that, taken together, represent a substantial operational and security risk:
unauthenticated remote command injection and related memory corruption/XSS issues are the sort of findings that enable full device takeover and network pivoting. The immediate, vendor‑recommended upgrade to firmware 9.3.3.0 should be treated as
high priority for any organization running TCIV‑3+ devices, especially where those units are reachable from non‑trusted networks or are part of a larger OT/IT attack surface.
At the same time, defenders must validate advisory metadata (CVE assignments, NVD entries, vendor release notes) within their operational tooling and not rely solely on numeric CVSS scores for prioritization. Where automated enrichment is missing, use vendor KBs and the advisory text itself to create triage tasks and deploy the mitigations listed above.
Claroty Team82’s involvement gives weight to the technical reporting, and industry standard mitigations (segmentation, minimal Internet exposure, patched VPNs and jump hosts) remain the backstop while devices are updated. Treat this advisory as a reminder that perimeter‑facing special‑purpose devices require the same disciplined patching and segmentation posture as any other enterprise asset.
Zenitel customers, integrators and managed‑service providers should immediately:
- Verify TCIV‑3+ firmware versions in inventory.
- Apply the 9.3.3.0 update where available and follow vendor rollback/testing procedures.
- Harden network controls, reduce exposure to untrusted networks and monitor for indicators of compromise.
For clarity: the advisory text and CVE identifiers referenced in this feature are published in a coordinated ICS advisory and attributed to the named researchers. Defenders should confirm the advisory and download firmware only from official Zenitel distribution channels and validate the integrity of any update packages before deployment.
(End of article)
Source: CISA
Zenitel TCIV-3+ | CISA