27,000-Download npm Package Silently Stole OpenAI Tokens

27,000-Download npm Package Silently Stole OpenAI Tokens

A malicious npm package called codexui-android spent an unknown period quietly stealing OpenAI authentication tokens from the developers who installed it. With roughly 27,000 weekly downloads, the package presented itself as a legitimate user interface for OpenAI's Codex model. Underneath that familiar exterior, it was running a covert credential harvesting operation that security researchers now classify as a textbook npm supply chain attack targeting OpenAI tokens at scale.

The discovery is another sharp reminder that package registries are not inherently safe, and that popularity alone is no indicator of trustworthiness.

How codexui-android Hid Token Theft Inside a Legitimate-Looking Package

The attack relied on a simple but effective deception: build something developers actually want to use, then add malicious logic that runs silently in the background. The codexui-android package offered a functional interface for OpenAI's Codex, which meant developers installed it, tested it, and kept it in their projects, often without ever questioning what the package was doing at the network layer.

This approach is known as a trojanized package attack. The malicious code was embedded within what appeared to be a useful tool, sidestepping the natural skepticism that an obviously non-functional or poorly built package would invite. The package exfiltrated OpenAI refresh tokens, the long-lived credentials that allow applications to request new access tokens without requiring a user to log in again.

The name codexui-android also followed a naming convention that implied legitimacy. It borrowed brand equity from OpenAI's Codex product while appending a platform-specific suffix that made it seem like a purpose-built mobile-adjacent tool. Developers searching npm for Codex-related tooling would have had no obvious reason to distrust it.

What Stolen OpenAI Refresh Tokens Actually Let Attackers Do

Refresh tokens are not just passwords. In many authentication systems, they are effectively master keys. When an attacker obtains a valid refresh token, they can generate new access tokens repeatedly, maintaining persistent access to an account even after the original session has ended or a password has been changed.

For OpenAI accounts, this access could translate to unauthorized use of paid API credits, access to stored prompts or fine-tuned model data, potential exposure of proprietary code passed through the API, and in organizational contexts, lateral access to team resources tied to the same account.

The risk compounds quickly in developer environments. Engineers frequently work with API keys and tokens that carry elevated permissions. A single compromised refresh token in a CI/CD pipeline or a shared development environment could give an attacker a persistent foothold that is difficult to detect and harder to fully remediate. This cascading effect mirrors what happened in the Dropbox Sign breach, where harvested credentials opened pathways into interconnected systems well beyond the initial point of compromise.

Why the npm Ecosystem Makes Supply Chain Attacks Easy to Scale

The npm registry hosts over two million packages. Publishing a new package requires minimal identity verification, and the registry's open nature is precisely what makes it so useful to the global development community. It is also what makes it a recurring target for supply chain attackers.

The codexui-android case demonstrates how attackers exploit the trust model that underpins open-source development. Developers generally assume that a package with substantial download numbers has survived some level of community scrutiny. That assumption is increasingly dangerous. Download counts can be artificially inflated, and real-world usage does not equal security review.

The broader npm supply chain attack problem is not new, but the targeting of AI tooling marks an evolution. As developers integrate large language model APIs into production systems, the tokens that authenticate those integrations become high-value targets. Attackers are clearly aware of this shift. Packages mimicking AI developer tools are an emerging category of threat that the security community is still working to counter at scale.

Defense-in-Depth for Developers: Credential Isolation, Network Segmentation, and Beyond

The codexui-android incident points to several concrete practices that can reduce exposure to this class of attack.

Credential isolation is the most immediate mitigation. API tokens and refresh tokens should be scoped as narrowly as possible, stored in secrets managers rather than environment variables or config files, and rotated regularly. If a token is stolen, limited scope means limited damage.

Dependency auditing should be a standard part of any development workflow. Tools like npm audit, along with third-party software composition analysis platforms, can flag packages with unusual behaviors or known vulnerabilities. Locking dependency versions in package-lock files and reviewing changes before accepting updates also reduces exposure to malicious version pushes.

Network egress monitoring can catch exfiltration attempts that audit tools miss. If a development environment or CI/CD pipeline is configured to alert on unexpected outbound connections, a package attempting to phone home with stolen tokens becomes detectable.

Principle of least privilege applies at every level. Development machines should not run with credentials that grant production-level access. CI/CD pipelines should use short-lived tokens generated at runtime rather than stored long-term secrets.

Finally, reviewing your own installed packages for anything touching authentication flows is a worthwhile exercise right now. The codexui-android incident is unlikely to be isolated. Audit what is in your node_modules, check what permissions your API tokens carry, and treat any package that touches credential storage with heightened scrutiny.

Supply chain attacks succeed because they exploit trust at scale. Rebuilding that security posture one dependency at a time, starting with the most sensitive credentials in your stack, is the most practical response available to individual developers today.