Malicious npm and PyPI Packages Impersonate Aerodrome Finance and Ethereum Vault Connector to Steal Developer Credentials

Say you're building a lending app on Base and you need a vault primitive. You search npm for 'ethereum vault connector,' the exact name of a real, audited piece of DeFi infrastructure from Euler Finance. A package called ethereum-vault-connector shows up. It's MIT licensed. Its description reads like real docs. The name is exactly what you typed. You install it. In the background, before your code ever runs, it reads your .npmrc, your .gitconfig, your SSH keys, and your Foundry and Hardhat config folders. Then it sends all of it to a webhook.site URL.

That's the attack ChainRadar caught on August 11, 2026. Eight packages across npm and PyPI, each named after a real DeFi protocol or a plausible-sounding crypto infra term, all running an identical credential-stealing install hook. This isn't spray-and-pray malware naming. It's targeted brand impersonation, aimed at developers who are already integrating with the protocols being spoofed. That's exactly the audience least likely to question the package name.

Why these specific names were chosen

Aerodrome Finance is not obscure. It's the top DEX on Base, built by the Velodrome team. It handles over 60% of all DEX trading volume on that network. It's also a proven attack target already. In November 2025, attackers hijacked Aerodrome and Velodrome's DNS. An insider at their domain registrar helped them do it. Users got redirected to a fake copy of the real site. Aerodrome and Velodrome's own report puts the damage at about $700,000, the amount users signed away on the phishing pages before the attack was stopped. That incident had nothing to do with npm. But it shows attackers already see Aerodrome as worth faking. Developers who build on it are a known, valuable target.

Ethereum Vault Connector (EVC) is the other anchor name. It's a real, open-source tool built by Euler Finance. It lets ERC-4626 and other vaults on Ethereum use each other as collateral. Lending protocols, stablecoins, and margin trading apps are all built on top of it. Its own site says it has been through two security reviews, four audits, and formal verification, with named partners including yAudit, Certora, and Trail of Bits. A developer building vault infrastructure who searches 'ethereum vault connector' would expect to find the real thing. They'd find the malicious package instead.

One template, eight packages, one C2

All six npm packages were published at version 1.0.0. All are MIT licensed. Each has a description written to sound like real docs, things like 'Aerodrome Slipstream AMM contracts and ABIs' or 'Boring Vault contracts.' Every one carries the same preinstall and postinstall script: node index.js || true. That isn't six independent authors landing on the same idea. That's one build template, stamped onto eight package.json files, published in a single burst.

"scripts": {
  "preinstall": "node index.js || true",
  "postinstall": "node index.js || true"
}

The strongest clue isn't the naming pattern. It's the command-and-control endpoint. O3 Security's disclosure to the OSSF malicious-packages database confirms all eight packages send stolen data to the exact same webhook.site URL, plus the same pair of callback IPs. Identical infrastructure across eight unrelated-sounding names, on two different package registries, doesn't happen by accident.

Why webhook.site as C2 is the smart part

webhook.site is a real service. Developers use it every day to inspect HTTP requests while debugging. That's exactly why it works as C2. A domain-reputation or allowlist tool has no reason to block it. It isn't a bulletproof host or a fresh lookalike domain. It's a well-known SaaS tool with a long, clean history. The malicious traffic doesn't look like malware traffic. It looks like a developer testing a webhook.

• Domain-reputation filters see a trusted, long-established domain and let the request through.
• SIEM rules that allowlist common developer SaaS tools (webhook testers, logging endpoints, CI callback URLs) miss it by design.
• The unique path (the UUID after webhook.site/) is what actually routes stolen data to the attacker, and that part is invisible to anything that only inspects the domain.

A separate cluster: @telekom-ods/react-ui-kit

