Supply chain alert: a seemingly reliable npm package steals Codex tokens and opens the door to persistent attacks

A new case of commitments in the software supply chain again shows a dangerous trend: attackers are no longer dependent on "filling" or typosquats packages to hide and, instead, are poisoning legitimate and functional projects that have already gained confidence among developers. In this particular incident, the npm codexui-android library - promoted as a remote interface for OpenAI Codex and with tens of thousands of weekly downloads - quietly introduced code that steals locally stored authentication tokens and sends them to a server controlled by the attacker.

What makes this campaign particularly serious is that the package was functional and had been actively developed before the exfiltration routines were added, a technique designed to build confidence and expand the range before activating the malicious component. In addition, the same exfiltration chain was observed in Android apps that run the package within an emulated userland using PRoot, which shows how vectors can be mixed between ecosystems: npm for developers and APKS for end users.

The main objective is Codex tokens, stored in flat text files like ~ / .codex / auth.json or in the credentials stores of the operating system. These files contain access _ token, refresh _ token, id _ token and the account identifier; and, according to researchers, the particular refresh _ token does not expire, allowing an attacker to maintain persistent and invisible access to the compromised account. Stealing a refresh _ token is equivalent to a master key that allows to operate on behalf of the victim until it is manually removed.

Beyond the immediate impact on the compromised Codex account, the consequences can be extensive: a privileged token can allow an attacker to exfilter data, manipulate projects, distribute additional malicious code or pivote to other assets in the organization. In corporate environments, this can become a gateway to repositories with secrets, CI / CD systems or cloud environments.

From a preventive and response point of view, there are concrete measures that any developer or team should implement right now. The first is to assume that the tokens stored on disk are equivalent to passwords and treat them as such: inspect and, if you have doubts, delete the file ~ / .codex / auth.json and revoke / regenerate the tokens from the supplier's console. If your organization centralizes identities, it forces the closure of active sessions and reemits credentials with shorter duration and reduced scope. Contact the service support concerned to notify and request revocation if you do not find direct options on the interface.

At the supply chain level, it is essential to harden how dependencies are consumed: set versions (pinning) and use integrity sums (package-lock, npm ci with integrity verification), automate unit analysis with tools such as security offers for third-party repositories and scanners, and restrict the installation of packages in critical environments. Organizations should require integrity and reproducibility tests when integrating external packages into production pipelines.

It is also essential to limit the attack surface through best practices in the management of credentials: to favour short-life tokens and minimum scopes, to activate multifactor authentication where possible, to avoid storing tokens in flat text and to deploy exfiltration detection controls in networks and endpoints. In CI / CD, block out unnecessary from runners and containers so that a malicious unit cannot communicate freely with external servers.

For mobile users, the recommendation is extreme: avoid installing apps that ask to run unverified Linux environments within the device and distrust apps with permissions or behaviors out of the ordinary. Official stores do not guarantee total absence of deception; monitor reviews, developer origin and app network activity if you are in risk environments.

The community and the suppliers also have a role. Repositories and records should improve the detection of malicious changes in active packages, applying controls that analyse differences between versions and monitor author-linked domains. Internal security teams should integrate the generation of SBOMs (bill of materials) and regular unit audits, and companies should enable suspicious domain blockages in their perimeters to mitigate known exfiltration channels.

Finally, monitoring and shared information are key: When you discover an intrusion, document the vector, the affected artifacts (package names, versions, hashes and exfiltration domains) and share that information with the community and with security platforms for coordinated action. Public resources such as the OWASP supply chain security project can guide defensive strategies: https: / / owasp.org / www-project-software-supply-chain /. To understand package risks and how to address them from the development ecosystem itself, software and security guides for platforms such as GitHub Security Lab offers practical tools and recommendations: https: / / securitylab.github.com /. If you detect packages that report exfiltration to services that pass through third parties (e.g. servers that mimic Sentry), see the official pages of the supplanted service to report abuse and obtain mitigation guidance; in the case of Sentry: https: / / sentry.io /.

This incident recalls that modern security is not just to protect your own code, but to control and verify each external component that introduces confidence in our flows. The practical and urgent recommendation is to review tokens and sessions, strengthen unit management and implement network and detection controls that identify exfiltration behaviors before a stolen token becomes a persistent commitment.