Home > Security and Compliance Blog > Cybersecurity Risk Management > OpenAI Codex Authentication Tokens Stolen in npm Supply Chain Attack

OpenAI Codex Authentication Tokens Stolen in npm Supply Chain Attack

by Patrick Spencer updated June 5, 2026 Cybersecurity Risk Management

Reading Time: 6 minutes

Supply chain risk has traditionally focused on software dependencies that introduce vulnerabilities into compiled products — the type of compromise represented by SolarWinds and XZ Utils. The Codex token theft is a different model. The compromised package does not introduce a vulnerability into the developer’s code. It extracts credentials from the developer’s environment while they work.

The attack lifecycle follows a predictable pattern: a functional package is published and gains downloads through normal channels; the package is maintained and updated, building a commit history that signals legitimacy; credential-harvesting code is added at some point; and because the package functions correctly, developers do not look closely. The exfiltration runs silently for weeks or months before detection.

Table of Contents

The quality of the disguise in the Codex case is instructive. Stolen credentials went to a server endpoint mimicking a Sentry error reporting integration — a service that receives telemetry from developer tools routinely. Network monitoring that flags outbound connections to unknown domains would not flag a connection to what appears to be Sentry. The attacker anticipated and defeated the most common detection mechanism for outbound data exfiltration.

Vendor risk management programs assessing software vendor security posture need to extend their scope to include the package ecosystems those vendors operate within. An npm package is a vendor relationship with no procurement process attached to it.

5 Key Takeaways

1. A functional npm package silently stole Codex OAuth tokens for one month.

“codexui-android” — with ~29,000 weekly downloads — harvested OpenAI Codex authentication tokens from local storage and shipped complete OAuth credential bundles to an attacker-controlled server disguised as a Sentry endpoint. The same exfiltration logic appeared in two Android apps totalling 60,000+ downloads. The package performed its advertised function while the credential harvesting ran in the background — giving developers no behavioral signal that anything was wrong. Supply chain pre-publish scans do not catch this pattern.

2. Refresh tokens do not expire — making this theft uniquely persistent.

The stolen ~/.codex/auth.json file contained refresh tokens, not just access tokens. An attacker holding a refresh token can silently impersonate the victim indefinitely, generating new access tokens as needed without triggering any re-authentication challenge. Most victims of credential theft do not know a theft occurred and therefore do not revoke anything — making continuous contextual verification more durable than token expiry as a control.

3. Plaintext credential storage is a systemic risk across developer toolchains.

Any package a developer installs has potential access to every credential stored in the home directory. The same pattern appears across cloud provider CLIs, version control systems, container registries, and AI service providers — all commonly storing credentials in plaintext local files. Vendor risk management frameworks built for SaaS vendors need an equivalent framework for open-source package dependencies.

4. Stolen AI developer credentials can reach enterprise data systems well beyond the workstation.

Codex tokens grant access to whatever enterprise systems the developer has connected — file sharing environments, MFT pipelines, content repositories, and internal APIs. An attacker operating with valid developer credentials can interact with these systems through AI-mediated workflows that appear entirely normal to audit logging systems watching for anomalous human behavior.

5. Zero-trust access enforcement limits consequences even when credentials are stolen.

Policy conditions attached to sensitive data — not just the identity of the credential — determine whether access is granted. Zero-trust data protection means a stolen token presented from an unexpected location, at an unusual time, requesting data outside normal scope, can fail policy evaluation even though the token itself is technically valid. The Kiteworks Secure MCP Server creates the chokepoint that attacker-controlled tokens cannot bypass.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

Why Plaintext Credential Storage Is a Systemic Risk

The ~/.codex/auth.json file stores OAuth credentials in plaintext because that is the path of least resistance for developer tooling. Developers need their tools to authenticate without friction. Credential files on the local filesystem, readable by any process the developer runs, solve that problem efficiently — while also creating a single point of failure: any process with filesystem read access can harvest everything needed to impersonate the account.

This is not a problem unique to Codex. The same pattern appears across developer toolchains — cloud provider CLIs, version control systems, container registries, and AI service providers all commonly store credentials in plaintext local files. Security teams focused on network-level access controls and perimeter defenses often overlook this local credential surface entirely.

