Skip to content
All posts

'zomato' npm dependency-confusion campaign

cyrokai's scanners flagged a same-day cluster of malicious npm packages published under the zomato- prefix, all at version 1.0.0. They are a Dependency Confusion attack: the names impersonate Zomato's private, internal package names so a misconfigured build pulls the attacker's public package instead.

Each package carries its payload inline in package.json as a preinstall hook (no dropped file). On install it runs hostname, whoami, pwd, and env | base64 and exfiltrates the result, including your entire environment (any CI, build, or shell secrets and tokens), to an out-of-band collaborator at hxxp[://]d8s0b82plbq3u5sb2vo0sb3a9obr4yjt7[.]oast[.]site (an Interactsh/OAST endpoint). A preuninstall hook beacons the hostname too. Because the package name is embedded in each payload, every tarball hash differs; the shared indicator is the C2 domain.

PackageVersionAttack type
zomato-mcp1.0.0Dependency Confusion
zomato-espresso1.0.0Dependency Confusion
zomato-core1.0.0Dependency Confusion
zomato-server1.0.0Dependency Confusion
zomato-sushi1.0.0Dependency Confusion
zomato-config1.0.0Dependency Confusion
zomato-logger1.0.0Dependency Confusion
If any of these reached an install on a build agent or developer machine, treat it as a secret-exposure incident: rotate every credential, token, and key that was present in that environment, since the full environment was exfiltrated. Block the C2 domain, and close the dependency-confusion gap by claiming or scoping your internal package names and pinning your registry so internal names never resolve to public npm.
Back to the blog