A Hanwha Vision security camera shipped a GitHub admin token in its login page

A security researcher who tore into a Hanwha Vision camera's firmware found a GitHub admin token sitting in the device's own web login page. Hanwha Vision is a South Korean vendor that ships IP cameras and video recorders to enterprises, retailers, and city-scale surveillance deployments. The token was visible only after the researcher decrypted the camera's inner filesystem, a process the vendor made possible by leaving a static, model-line-shared AES-256 key inside its own update utility.

The researcher's writeup on hhh.hn walks through the decryption step by step. The outer firmware blob contains a second, AES-256-CBC-encrypted archive called fwimage.tgz. The encryption sits on top of a scheme Matt Brown documented in 2023, when a simple HTW<model> passphrase was enough to unpack the archive. Hanwha swapped the passphrase for a real cipher and added a new layer around it, but the new key still lives in the updater binary, where it is recoverable.

The updater, called fwupgrader, hides the AES key with a one-byte XOR against a 256-entry static table. The IV lives in plaintext next to it. Both fragments are themselves XOR-scrambled before the program shells out to OpenSSL. The researcher used an LLM coding agent to reconstruct the command:

``

openssl enc -md sha256 -aes-256-cbc -d -K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT>

`

The recovered key, dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0, and the IV, 53f926801b81454a4f889c9a390db6e6, are now in the blog post. Anyone holding the affected firmware blob can decrypt the root filesystem, and the affected model line shares the key, so the same key works across the family.

Inside the rootfs the researcher found the GitHub admin token sitting in the files that build the camera's login page: a credential with full administrative scope over some external repository, embedded in the device's user-facing HTML. The researcher has not named the organization that owned the token, and the writeup does not claim Hanwha or the camera vendor owned it. Until an independent party either decrypts a second unit or the affected organization confirms the credential, the token's existence should be treated as a single researcher's untested claim. The researcher's broader point does not depend on which organization owned the token. A static, model-line-shared AES key plus a credential baked into the login page is the failure mode, not the specific repository.

XOR against a 256-byte table is not encryption. The same updater handles the key the same way on every unit, so the published key is not a per-device secret. It is a vendor-wide decryption key that the researcher's blog post has now published in full. In Hanwha's design, the layered fwimage.tgz was meant to add another round of the same class of obfuscation, rather than to move to per-device key wrapping, signed firmware, or a real rotation story.

Hanwha Vision is not new to this neighborhood. Nozomi Networks Labs published a five-finding writeup on Wisenet cameras in 2024, covering command injection, weak credential handling, and unauthenticated access paths across the line. NVD's CVE-2023-31994 records a separate Hanwha camera flaw of the same general class. The vendor maintains a public cybersecurity page and posts periodic vulnerability reports; a December 2025 PDF covers CVE-2025-52598, CVE-2025-52601, and CVE-2025-8075. The presence of a disclosure channel does not change what the static key means for any camera already in the field. If it can be decrypted, it has been decrypted.

Practitioners on the Hacker News thread that surfaced the post took the same line. Several described running cameras on isolated VLANs, stripping vendor firmware down to a known baseline, or replacing the camera OS with OpenIPC, an open-source camera firmware project. The shared assumption was that any internet-connected security camera is, in practice, a credentialed device with an uninspectable software stack.

A reader running a Hanwha Vision camera from the affected model line should assume the unit is inspectable by anyone with the blog post, which is everyone. Treat any credential that touched the device as compromised. Isolate the camera on a VLAN that does not route to identity infrastructure, replace the firmware with a community build such as OpenIPC, or take the device off the network. Watch the vendor advisory page for a firmware image that ships a per-device key and a signature the updater actually checks. Until that image exists, the layered fwimage.tgz` is a speed bump, not a fix.