John Z Black

John Z Black Mar 15, 2026 Threat Intelligence #supply-chain #developer-security #vs-code #appsflyer #malware #sdk-security

The old supply-chain attack model assumed someone made a bad call. Installed a sketchy package, clicked a phishing link, grabbed code from a shady repo. Somebody did something wrong.

That’s not how it works anymore. This week proved it twice.

GlassWorm is abusing the Open VSX registry’s dependency features. You install a perfectly clean extension. That extension declares a dependency on another extension. The second one is the payload. Seventy-two extensions were involved. The developer never chose the malicious code. Never saw it listed. Just installed something they wanted and the rest came along for the ride.

That’s a real shift. Previous extension marketplace attacks required the malicious extension to be the one you actually installed. You could vet the listing, check the publisher. With transitive dependency abuse, none of that helps. The thing you’re evaluating is clean. The poison’s in the plumbing.

So far this looks limited to Open VSX, the independent registry used by VS Codium and Eclipse Theia. But if it crosses into Microsoft’s VS Code Marketplace, the scale explodes. Don’t assume you’re clear without checking.

Then there’s AppsFlyer. One of the most widely deployed mobile analytics platforms in the world. For a window between March 9 and 11, their Web SDK was serving malicious JavaScript designed to steal cryptocurrency. Their domain registrar got compromised. Any site loading the SDK during that window was potentially serving crypto-stealing code to visitors.

Same pattern as GlassWorm. The site owners didn’t write the malicious code. Didn’t install it. They’d been loading the AppsFlyer SDK for months or years. The attack worked because the trust was real. AppsFlyer is legitimate. The SDK is legitimate. The compromise was behind the scenes.

Both attacks bypass the point where traditional security advice applies. “Don’t install unknown software” doesn’t help when malicious code arrives through a dependency you never reviewed. “Use trusted vendors” doesn’t help when the trusted vendor’s own library gets hijacked.

For developers: audit your VS Code extensions and their declared dependencies. Check whether those deps are things you’d have consciously installed. For teams with third-party SDKs: version-pin your loads. Use Subresource Integrity. Stop loading scripts dynamically from vendor CDNs without verifying what you’re actually getting.

The software you chose is not the only software you’re running. Start treating those invisible trust relationships as part of your threat model.

Read the full post on gNerdSEC