Critical Unauthenticated API Flaw in Honeywell CCTV (CVE-2026-1670)

A high-severity vulnerability disclosed by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) on February 17, 2026 exposes an unauthenticated API on multiple Honeywell CCTV product families that can be abused to change the “forgot password” recovery email address — an action that can immediately enable account takeover and unauthorized access to live camera feeds. CISA assigned the issue a critical CVSS v3.1 score of 9.8 and named the weakness as Missing Authentication for a Critical Function (CWE‑306), warning that an unauthenticated attacker with network reachability to affected devices could change recovery contact information and then reset credentials, leading to persistent administrative access.

Background / Overview​

Honeywell supplies a broad portfolio of IP cameras, PTZ units, and enterprise CCTV systems used across commercial facilities, government sites, and enterprise networks worldwide. Many of these devices are integrated into on‑premises video management systems (VMS), network video recorders (NVRs), building management systems, and cloud broker services. The product families named in the advisory — including variants in the HI/Impact/Performance lines and NDAA‑compliant models — demonstrate the vendor’s deep presence in medium and large deployments. That breadth makes any unauthenticated management‑plane flaw particularly consequential for Windows‑based security operations, integrators, and managed service providers.
CISA’s advisory identifies the reported issue as CVE‑2026‑1670 and lists specific affected firmware/build identifiers (for example: I‑HIB2PI‑UL 2MP IP: 6.1.22.1216 and several WDR_2MP_32M_PTZ_v2.0 variants). The advisory also reproduces standard ICS/OT defensive recommendations — isolate camera/control networks, minimize public Internet exposure, and use hardened remote access mechanisms — reflecting how device exposure drives exploitability in this class of bug.

---

What exactly is the vulnerability?​

The core technical weakness​

At its heart this is a missing authentication vulnerability: an API endpoint intended for account‑recovery or administrative use accepts requests that change an account’s recovery contact (the email address used by “forgot password” flows) without validating the caller. Because password‑recovery flows typically allow an attacker to obtain a reset token or set a new password when the recovery contact is controlled by the attacker, changing the recovery email effectively hands the attacker a way to bypass normal credential checks.
This is a classic CWE‑306 scenario: a critical function (account recovery / credential reset) performs a state‑changing operation but lacks the necessary access control checks. That makes the endpoint trivially scriptable and highly attractive to automated scanners and botnets.

Why changing the recovery email matters​

Changing the recovery email is more than an inconvenience: it is an immediate path to account takeover. Attack flow in realistic deployments typically looks like this:

• Attacker discovers the camera or management interface by scanning IP ranges or using device fingerprinting.
• Attacker issues an unauthenticated request to the exposed endpoint to replace the account’s recovery email with an address under the attacker’s control.
• Attacker triggers the “forgot password” flow to receive a reset link or code at that attacker‑controlled email.
• Attacker resets the account password and logs into the device’s web UI, ONVIF services, and API with administrative privileges.
• From that foothold, the attacker can exfiltrate live video (RTSP/ONVIF), change NVR/VMS credentials, create persistent accounts, or pivot into management networks.

Because many NVRs and VMS installations store camera credentials centrally (and sometimes reuse them), a single camera takeover can cascade into broader surveillance compromise. This is precisely the reason CISA rates this class of issue as high‑impact despite the simplicity of the bug.

---

Affected products and scope​

CISA’s advisory enumerates specific affected models and firmware strings. Administrators should assume that any device in the named families running the listed builds is vulnerable until the vendor provides a confirmed patch. The advisory called out (among others):

• Honeywell I‑HIB2PI‑UL 2MP IP — firmware/build 6.1.22.1216 (CVE‑2026‑1670).
• Several WDR_2MP_32M_PTZ_v2.0 family firmware images covering SMB NDAA MVO‑3, PTZ WDR 2MP 32M, and 25M IPC variants (CVE‑2026‑1670).

Because vendor product naming conventions and firmware channels are sometimes opaque, operators must cross‑check device model/part numbers and reported firmware strings against their asset inventory rather than rely on marketing names alone. If you manage cameras across multiple sites, treat the scope conservatively: any camera matching the same firmware family and build pattern should be considered for immediate mitigations.

---

Threat model and practical impact​

Immediate confidentiality and integrity risks​

• Live stream theft: An attacker who gains admin access can consume RTSP/ONVIF streams and record video, violating privacy and operational confidentiality.
• Persistence: Attackers can create additional administrative accounts or modify firmware update sources, creating durable access.
• Supply‑chain and network pivoting: With admin privileges, an attacker may extract NVR credentials or API tokens stored on the device and use them to compromise central recording infrastructure or cloud sync services.
• Physical security bypass: Attackers can modify PTZ presets, alarm thresholds, or recording schedules to blind cameras at targeted times, facilitating theft or sabotage.

