June 3, 2026
The codexui-android Supply Chain Attack Is a Textbook Case for Runtime Application Security
Why correlating vulnerability data with live observability catches what scanners structurally cannot
Girish Sivasubramanian
3 min read
This week's disclosure of the codexui-android npm supply chain attack should make every engineering leader pause. Not because supply chain attacks are new — but because of how this one stayed invisible.
Here's the recap of what Aikido Security uncovered: a legitimate-looking remote web UI for OpenAI Codex, pulling more than 29,000 weekly downloads, quietly began exfiltrating Codex authentication tokens roughly a month after it was published. The malicious code read ~/.codex/auth.json — containing the access_token, refresh_token, and id_token — and shipped the full OAuth blob to sentry.anyclaw.store, a domain deliberately named to impersonate Sentry, the well-known application monitoring platform.
The GitHub repository stayed clean. The npm build was the poisoned one. And because the stolen refresh token doesn't expire, the result is persistent, silent account takeover — an attacker can impersonate you indefinitely.
Why static analysis never stood a chance
It's worth being precise about why our usual defenses missed this, because the answer reframes how we should think about supply chain risk.
The repository was clean, so source review found nothing. The package had a real development history and built genuine user trust before turning malicious — the exfiltration code was introduced about a month after publication, a deliberate trust-building delay. Version pinning was absent, so devices simply pulled whatever npm currently served. And the exfil endpoint was a brand-new domain, registered just two days after the package's first release, dressed up to look like a trusted monitoring vendor.
Every one of those design choices was aimed at defeating left-shift defenses: SCA tools, manifest locking, source scanning, artifact signing. All necessary. None of them would have stopped this attack, because the malicious behavior wasn't in the source — it lived at runtime, inside a trusted package, after trust was already established.
This is the new shape of supply chain risk. And it lives exactly where runtime application security plus observability is built to operate.
Where detection actually happens
The attack wasn't silent in every sense. It generated telemetry — it had to, in order to exfiltrate anything. The question is whether anyone was positioned to see it. Walk through the signals:
1. Anomalous outbound connection. The exfil endpoint, sentry.anyclaw.store, was a freshly-registered domain masquerading as a trusted vendor. Observability data on egress — destination domains, connection frequency, payload volume — surfaces a process suddenly talking to an unknown host that looks like Sentry but isn't actually in your known service map. The impersonation was a bet that no one was watching the runtime closely enough to tell the difference.
2. Sensitive file access at runtime. A web UI process reading ~/.codex/auth.json is not normal behavior. Runtime instrumentation that watches for access to credential stores and secrets files turns this into a high-fidelity signal — entirely independent of whether the package was ever flagged as vulnerable.
3. Behavioral drift after an update. "Every single invocation has been quietly exfiltrating tokens." That's a baseline change you can detect: a dependency that behaved one way for weeks and started making new outbound calls after a version bump.
4. Correlating vulnerability and observability data — the real unlock. A vulnerability signal on its own ("this package version is known-malicious") is reactive; it depends on someone having already caught and catalogued the threat. But when you correlate vulnerability intelligence with live observability — what the process is actually doing, what it's connecting to, what it's reading — you shift from "was this flagged?" to "is this behaving badly right now?" That correlation is where an unexplained outbound connection to a look-alike domain stops being noise and becomes the thread you pull.
The core thesis is straightforward: runtime application security and observability shouldn't be separate disciplines living in separate tools. When your vulnerability data and your observability data sit in the same place and talk to each other, the picture changes. You're no longer asking your SCA tool whether a package declared something dangerous. You're watching what your applications actually do in production — the egress, the file access, the behavioral drift — and correlating that runtime reality against vulnerability and threat intelligence in real time.
In a scenario like codexui-android, that correlation is the difference between finding out from a security blog a month later and catching a trusted dependency the moment it starts reading credentials and phoning home to a domain that has no business being there.
The takeaway for engineering leaders
We spent the last decade getting genuinely good at shifting left — and we should keep doing all of it. But left-shift and runtime observability are complementary, not interchangeable. Locking your manifests and signing your artifacts does nothing about a trusted package that turns on you after the fact.
The attackers in this case understood the gap better than many defenders do. They named their exfiltration endpoint after a monitoring platform specifically because they were betting nobody was watching the runtime closely enough to notice.
So the question worth bringing to your team this week is simple: if a trusted dependency in your stack started reading credentials and phoning home tomorrow, would you see it — or would you find out from a blog post a month later?
The answer depends entirely on whether your vulnerability data and your observability data are looking at the same thing, at the same time.