Which versions of lynx-keeper are malicious?

The following npm versions of lynx-keeper are flagged malicious: 0.1.0, 0.1.1, 0.1.3. Treat any of these as compromised.

How do I remediate lynx-keeper if I installed it?

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

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

Yes — lynx-keeper is associated with the IN-MAL-2026-003557, IN-MAL-2026-004156, IN-MAL-2026-003535, GHSA-x7hr-g7qr-7j7p 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 lynx-keeper 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 lynx-keeper (3 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging lynx-keeper across your stack and pipelines.

Malicious package

lynx-keepernpm

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

MAL-2026-4603

Immediate action

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

npm uninstall lynx-keeper

What this malware does

On require, dist/index.js executes a hex-obfuscated harvester that reads ~/.aws/credentials, ~/.aws/config, ~/.ssh/id_rsa, ~/.ssh/id_ed25519, ~/.ssh/config, gcloud application_default_credentials.json, ~/.kube/config, and.env/.env.local/.env.production from the current working directory, plus all process.env keys matching /KEY|SECRET|TOKEN|PRIVATE|MNEMONIC|PASSWORD|CREDENTIAL/i. The collected data is AES-128-GCM encrypted with a hardcoded key and POSTed to https://72.62.71.201/api/v2/collect with TLS verification disabled (rejectUnauthorized:false). The IP is stored as a decimal-charcode array and decoded at runtime; sensitive strings ('aes-128-gcm', 'child_process', '.aws/credentials', '.ssh/id_rsa', '/api/v2/collect', '/api/v2/beacon', the credential-targeting regex) are all hex-encoded and decoded via a Buffer.from(...,'hex') helper. After the initial exfil the module enters a polling loop that POSTs to https://72.62.71.201/api/v2/beacon every ~45-90 seconds, decrypts the AES-128-GCM response, and runs each returned command through child_process.execSync with windowsHide:true, returning stdout to the same C2 — a full remote-command backdoor. Persistence is established by writing a standalone copy of the beacon to ~/.npm/_npx/.cache/gyp-rebuid/index.js with a fake package.json naming it 'gyp-rebuild' (typosquatting node-gyp), so the backdoor survives uninstall and remains reachable via npx. Before any network activity the payload checks for CI/GITHUB_ACTIONS/GITLAB_CI/JENKINS_URL/CIRCLECI/TRAVIS/CODEBUILD_BUILD_ID/TF_BUILD/VERCEL/NETLIFY and silently returns if any are set, evading automated scanning environments while firing on developer workstations. The package's advertised purpose (utilities for lynx.finance keeper bots that handle KEEPER_PRIVATE_KEY) targets DeFi keeper operators whose env/.env files contain hot-wallet private keys.

Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Malicious versions

3 flagged

0.1.00.1.10.1.3

Indicators of compromise (SHA-256)

b1ceea5d6444b83f20cee4bbd8b4217e258473b2e55e105647ee444f5848db17

c475517e8036d792ed20ed340623f801b16d90e0ed9fb81ebb22b900cdb9fc65

dc28f02ae68bf5a1a57af8662180d7a8a040e6f32ad87abde9acdae508070189

61dc11fdce13daf749040523637a1de2db93542468e33b38072fb99c310949fc

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

Campaign

IN-MAL-2026-003557IN-MAL-2026-004156IN-MAL-2026-003535GHSA-x7hr-g7qr-7j7p

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks lynx-keeper-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