Operational and compliance consequences​

Enterprise and public‑sector camera fleets are often subject to regulatory or contractual security obligations. A breach that exposes surveillance feeds or that allows an attacker to manipulate logs and recordings can have legal, regulatory, and reputation costs far exceeding the price of a firmware update.

Exploitability and weaponization​

A missing‑authentication endpoint that performs a single state change (recovery email) but does not require authentication scores highly in exploitability because:

• Attack complexity is low (no credentials or special timing).
• The vulnerability is remote (network accessible).
• No user interaction is required.
• Vulnerable units may be discovered by automated scanners and exploited en masse.

That means rapid weaponization is plausible — especially if devices are Internet‑facing or poorly segmented. History of similar camera and encoder advisories shows quick development of mass‑scan tools and automated exploit scripts once the family and fingerprints are public.

---

Verification: what we could confirm​

• CISA published an advisory on February 17, 2026 that lists CVE‑2026‑1670 and describes an unauthenticated API endpoint allowing recovery email changes; the advisory assigns a CVSS v3.1 base score of 9.8. The advisory names specific Honeywell camera/firmware variants as affected.
• Honeywell’s commercial CCTV product lines (Impact/HI/60/50 series and NDAA‑compliant models) are widely deployed in commercial and enterprise settings; vendor documentation confirms remote configuration and web/HTTP management channels are standard on these devices, explaining the attack surface. Operators should therefore assume real exposure where devices are reachable from management networks or the Internet.
• At the time of the advisory’s initial release, CISA reported no known public exploitation specifically tied to CVE‑2026‑1670; nonetheless, CISA’s standard mitigations (isolate devices, minimize public exposure, and use secure remote access) were recommended immediately. This “no known exploitation” status can change rapidly and should not be taken as a comfort for exposed deployments.

Note: Some indexing sources (MITRE/NVD) may lag for newly minted CVEs; researchers and operators should prioritize the vendor and CISA advisory content for urgent mitigation rather than waiting for canonical indexing to catch up.

---

Recommended, prioritized actions for administrators and integrators​

Below is an operational action list tailored for Windows teams managing NVRs, VMS instances, and camera fleets. These are prioritized by impact and speed of implementation.

Immediate (0–24 hours)​

• Inventory and identify: Build or update an inventory of all Honeywell cameras, including model, firmware version, and whether they are Internet‑facing. Prioritize devices matching the affected firmware strings cited in the advisory.
• Block external access: Ensure cameras and camera management ports are not reachable from the public Internet. Use perimeter firewalls or cloud ACLs to block HTTP/HTTPS/RTSP/ONVIF management ports from untrusted networks.
• Isolate and segment: Move camera management traffic onto an isolated VLAN/subnet with strict firewall rules and allow management only from known admin hosts or jump‑boxes.
• Disable remote recovery methods where possible: If the camera/WebUI allows toggling of email‑based recovery or remote account recovery, disable it until a patch is applied. If you cannot toggle it, place compensating network controls around the device.
• Change shared credentials: Immediately rotate any shared default or weak credentials used by cameras in NVRs or VMS configurations — but do so carefully to avoid disrupting operations. Document changes and rollback steps.

Short term (1–7 days)​

• Monitor for suspicious changes: Review device management logs for events that change account email/recovery fields, create accounts, or execute password resets. Alert on any such events. If logs are not centrally ingested, enable or export them.
• Harden admin access: Require MFA on supporting cloud accounts or NVR/VMS admin portals; restrict local UI access to administrative jump servers.
• Apply network allowlists: Where possible, limit which management hosts can reach camera admin ports (source IP allowlisting).
• Check NVR and VMS credentials: Verify that the camera credentials stored in NVRs and VMS are not easily removable or exposed; rotate those credentials and update VMS configs securely.

Medium term (7–30 days)​

• Coordinate with Honeywell: Follow vendor guidance and apply any available patches as soon as they’re released. If no patch is published, ask Honeywell for mitigation guidance and timelines through official support channels.
• Patch management: Integrate camera firmware into your patch management lifecycle. Test firmware updates in a lab before broad deployment to avoid service disruption.
• Threat hunting: Search network traffic, Windows event logs on management hosts, and VMS logs for evidence of exploit attempts, unusual account resets, or access from unexpected IPs.

Incident response (if compromise suspected)​

• Isolate the device: Immediately isolate suspected compromised cameras from the network and preserve logs and forensic evidence.
• Reset accounts and credentials: Reset local admin passwords and recovery contacts from a trusted management host after taking the device offline for analysis.
• Forensically capture: Export device logs, configuration files, and NVR/VMS logs for forensic review.
• Notify stakeholders: Inform legal, privacy, and executive stakeholders as dictated by policy; consider reporting to CISA and law enforcement if the breach impacts critical operations.

