Which versions of permit2 are malicious?

The following npm versions of permit2 are flagged malicious: 1.0.0, 1.0.1. Treat any of these as compromised.

How do I remediate permit2 if I installed it?

permit2 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 permit2 — how do I know if it already compromised me?

If permit2 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 permit2 part of a known attack campaign?

Yes — permit2 is associated with the IN-MAL-2026-017433, IN-MAL-2026-017442 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 permit2 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 permit2 (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging permit2 across your stack and pipelines.

Malicious package

permit2npm

permit2 is a confirmed malicious npm package (MAL-2026-13775) that steals credentials and exfiltrates sensitive data (malicious versions 1.0.0, 1.0.1). Do not install it — remove it immediately and rotate any exposed credentials.

Malicious code in permit2 (npm)

MAL-2026-13775

Immediate action

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

npm uninstall permit2

What this malware does

permit2 is a malicious npm package that squats the bare name of Uniswap's Permit2 token-approval system (whose legitimate npm distribution is the scoped @uniswap/permit2-sdk), advertising itself as a "smart contract development toolkit." The package contains no real functionality — the published tarball ships only a package.json and an install-time payload (index.js), which both preinstall and postinstall execute via node index.js, so it runs automatically on npm install.

The payload is a more aggressive variant of the infostealer used across the mssjeep843 DeFi-impersonation campaign and exfiltrates to the same webhook.site endpoint. It collects environment variables whose names match a broadened secret pattern (KEY|TOKEN|SECRET|PASS|PRIVATE|MNEMONIC|RPC|AWS|GITHUB|NPM|KUBE|VAULT|AUTH|PGP|GPG|SEED|WALLET|BEARER|API|INFURA|ALCHEMY|HELIUS|QUICKNODE|ANKR|PRIVATE_KEY) and, rather than merely listing credential directories, reads and exfiltrates the full contents (up to 4000 bytes each) of a wide set of credential and key files: ~/.aws/credentials and ~/.aws/config, SSH private keys (~/.ssh/id_rsa, ~/.ssh/id_ed25519) and ~/.ssh/config, ~/.kube/config, ~/.docker/config.json, ~/.netrc, ~/.pgpass, ~/.npmrc, ~/.pypirc, ~/.gitconfig, ~/.git-credentials, GCP application-default and legacy credentials, Solana/Anchor keypairs (id.json), NEAR credentials, the Sui keystore, up to three Foundry keystore files, and .env/.env.local/.env.production/.env.development/secrets.env from the current working directory. It also captures the hostname, username, cwd and platform. The JSON is POSTed over HTTPS to https://webhook.site/326b0891-2093-4800-a4c1-686ce3e07b09, with errors swallowed so the install never visibly fails. Any host that installed this package should treat SSH keys, cloud credentials, wallet keystores and .env secrets as compromised and rotate them.

The npm package 'permit2' (a name-squat of Uniswap's Permit2) ships an index.js that is registered as both preinstall and postinstall in package.json. On install, index.js enumerates environment variables matching KEY/TOKEN/SECRET/PRIVATE/MNEMONIC/AWS/GITHUB/NPM and reads installer-owned credential files including ~/.aws/credentials, ~/.ssh/id_*, ~/.npmrc, ~/.kube, ~/.docker, ~/.netrc, ~/.gitconfig, gcloud/solana/sui/anchor credentials, foundry keystores, and local.env files. The collected data is POSTed via https.request to a hardcoded attacker endpoint at webhook.site (path /326b0891-2093-4800-a4c1-686ce3e07b09). The upload is deferred 60-240 seconds inside a detached child process (spawn with detached:true, stdio:'ignore') to outlive install/scanner windows, and the script early-exits if os.hostname()/user matches sandbox patterns (scan-, detonation, sandbox, ubuntu-fc-uvm) or if the npm registry points at a mirror. The package ships no functionality matching its self-description as a 'smart contract development toolkit'.

Malicious versions

2 flagged

1.0.01.0.1

Indicators of compromise (SHA-256)

51baca54ac515b4ff006cc3c6b99645d5f38f8c0250a294b8abe75c9d3172f2b

57057e349a16d1c1de4619f660e9de63c638d6a9ea8915915424e98e8dcf6e64

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 permit2 (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging permit2 across your stack and pipelines.
If you installed it — respond
permit2 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 permit2 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 permit2 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. permit2 on npm has been identified as a malicious package (versions 1.0.0, 1.0.1 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-017433IN-MAL-2026-017442

References

Credits

Amazon Inspector · finder
SafeDep · finder

Detect & block this

O3 blocks permit2-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

Explore

All malware advisories How O3 detects malware Vulnerability database