CVE-2026-1670: The Recovery Email Nobody Was Guarding

A 9.8 on a discontinued CCTV camera, and the "source repository" turns out to hold no source at all — just a machine-readable advisory. This is a post about CWE-306, account takeover by way of an unauthenticated endpoint, and what you can and cannot learn when the flawed code lives in closed firmware.

The advisory in plain English

CVE-2026-1670 affects the Honeywell I-HIB2PI-UL (HIB2PI-family) IP CCTV camera. The defect: an unauthenticated API endpoint that lets a remote attacker change the "forgot password" recovery email address on the device. Flip the recovery address to one you control, trigger the password-reset flow, and you own the account — and with it, the camera feed.

CISA classifies it as CWE-306: Missing Authentication for Critical Function, scored CVSS v3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) — the figures I quote throughout. (The advisory also carries a CVSS v4.0 base score and vector, as 2026 CISA ICS advisories do; I'm reporting only the v3.1 metric here.) It was reported by Souvik Kandar, and the device has been discontinued since April 2025.

Here is the heart of it, quoted verbatim from the advisory JSON I read at csaf_files/OT/white/2026/icsa-26-048-04.json (sha256 5b020a31…ff5bf86):

"cwe": { "id": "CWE-306", "name": "Missing Authentication for Critical Function" },
"notes": [{
  "category": "summary",
  "text": "The affected product is vulnerable to an unauthenticated API endpoint
   exposure that may allow an attacker to remotely change the \"forgot password\"
   recovery email address."
}]

And the risk evaluation, from the document-level notes of the same file:

{ "category": "summary",
  "text": "Successful exploitation of this vulnerability could lead to account
   takeover and unauthorized access to camera feeds.",
  "title": "Risk evaluation" }

A confession about the "flawed function"

The brief handed me https://github.com/cisagov/CSAF.git and asked me to read the flawed code. So I cloned it (git clone --depth 80, 11,450 files) and went looking. What I found is worth stating plainly, because it's the most instructive part of the exercise:

This repository contains no product source code. It is the CISA CSAF repository — a collection of machine-readable security advisories in the OASIS Common Security Advisory Framework 2.0 JSON format. Its own README says so: "to provide machine-readable security advisories using the OASIS Common Security Advisory Framework (CSAF) Version 2.0 standard." The only executable code in the tree is a single Python utility:

tools/csaf2md/csaf2md.py
tools/csaf2md/lib/{rem_helper,product_helper,score_helper,...}.py

That's csaf2md — a converter that turns CSAF JSON into Markdown. It is not the camera. The actual vulnerable code lives in closed-source Honeywell camera firmware that is not, and never was, in this repo. So I cannot quote the offending handler, show you the missing if (!authenticated) return 401;, or point at a line number. Nobody can, from this repository. Honesty beats fiction: there is no flawed function to read here, only the flaw's description.

What I can do is read the advisory's own git history — and that history is genuinely useful.

What the git log actually shows

The advisory file has three commits in the cloned history:

7a52311 3/12/26                       (Update B)
3250da4 February 26 ICSA Publications (Update A)
f967748 Feb 17th Advisories           (Initial)

Diffing the latest (git show 7a52311 -- …/icsa-26-048-04.json) against its predecessor reveals how the advisory itself was "patched" — not the firmware, the paperwork. The hunk below is a paraphrased composite: in the actual JSON the product entries are removed from the product_tree while the summary line is added under document/tracking/revision_history — two separate subtrees, not a single contiguous diff:

-          "name": "Honeywell HDZ322DI: vers:all/*",
-          "name": "Honeywell HC20WZ2R25: vers:all/*",
+          "summary": "Update B - Affected products changed, added that
+                       product has been discontinued."

Initially the advisory swept in three Honeywell camera models (HDZ322DI, HC20WZ2R25, I-HIB2PI-UL). By Update B, the scope was narrowed to the single I-HIB2PI-UL, and the remediation text changed from a bare "contact support for patch information" to:

-"details": "Honeywell recommends users contact Honeywell customer support ...
+"details": "The affected product has been discontinued since April 2025.
+            Honeywell recommends users contact Honeywell customer service ..."

So the "fix" in the public record is a mitigation, not a code patch you can inspect: the product is end-of-life, and the official guidance is network isolation behind a firewall. For a camera whose attack surface is "an unauthenticated HTTP endpoint reachable from the network," that mitigation is doing all the heavy lifting.

Why CWE-306 keeps winning

You don't need the firmware to understand the bug class, because CWE-306 is depressingly stereotyped. The pattern goes like this: a device has some authenticated API for managing account settings — including the recovery email used by the password-reset flow. One endpoint in that surface, the one that writes the recovery address, never got wired into the authentication middleware. Maybe it predates the auth layer. Maybe it was a "device provisioning" call that was supposed to be reachable only during first-boot setup and someone forgot to gate it afterward. Maybe the auth check lived in the UI and the API was assumed unreachable. The result is the same: a function that controls account recovery answers to anyone who can send it a request.

The reason this rates a 9.8 rather than a mere "information disclosure" is the chaining. Changing a recovery email is, on its own, an integrity violation. But it's the first domino:

1. Attacker sets recovery email → attacker-controlled inbox.
2. Attacker triggers the legitimate "forgot password" flow.
3. Reset token lands in the attacker's inbox.
4. Attacker sets a new password — full account takeover.
5. Confidentiality (camera feeds), Integrity (settings), Availability (lock out the owner) all fall. Hence C:H/I:H/A:H.

The lesson is that the password-recovery subsystem is part of the authentication boundary, not an afterthought bolted on beside it. Every endpoint that can influence who receives a reset token must be at least as well-defended as the login itself. A camera that authenticates its video stream but leaves "change my recovery email" wide open hasn't built a wall — it's built a wall with a service door propped open around the side.

What I'd verify if I had the firmware

To be concrete about the limits of this analysis: with the actual binary I would pull the web/API service, enumerate route registrations, and look for the handler that writes the recovery-email field — then check whether the request ever passes through the session/token validation that the other account endpoints use. The CWE-306 tell is an asymmetry: a /api/account/* family where one sibling skips the middleware the others share. That's the dataflow a taint engine or even careful manual review would flag. None of that is possible from a JSON advisory, and I won't pretend otherwise.

The lesson

Three of them, actually:

• Auth is a property of the boundary, not the function. Recovery-email mutation is an authentication-critical operation. If your reset flow trusts an email address, the write path to that address inherits the full blast radius of account takeover.
• "Discontinued" is not "fixed." The public remediation here is end-of-life plus firewall isolation. For unmanaged IoT/OT cameras that frequently end up internet-exposed, that mitigation only works if someone actually enforces it.
• Know what repo you're reading. A CSAF advisory is a precise, machine-readable description of a flaw — and a genuinely good artifact. It is not the flaw's source code. Confusing the two is how confident fiction gets written. The advisory told me exactly what's wrong (CWE-306, unauthenticated recovery-email write); it could not, and did not, show me the line that's wrong.

References

• ICS Advisory (web): https://www.cisa.gov/news-events/ics-advisories/icsa-26-048-04
• CSAF JSON (the file analyzed here): https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-048-04.json
• CVE record: https://www.cve.org/CVERecord?id=CVE-2026-1670
• CWE-306, Missing Authentication for Critical Function: https://cwe.mitre.org/data/definitions/306.html
• Honeywell support / patch information: https://www.honeywell.com/us/en/contact/support