CISA’s canonical guidance — minimize network exposure, isolate control systems, and prefer hardened remote access such as properly configured VPNs — remains applicable and should be followed while vendor patches are pending.

---

Detection guidance and practical hunt queries​

Because the advisory does not (and often will not) publish exploit code or exact API URIs, defenders should approach detection in two layers: network artifacts and device management logs.

• Network layer: look for unusual HTTP(S) POST/PUT requests to camera management endpoints originating from untrusted sources, or sudden outbound SMTP/SMTP‑relay activity (used to confirm recovery emails). Watch for repeated password‑recovery flows for the same account in a short time window.
• Device/UI layer: look for events that update account recovery email, account creation, or password resets. If devices do not produce detailed logs, enable debug/logging temporarily and forward logs to your SIEM for correlation.
• Windows/NVR layer: query VMS and NVR logs for “failed login” spikes followed by successful admin logins from unusual IPs, or sudden changes in camera credentials stored in the recorder.

Sample investigation checklist:

• Search Windows event logs and VMS log exports for “password reset”, “recovery email”, “account changes”.
• Query firewall logs for HTTP(S) access to the camera management subnet from the Internet.
• Use simple HTTP probes from a controlled host to verify whether management endpoints require authentication (be careful: avoid actions that change device state).

Caveat: the exact endpoint names and request payloads are vendor specific and may not be publicly released; any detection rules that rely on a specific URI should be validated in lab before deployment and flagged as potential indicators. If you lack telemetry, prioritize network segmentation and access controls.

---

Vendor and ecosystem responsibilities​

• Honeywell: the vendor should publish an authoritative security bulletin with confirmed affected builds, mitigation steps, and firmware fixes. The CISA advisory explicitly directed customers to contact Honeywell support for patch information; customers should use only official Honeywell support channels and firmware packages to avoid counterfeit or malicious updates.
• NVR/VMS vendors and integrators: these vendors should treat camera credentials in recorders as sensitive assets. Default behavior of storing plaintext or reversible credentials in management systems increases blast radius and should be remediated.
• System integrators and managed service providers: must communicate immediately with customers who operate affected devices, assist with inventorying, and implement compensating controls while patches are tested and rolled out.

---

Strengths in the advisory and gaps to watch​

Notable strengths​

• CISA’s advisory provides an early, centralized alert that enables asset owners to prioritize mitigation actions quickly.
• The advisory uses standard CWE/CVSS semantics that help security teams triage risk against other active threats.
• The guidance reiterates well‑established ICS/OT mitigations that are directly actionable for network teams.

Gaps and caveats​

• Vendor patch availability: initial advisories sometimes publish before a vendor has released an immediate patch. Until Honeywell publishes a firmware fix, operators must rely on network mitigations — an imperfect but necessary stopgap. Operators should verify vendor bulletins and avoid installing firmware from unverified third‑party sources.
• Indexing lag: canonical databases (MITRE, NVD) can lag on newly issued CVEs; do not wait for those indexes when an authoritative government advisory is available.
• Detection specificity: because the advisory does not publish the exact API request shape, many detection rules will be approximate and may produce false positives or negatives unless validated in a lab environment.

When communicating to business stakeholders, emphasize that the risk here is both immediate and operational: a single vulnerable camera exposed to an untrusted network can be a low‑cost entry vector with outsized consequences.

---

Final checklist — what to do right now​

• Assume exposure if any affected Honeywell firmware is present.
• Immediately block camera management ports from Internet access.
• Place cameras and management consoles on isolated VLANs with strict ACLs.
• Rotate and strengthen credentials stored in NVRs and VMS.
• Enable and centralize logging for cameras and recorders; hunt for account recovery changes.
• Contact Honeywell support for patch timelines and follow the vendor’s remediation guidance through official channels.
• If you detect suspicious events, preserve logs and follow your incident response playbook.

CISA’s advisory and the initial CVE assignment elevate this issue to a top‑tier operational priority for organizations that operate Honeywell CCTV devices. Even absent public exploitation reports, the combination of an unauthenticated endpoint and a built‑in password‑recovery mechanism is an attractive target and must be treated urgently by security and IT operations teams.

---

Conclusion​

This advisory is a reminder that physical security devices live on networks and inherit all the threats that come with network connectivity. A seemingly small oversight — an unauthenticated API that updates the password recovery email — becomes a severe operational risk when that function ties directly into account recovery and credential reset flows. Owners and operators of Honeywell CCTV equipment should act now: inventory devices, block management access from untrusted networks, harden and rotate credentials, centralize logging, and coordinate with Honeywell for patching. These steps will materially reduce the window of exposure while the vendor and the broader security community work to deliver tested firmware updates and longer‑term fixes.

---

Source: CISA Honeywell CCTV Products | CISA