A security camera's login page is supposed to protect your home or office. It is not supposed to hand attackers the keys to your source code. Yet that is exactly what happened when a researcher discovered a live GitHub admin token embedded directly inside the frontend of a shipped consumer device. No reverse engineering required — just load the login page, read the source, own the repository.
This is not a theoretical supply chain risk. It shipped to real customers.
What Actually Happened
The device in question served its web-based login interface over the local network, as most IP cameras do. Inside the HTML or bundled JavaScript of that interface, a GitHub personal access token with administrative scope was sitting in plain text. Anyone on the same network — or anyone who had already accessed the device — could read it.
An admin-scoped GitHub token is close to the worst possible credential to leak. It can:
- Read and clone every private repository in the organisation
- Push malicious commits or overwrite protected branches
- Read Actions secrets, which often contain cloud credentials, API keys, and deployment certificates
- Enumerate internal tooling, CI/CD pipelines, and contributor identities
In practice, a single leaked token of this kind can pivot an attacker from a consumer gadget into an organisation's entire software supply chain.
How a Token Ends Up in a Login Page
The accidental path here is unfortunately common, especially in embedded and IoT firmware teams:
- Hardcoded during development. A developer authenticates against a private package registry or internal GitHub repository during a build step and hardcodes the token for convenience.
- Bundled into the frontend artifact. Build tooling — webpack, rollup, or a custom Makefile — bundles configuration files or environment variables directly into the distributed JavaScript without stripping sensitive values.
- Firmware ships without a secrets audit. Unlike a SaaS deployment that passes through a CI pipeline with secret-scanning gates, embedded firmware often goes straight from a build server to a factory flash process. The audit step never happened.
The result is a credential that was only ever meant to live on a developer's machine, now permanently burned into millions of firmware images worldwide.
The Right Secrets Management Posture
Whether you are shipping firmware, a mobile app, or a web service, the principles are the same.
Never commit credentials to source control
This sounds obvious because it is, but the failure mode here was not a bad git push — it was a build pipeline that treated a secret as a build artifact. Both failures share the same root cause: secrets were not separated from code from the very beginning.
Use environment variables, a secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager), or short-lived OIDC tokens wherever possible.
Scan before you ship
Several tools can catch secrets before they reach production:
- git-secrets / gitleaks — scan commits and history
- truffleHog — deep entropy analysis across branches
- GitHub Advanced Security / secret scanning — automatic alerts on push
For firmware teams, add a static scan of the final binary or bundled file as a mandatory gate before signing the image.
# Example: run trufflehog against a compiled firmware directory
trufflehog filesystem ./firmware-build-output/ \
--only-verified \
--fail
A non-zero exit code fails the build. Simple, effective, and takes minutes to set up.
Rotate immediately when leaks are confirmed
Tokens are not passwords — they can be rotated without user friction. The moment a leak is suspected, revoke the token, audit its usage logs in GitHub (Settings → Security log), and issue a new scoped token with the minimum permissions required. Do not wait for a formal incident review.
Apply least privilege to machine credentials
An admin-scoped token is almost never necessary for a build or packaging step. GitHub's fine-grained personal access tokens allow you to scope access to specific repositories and specific actions — read contents, write packages, trigger workflows — nothing more. If the leaked token had only read access to one internal package repository, the blast radius would have been a fraction of what it was.
What This Means for IoT and Embedded Teams Specifically
SaaS teams have had years of cloud-native tooling nudging them toward better secrets hygiene. Embedded and firmware teams are only beginning to catch up. A few structural shifts help:
- Treat firmware like a container image. Apply the same pre-deployment scanning you would run against a Docker image before pushing to a registry.
- Separate build credentials from runtime credentials. The token that pulls a private npm or pip package at build time should never appear in the final artifact. Use a build-time secret injection step that does not persist values into the output bundle.
- Include a SBOM and secrets audit in every firmware release checklist. A software bill of materials helps downstream customers and regulators, but it also forces your team to enumerate every dependency and credential used in the build — a natural moment to ask "does this belong in the binary?"
The Broader Supply Chain Implication
This incident is a reminder that supply chain risk does not only flow through compromised open-source packages. It also flows through the first-party devices and software that organisations trust by default. A camera on your corporate network with admin access to your GitHub organisation is a lateral movement vector, not just a privacy concern.
Security teams performing vendor risk assessments should now include firmware credential audits alongside the usual network and data-handling questions.
Source: Hacker News — https://hhh.hn/hanwha-github-token/
Why this matters for your project: If your team ships any compiled artifact — a mobile app, a firmware image, a desktop installer — your release pipeline needs a secrets-scanning gate before that artifact is signed and distributed. At Code!nk Technologies, secrets hygiene is a standard part of every CI/CD setup we build for clients, because the cost of adding a scanner is trivial compared to the cost of rotating credentials across a deployed install base of thousands of devices or users.
