Which versions of wrld-dev are malicious?

The following npm versions of wrld-dev are flagged malicious: 1.0.0. Treat any of these as compromised.

How do I remediate wrld-dev if I installed it?

wrld-dev is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.

I already installed wrld-dev — how do I know if it already compromised me?

If wrld-dev was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.

Is wrld-dev part of a known attack campaign?

Yes — wrld-dev is associated with the IN-MAL-2026-004134 campaign. Packages in the same campaign often share infrastructure and payloads, so check whether any related packages are also in your dependency tree.

How do I find wrld-dev across my projects, lockfiles, and CI pipelines?

Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for wrld-dev (version 1.0.0). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging wrld-dev across your stack and pipelines.

Malicious package

wrld-devnpm

Malicious code in wrld-dev (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-4733

Immediate action

Remove the package, then rotate any secrets the build/runtime could reach.

npm uninstall wrld-dev

What this malware does

The package exposes a public authentication API (auth.user.login, auth.user.register, auth.user.get, auth.user.delete, plus an auth.system RPC surface) wired to a Supabase client constructed from AUTH_URL/AUTH_KEY values bundled in the package's own .env file. In SupaAuth/interface.js, createClient(supaAuth.url, supaAuth.key) is built from AUTH_URL=https://xyxkteprdjiyctrpbaym.supabase.co and a hardcoded JWT, with no parameterization on the public API to override the destination. Any consumer that integrates this package to authenticate its own users will transmit those end users' email and password to the author's Supabase tenant on every login/register call — the canonical silent-relay shape, where the package's advertised functionality unconditionally exfiltrates caller-supplied data to a fixed author-controlled endpoint. Compounding the impact, the published tarball also ships two Supabase JWTs in .env whose decoded payload is {"role":"service_role"} for projects xyxkteprdjiyctrpbaym and ylznhlroyioyxpasyahm. These are full DB-admin keys that bypass row-level security; anyone who installs the package can read them from the tarball and gain admin access (read/write/delete all tables, delete arbitrary auth users) to those Supabase projects. While the leaked admin keys are primarily author self-harm, in combination with the silent relay they mean any end-user credentials collected through integrators of this package land in a Supabase tenant whose admin key is publicly recoverable from the npm artifact.

Malicious versions

1 flagged

1.0.0

Indicators of compromise (SHA-256)

58965a325ad88c872b7c01668e4c08ca337b5fa022c15e626e23697d23fb594c

Detection & response playbook

Credential / info stealer

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for wrld-dev (version 1.0.0). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging wrld-dev across your stack and pipelines.
If you installed it — respond
wrld-dev is built to steal secrets, so assume every credential the build or runtime could read is compromised. Remove it from your project and lockfile, then rotate ALL exposed secrets — npm/registry tokens, cloud keys, CI/CD secrets, SSH keys, and any .env values — from a known-clean machine. Audit logs for unauthorized use of those credentials.
Did it already run?
If wrld-dev was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks wrld-dev before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.

Frequently asked questions

No. wrld-dev on npm has been identified as a malicious package (version 1.0.0 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-004134

References

npmjs.com

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks wrld-dev-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the credential exfiltration and severs the channel.

Malware detection Runtime egress monitoring