The same sweep also caught @telekom-ods/react-ui-kit at version 2.6.9. The name is a near-match for Deutsche Telekom's real npm scope, @telekom, home of the company's Scale design system. But the behavior is different in every way that matters. This package doesn't read .npmrc or post to webhook.site. It reads /etc/passwd and /etc/shadow instead: the local user list and, on a misconfigured or root-running system, the hashed password file. It then sends the results out through an OAST (out-of-band application security testing) callback domain.

Here's how an OAST domain works: it encodes a unique subdomain per victim. Any DNS lookup or HTTP hit against that subdomain confirms the code ran, even with no direct network access allowed. DNS resolution alone can leak the confirmation. Reading /etc/shadow needs elevated privileges to actually pull hashes on a properly locked-down system. That suggests one of two things. Either this payload is opportunistic, aimed at misconfigured CI runners and containers that run as root, or it just tries the read regardless, to see what comes back.

Attribution: unattributed

We checked this against known campaign families: Shai-Hulud, Miasma, TeamPCP, and others. No match. The install-hook mechanism here is a plain preinstall/postinstall npm script, not a .pth injection or a worm-style spreading step. The shared webhook.site C2 and the DeFi-brand namesquat pattern don't line up with any campaign we could verify against a primary source. So we're not naming this cluster. If you've seen IOC or infrastructure overlap with a tracked campaign, we'd want to know.

Detection and response

If any of the listed packages appear in a lockfile, package.json, or requirements.txt, treat the machine as compromised. The preinstall/postinstall hook runs automatically on npm install, before you'd ever import or run the package's code.

# npm projects: search lockfiles and node_modules for the malicious names
grep -RE '"(ethereum-vault-connector|@aerodrome-finance/contracts|@aerodrome-finance/slipstream|boring-vault|camelot-ammv2-core|camelot-ammv2-periphery|@telekom-ods/react-ui-kit)"' package.json package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

# PyPI projects: check installed packages and requirements files
pip freeze | grep -E '^(dlmm|dlmm-sdk)=='
grep -E '^(dlmm|dlmm-sdk)' requirements*.txt 2>/dev/null

# Confirm exact malicious version if a match is found
npm ls ethereum-vault-connector boring-vault camelot-ammv2-core camelot-ammv2-periphery 2>/dev/null
npm ls @aerodrome-finance/contracts @aerodrome-finance/slipstream @telekom-ods/react-ui-kit 2>/dev/null

1. Run the grep/pip commands above across every repo and CI cache on machines used for DeFi/Web3 or Telekom-adjacent frontend development.
2. If a match is found, rotate everything readable from .npmrc: npm/registry auth tokens, and any org-scoped publish tokens tied to that machine's identity.
3. Rotate git-linked credentials referenced in .gitconfig, including any stored credential helper tokens.
4. Rotate SSH keys that were present in ~/.ssh at the time of install, and revoke the corresponding public keys from GitHub, GitLab, and any servers that trusted them.
5. Rotate Foundry, Hardhat, and gcloud credentials/config if those directories exist on the affected machine, since the payload specifically enumerates them.
6. For @telekom-ods/react-ui-kit, audit whether the process had root or elevated privileges (CI runner, container running as root) and, if so, treat any credentials or hashes in /etc/shadow as potentially exposed and rotate local account passwords.
7. Remove the malicious package version, pin dependencies going forward, and add the package names above to an internal denylist or private registry block.
8. Add an egress monitoring rule for outbound traffic to webhook.site immediately following an npm/pip install step in CI, since legitimate build steps rarely need it.

Why this evades most scanning stacks

None of the individual techniques here are exotic. What makes this cluster effective is that each layer of a typical AppSec stack has a specific, predictable reason to let it through.

This maps to MITRE ATT&CK T1195.002 (Compromise Software Supply Chain) for the distribution vector and T1552.001 (Unsecured Credentials: Credentials In Files) for the .npmrc/.gitconfig theft. If you're building detection rules off this report, alert on preinstall/postinstall scripts making outbound HTTP requests during CI dependency installs, not just on known-bad package names, since name-based rules will always trail the next namesquat by however long it takes someone to notice.