Any package a developer installs has potential access to every credential stored in the home directory. Third-party risk management frameworks designed for SaaS vendors and cloud providers need an equivalent framework for open-source package dependencies. Credentials at rest should receive the same treatment as sensitive data at rest: encryption with keys stored separately from the encrypted material.

How Stolen AI Credentials Become Enterprise Data Breaches

The Codex token theft is not just an account compromise — it is the first step in a chain that can end with enterprise data exfiltration. A developer installs a malicious package; the package harvests Codex credentials; the attacker uses those credentials to access whatever enterprise systems the developer’s account can reach; the attacker then extracts sensitive content through channels that look indistinguishable from the developer’s legitimate activity.

The enterprise data systems most at risk are those that AI tools increasingly connect to: document repositories, secure file sharing platforms, virtual data rooms, and managed file transfer pipelines. These systems hold contracts, financial data, intellectual property, and regulated personal information. An attacker operating with a developer’s Codex credentials can interact with these systems through AI-mediated workflows that appear entirely normal to audit logging systems watching for anomalous human behavior.

Kiteworks interrupts this chain at the data access layer. The Secure MCP Server controls which AI tools can interact with enterprise data at all — if a tool’s identity or policy context does not match the permitted set, it cannot reach the data regardless of the credentials it presents. ABAC enforcement goes further: evaluating not just who is asking but what attributes describe the request, the data, and the operating context. A stolen token presented from an unexpected geographic location, at an unusual time, requesting data outside the developer’s normal scope, can fail policy evaluation even though the token itself is valid.

Responding to AI Toolchain Supply Chain Compromises

When a credential theft event of this type occurs, response runs on two parallel tracks: containing the immediate exposure and building controls that prevent recurrence. Immediate containment requires revoking all potentially compromised tokens — any developer who installed the affected package during the exposure window should treat their auth.json credentials as compromised. Token revocation is a manual action in most OAuth implementations, and organizations without an inventory of which developers hold which service credentials will struggle to execute it comprehensively.

An incident response plan covering AI toolchain compromise should include automated detection of credential file access by unauthorized processes, token revocation procedures with enterprise-wide scope, and a review of which enterprise systems developer AI tool credentials can reach. Audit logs capturing AI-mediated data access are essential for determining what an attacker actually accessed during the exposure window — the evidence baseline that determines whether regulated data was involved.

To learn more about protecting your sensitive data from AI supply chain attacks, schedule a custom demo today.

Frequently Asked Questions

The attacker routed stolen credentials through an endpoint mimicking a Sentry error reporting integration — traffic most network monitoring would not flag. The package also functioned correctly, giving developers no behavioral signal. Pre-publish registry scans check for known malicious signatures but do not perform behavioral simulation that would reveal credential access at runtime. Supply chain risk management controls need to include runtime behavioral analysis of installed packages, not just signature checks at installation.

Access tokens expire after minutes or hours. Refresh tokens generate new access tokens indefinitely until explicitly revoked — and most victims do not know a theft occurred and therefore never revoke them. Zero-trust principles address this through continuous contextual verification: flagging tokens used in anomalous contexts even when technically valid. Kiteworks’ ABAC enforcement applies this contextual evaluation to every data access request, independent of token validity.

Yes. OAuth credentials should live in platform-managed keystores — macOS system keychain, Windows Credential Manager, or a hardware security module for enterprise deployments — not in plaintext JSON files in the home directory. Platform keystores require explicit user authentication before releasing credentials, making silent background access by a malicious package significantly harder. Organizations should also periodically audit which developer tools can access enterprise system credentials as part of their vendor risk management program.

It depends on what enterprise systems those credentials can reach. If they authorize access to document repositories, secure file sharing platforms, or MFT pipelines, an attacker can interact with those systems through AI-mediated workflows. Regulated data — HIPAA-protected PHI, GDPR-covered personal data, CUI under CMMC — becomes directly exposed. Treat compromised AI tool credentials with the same urgency as compromised privileged user credentials.

Kiteworks enforces access policy at the data layer, not just at authentication. The Secure MCP Server controls which AI tools are authorized to interact with enterprise data — an unrecognized tool identity cannot reach protected content regardless of credentials presented. The AI Data Gateway and ABAC enforcement evaluate the full request context — identity, tool, data classification, environment, and behavioral patterns — so a stolen token used in anomalous context fails policy evaluation even if not yet revoked. Every interaction produces a tamper-evident audit trail.

Additional Resources