Topic starter
20/08/2026 6:01 pm
TL;DR: Published npm builds of codexui-android contained code absent from the GitHub source tree that read local Codex auth files and exfiltrated token objects to an attacker endpoint, according to Corgea’s analysis. The issue turns a seemingly legitimate developer tool into a supply-chain credential theft path, and it shows why artifact-level verification matters more than repository trust alone.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “codexui-android npm package exfiltrates Codex OAuth tokens on startup”.
Key questions
Q: What breaks when an npm package can read local AI auth files at startup?
A: The boundary between application startup and credential theft disappears.
Q: Why are refresh tokens riskier than access tokens after compromise?
A: Access tokens are usually short-lived, so their damage window is limited.
Q: What are the signs that a developer package is exfiltrating secrets quietly?
A: Watch for startup-time reads of local credential files, outbound requests to unexpected telemetry-style domains, and error handlers that suppress network failures.
Practitioner guidance
- Verify installable artifacts before trust decisions Compare the published npm tarball against the reviewed source tree, and block packages whose artifact contents differ from the repository or expected build output.
- Protect Codex auth files as secrets Treat ~/.codex/auth.json and $CODEX_HOME/auth.json as credential material, with file permissions, endpoint restrictions, and host-level secret scanning in place.
- Invalidate sessions after any exposure signal Revoke Codex and OpenAI sessions from a known-clean machine, then recreate local auth state and review workspace activity for reuse of stolen tokens.
Bottom line: Published developer packages can become credential theft channels when the installable artifact diverges from the reviewed source.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:39 pm
Artifact trust, not repository trust, is now the control boundary. Developer teams often review source code while implicitly trusting the registry package that users actually install. This case shows that gap clearly: a clean-looking repository can coexist with a malicious published artifact. The practitioner conclusion is that provenance, hashing, and artifact verification have to sit in the release path, not outside it.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: How should teams respond when a developer toolchain compromise is discovered?
A: Contain the workstation, revoke any exposed tokens, review repository and package publishing activity, and rebuild trust in the affected developer accounts before restoring normal access. Because the compromise can propagate through source control and package ecosystems, response must include identity containment, not just endpoint cleanup.
👉 Read our full editorial: Malicious npm builds of codexui-android steal Codex tokens