Supply Chain Attacks in 2026: What Your Dependency Scanner Catches (and What It Doesn't)

In January 2026, attackers compromised the npm and PyPI accounts of dYdX — a major decentralized exchange — and published malicious versions of @dydxprotocol/v4-client-js and dydx-v4-client that silently exfiltrated cryptocurrency wallet credentials. No CVE existed for these packages because the vulnerability wasn't a bug. It was intentional malicious code, published through stolen maintainer credentials.

A traditional dependency scanner would not have flagged these packages at the time of compromise. That includes GeekWala. This is important to understand, and it's the reason this article exists.

What We'll Cover

• CVE vulnerabilities vs supply chain attacks: the critical distinction
• How supply chain attacks work in 2026
• The 2026 supply chain threat landscape
• What dependency scanners (including GeekWala) catch
• What dependency scanners miss
• Defense layers: combining CVE scanning with malicious package detection
• Practical defenses against supply chain attacks
• FAQ

CVE Vulnerabilities vs Supply Chain Attacks: The Critical Distinction

These two threat categories get conflated constantly, and the confusion creates real gaps in how teams defend their software.

CVE vulnerabilities are bugs in legitimate packages. A maintainer writes code with a buffer overflow, a prototype pollution flaw, or an insecure default. The vulnerability gets discovered, assigned a CVE identifier, and published to advisory databases like the OSV database, the National Vulnerability Database, or GitHub Security Advisories. The maintainer releases a patch. Scanners detect the vulnerable version and tell you to upgrade.

Supply chain attacks are intentional. An attacker gains access to a package — by phishing a maintainer's credentials, by registering a typosquatted name, or by contributing malicious code through a seemingly innocent pull request — and publishes a version containing code designed to steal data, install backdoors, or exfiltrate secrets. There is no "bug" to find. The malicious code does exactly what the attacker intended.

The detection mechanisms for these two threats are fundamentally different. CVE scanning compares your dependency versions against a database of known issues. Malicious package detection requires behavioral analysis — examining what the code actually does at install time, looking for obfuscated payloads, flagging unusual network calls in post-install scripts, and identifying packages that don't match the behavior their description claims.

This distinction matters because developers who run a dependency scanner and see a clean report sometimes assume they're fully protected. They're protected against one category of threat. The other category requires additional tooling.

How Supply Chain Attacks Work in 2026

The attack patterns have grown more sophisticated, but most still follow a recognizable playbook.

Maintainer account compromise remains the most impactful vector. Attackers send targeted phishing emails to maintainer accounts associated with popular packages. If the maintainer's npm or PyPI account lacks two-factor authentication — and many still don't — the attacker gains publishing rights. They push a new patch version containing malicious code, and every developer who runs npm update or pip install --upgrade pulls it automatically.

The dYdX attack in January 2026 followed this pattern precisely. The attacker compromised maintainer credentials for both the npm package @dydxprotocol/v4-client-js and the PyPI package dydx-v4-client, then published versions containing wallet-stealing payloads. Because the packages were legitimate and widely used in the DeFi ecosystem, the malicious versions were installed thousands of times before detection.

sequenceDiagram
    participant A as Attacker
    participant M as Maintainer
    participant R as npm/PyPI Registry
    participant D as Developer
    participant S as Production Server

    A->>M: Phishing email (fake npm security alert)
    M->>A: Clicks link, enters credentials
    A->>R: Publishes malicious version (v4.1.1)
    D->>R: npm install (pulls v4.1.1)
    R->>D: Malicious package installed
    D->>S: Deploys to production
    S->>A: Exfiltrates secrets/credentials

Typosquatting targets developers who make typos. An attacker publishes expres (missing the second 's'), lodasj, or reqeusts — close enough to catch a mistyped npm install or pip install. These packages often contain the real package's code plus a malicious payload, so the developer's code works normally while data exfiltration runs in the background.

Dependency confusion exploits the gap between public and private registries. If your company uses an internal package called @company/auth-utils but hasn't claimed that name on the public npm registry, an attacker can publish a higher-versioned package with that exact name on npm. Many build systems will prefer the higher public version over the lower internal one. For a deeper dive on this vector specifically, see our dependency confusion attacks guide.

The GitLab "Shai-Hulud" propagation pattern demonstrated in early 2026 how a single compromised npm package could spread worm-like through CI/CD pipelines. The malicious install script searched for .npmrc files containing authentication tokens, used those tokens to publish compromised versions of other packages the developer maintained, and spread laterally across the ecosystem. One compromised maintainer could cascade into dozens of infected packages within hours.

The 2026 Supply Chain Threat Landscape

The numbers tell a clear story: supply chain attacks are accelerating.

In February 2026 alone, security researchers identified over 230 malicious packages across npm and PyPI. The majority targeted npm — it remains the primary attack surface due to its size (over 2.5 million packages), the ease of publishing, and the automatic execution of install scripts. PyPI is the secondary target, with RubyGems emerging as an increasingly attractive vector as attackers diversify.

Key trends in 2026:

Targeting has shifted upstream. Rather than publishing standalone malicious packages and hoping developers install them, attackers increasingly target the maintainers of packages that already have millions of weekly downloads. One compromised maintainer account yields far more impact than a thousand typosquatted packages.

Install scripts are the primary payload delivery mechanism. The preinstall and postinstall hooks in package.json run arbitrary code the moment npm install completes. Most malicious npm packages use this vector because the code executes before the developer has any chance to review it.

Detection windows are shrinking but still exploitable. The median time between a malicious package being published and being detected by the community is still measured in days, not hours. During that window, every install is compromised.

AI-generated code amplifies the risk. When developers use AI assistants to generate dependency lists, hallucinated package names create new attack surfaces. An attacker who knows which names AI models commonly hallucinate can register those names preemptively. We covered this attack vector in detail in auditing AI-generated dependencies.

What Dependency Scanners (Including GeekWala) Catch

Dependency scanners are built to answer one question: "Do any of my dependencies have known vulnerabilities?"

This is genuinely valuable. Most security incidents involving open-source software involve known CVEs that simply weren't patched. The Log4Shell vulnerability (CVE-2021-44228) was exploited widely not because detection was hard, but because organizations didn't scan, didn't prioritize, or didn't patch in time.

GeekWala scans your dependency manifests — package.json, requirements.txt, composer.json, go.mod, Cargo.toml, Gemfile, and .csproj files — against the OSV database and enriches results with EPSS scores (probability of exploitation in the wild) and CISA KEV data (confirmed active exploitation). This enrichment helps you prioritize which vulnerabilities to fix first rather than drowning in a flat list of CVEs sorted by CVSS score alone.

What CVE scanning handles well:

• Known vulnerabilities in legitimate packages. If lodash@4.17.11 has a prototype pollution CVE, your scanner flags it and tells you to upgrade to 4.17.21.
• Transitive dependency risks. Your direct dependency might be fine, but its dependency's dependency might have a critical flaw. Scanners trace the full tree.
• Prioritization context. Not all CVEs are equal. EPSS data shows that at most about 6% of CVEs are ever exploited, with stricter datasets nearer 1–2%. Scanners with enrichment data help you focus on the ones that matter.
• Continuous monitoring. New CVEs are published daily. A scanner integrated into your CI/CD pipeline catches newly disclosed vulnerabilities in packages you already use.

This coverage is necessary. It handles the majority of real-world dependency risk. But it doesn't cover everything.

What Dependency Scanners Miss

Here's where we need to be straightforward.

Malicious packages with no CVE. When an attacker publishes a malicious version of a package, there is no CVE for it — at least not immediately. The OSV database and NVD track vulnerabilities in code, not intentional malware. Some malicious packages eventually receive advisory entries, but the detection happens through other means (behavioral analysis, community reports, registry takedowns), not through CVE databases.

The time gap between compromise and advisory. Even when a compromised package does get flagged, there's a window — hours to days — between the malicious version being published and an advisory being issued. During that window, CVE scanners see a clean report while the malicious code runs.

Zero-day malicious payloads. If an attacker publishes a new malicious package that hasn't been analyzed yet, no advisory exists. Scanners that rely on advisory databases have nothing to match against.

Post-install script behavior. A dependency scanner reads your manifest and lockfile. It doesn't execute the package's install scripts or analyze what they do. A package that exfiltrates environment variables in its postinstall hook looks identical to a benign package in a manifest scan.

This isn't a failing unique to GeekWala. It's a fundamental limitation of the CVE-scanning approach. Advisory-based scanning and behavioral analysis are complementary techniques that require different architectures. Trying to bolt behavioral analysis onto a CVE scanner produces poor results at both tasks.

Defense Layers: Combining CVE Scanning with Malicious Package Detection

The right approach is layered defense, not a single tool.

Layer 1: CVE scanning catches known vulnerabilities in the packages you depend on. This is your foundation. GeekWala, Snyk, Trivy, Grype — pick a scanner and run it in CI. If you're evaluating options, we've written comparisons for several alternatives.

Layer 2: Malicious package detection catches intentional malware, typosquatting, and compromised packages. Socket.dev is the standout tool in this category. It analyzes package behavior — what happens at install time, what network calls the code makes, whether the package accesses the filesystem in unexpected ways — rather than matching against advisory databases. This is a different detection model designed for a different threat.

Layer 3: Registry-level protections. npm and PyPI have improved their automated malware scanning. npm's registry-side checks catch a growing percentage of malicious packages before they reach developers. But these checks aren't comprehensive, and attackers actively work to evade them.

Layer 4: Organizational controls. Lockfiles, private registries, scoped packages, and code review of dependency updates. These don't detect attacks — they reduce the attack surface.

Using GeekWala and Socket.dev together gives you coverage across both threat categories. GeekWala tells you "this version of express has a known vulnerability, and EPSS says there's a 73% chance it gets exploited this month." Socket.dev tells you "this package's install script makes HTTP requests to an IP address in Russia and reads your .env file." Different questions, both critical.

Practical Defenses Against Supply Chain Attacks

Beyond tooling, these practices reduce your exposure to supply chain attacks directly.

Pin exact versions and commit lockfiles. Use npm ci instead of npm install in CI. Commit your package-lock.json, yarn.lock, or poetry.lock. This ensures you install exactly what you tested, not whatever the latest version happens to be. Version ranges like ^4.1.0 automatically pull new minor and patch versions — which is exactly how compromised versions propagate.

Delay adoption of new releases. Wait 7-14 days after a package publishes a new version before upgrading. Most malicious versions are detected and removed within a few days. This buffer protects you during the highest-risk window. Automated tools like Dependabot and Renovate can be configured with delay windows.

Use a private registry or caching proxy. Tools like Artifactory, Verdaccio, or npm Enterprise let you vet packages before they enter your build pipeline. You control what's available. This also protects against dependency confusion attacks by ensuring private package names resolve internally.

Require 2FA on all maintainer accounts. If you publish packages, enable two-factor authentication on your npm, PyPI, and RubyGems accounts. Use hardware keys if possible. This is the single most effective defense against account takeover — the attack vector behind the highest-impact compromises.

Review dependency updates before merging. Don't auto-merge Dependabot PRs. Look at the changelog, check the diff, and verify the release was made by the expected maintainer. This takes time, but it's the only human checkpoint in the process. Focus review effort on packages with install scripts.

Minimize your dependency footprint. Every dependency is a trust relationship. Use standard library functions when they suffice. Evaluate whether a 12-line utility function justifies adding a package with its own transitive dependency tree. Fewer dependencies means fewer attack surfaces.

Audit install scripts. Run npm pack and inspect the package contents before installing anything new. Check for preinstall and postinstall scripts in package.json. If a utility library needs to run code at install time, that's worth investigating.

FAQ

Can GeekWala detect malicious packages?

GeekWala detects known CVEs in legitimate packages, enriched with EPSS exploitation probability and CISA KEV active exploitation data. It does not perform behavioral analysis to detect novel malicious code. For malicious package detection, use a specialized tool like Socket.dev alongside GeekWala. The two tools are complementary — GeekWala covers vulnerability management and prioritization, Socket.dev covers supply chain attack detection.

What's the difference between a CVE and a supply chain attack?

A CVE is a cataloged vulnerability — typically an unintentional bug — in a legitimate package. The maintainer didn't mean to introduce the flaw, and once discovered, they release a patch. A supply chain attack is intentional: an attacker injects malicious code into a package (through account compromise, typosquatting, or other means) with the goal of stealing data, installing backdoors, or causing harm. CVEs have identifiers you can look up. Supply chain attacks may never receive a CVE at all.

How do I protect my npm packages from being compromised?

Enable two-factor authentication on your npm account immediately — use a hardware security key if possible. Use strong, unique passwords and monitor your account for unauthorized publishes. Consider npm's granular access tokens to limit what automation tokens can do. Review access permissions regularly and remove contributors who no longer maintain the package. Enable npm's publish notifications so you're alerted if someone publishes a version you didn't authorize.

Should I stop using open source packages?

No. Open-source software powers virtually all modern software. The risk isn't in using open source — it's in using it without appropriate security practices. Pin your versions, scan for CVEs, use behavioral analysis tools for malicious packages, review dependency updates, and minimize unnecessary dependencies. A well-maintained dependency with a large contributor base and active security response is typically safer than writing equivalent code yourself.

How quickly are malicious packages typically detected and removed?

Detection time varies significantly. High-profile compromises of popular packages (like the dYdX incident) are typically detected within hours to a few days as developers notice unusual behavior and report it. Less prominent malicious packages — typosquatted names or packages targeting niche ecosystems — can persist for weeks or even months before discovery. This is why delayed adoption (waiting 7-14 days before upgrading) is an effective defense: it lets the community's collective detection catch most threats before they reach your pipeline.