Apifox CDN Supply Chain Attack: Malicious JavaScript Hidden in the Official Analytics Script

Commissioned, Curated and Published by Russ. Researched and written with AI.

On March 26, 2026, SlowMist reported a supply chain attack against the Apifox desktop client. Attackers had injected heavily obfuscated malicious JavaScript into an official Apifox CDN script: cdn.apifox.com/www/assets/js/apifox-app-event-tracking.min.js. The file was disguised as a legitimate analytics tracker. Every Electron-based Apifox desktop client that loaded it – automatically, on startup, without any user action – ran attacker-controlled code.

The outcome: credential theft and full remote code execution on affected machines.

What Apifox Is

Apifox is an API development and testing platform, roughly analogous to Postman. It’s widely used, particularly across Asia and Chinese development teams. The desktop client is built on Electron, which means it runs web technologies in a privileged Node.js context – and automatically fetches and executes CDN-hosted scripts as part of normal startup.

That architecture is the lever the attackers pulled.

How the Attack Worked

The malicious code was appended after the legitimate analytics logic in the CDN file, inheriting its whitelist trust. The tampered version is preserved via Web Archive at the March 5 snapshot. SlowMist’s SHA256 for the malicious file: 91d48ee33a92acef02d8c8153d1de7e7fe8ffa0f3b6e5cebfcb80b3eeebc94f1.

The obfuscation was layered:

• The JavaScript was processed with javascript-obfuscator
• All strings were RC4-encrypted and stored in a large array, then decrypted dynamically at runtime
• Numeric constants – time intervals, chunk sizes – were expressed through multi-step calculations to defeat static analysis
• C2 communications were RSA-encrypted (256-byte chunking), preventing traffic analysis

The malware operated on a randomized timer: periodic beaconing to a C2 server at apifox.it.com. Each beacon exfiltrated login tokens and system information, and retrieved updated payloads. Stolen credentials were held in localStorage under the keys _rl_headers and _rl_mc.

The full chain: script loads on startup, obfuscated payload runs silently, credentials exfiltrated, arbitrary remote code fetched and executed. All without any user interaction.

The Attack Window

According to an independent Chinese-language technical analysis, the attack was active from approximately March 4 to March 22. If accurate, that’s 18 days of the malicious CDN file serving from Apifox’s official infrastructure before detection. I haven’t been able to verify this window independently against the SlowMist report, so treat it as a reported figure rather than confirmed.

Why This Matters for Dev Teams

Apifox sits in developer workflows the same way Postman does: it holds API keys, auth tokens, session credentials. It often runs authenticated against internal staging and production APIs. If your team uses Apifox desktop – especially in the last few weeks – those credentials may have been exfiltrated.

The broader point is the attack vector: a legitimate CDN-hosted analytics file. Not a dependency you’d audit. Not a package version you’d pin. A JavaScript file your tooling fetched silently as part of normal startup, from the vendor’s own CDN.

SRI (Subresource Integrity) hashes would have caught this – but almost no Electron apps implement SRI on their own CDN assets. There’s no standard mechanism forcing desktop clients to verify the integrity of remote scripts before executing them. That gap is the attack surface.

Immediate Actions

If your team uses the Apifox desktop client:

1. Revoke all API tokens and check for abnormal API call records
2. Log out of Apifox to forcibly invalidate current session tokens
3. Change the Apifox account password and audit login history
4. Block apifox.it.com and all subdomains at the network level
5. Clear Apifox client localStorage – run this in the app’s developer console: localStorage.removeItem('_rl_headers');localStorage.removeItem('_rl_mc');

The C2 domain apifox.it.com should be in your DNS blocklists now regardless.

No CVE has been assigned yet. English-language coverage is thin. SlowMist’s full writeup is the authoritative technical reference.

The lesson isn’t new, but it keeps needing to be repeated: trusted tools loading remote scripts is a supply chain risk. The fact that it’s your own vendor’s CDN doesn’t make it safe.