supply chainpayrollNotable hacks

Supply chain attacks on payroll software: how they work and how to protect yourself

Name: CleanIssue
Price range: €€

Published on 2026-06-058 min readCleanIssue

Why payroll software is a target

Payroll software is a goldmine for attackers. It contains names, addresses, social security numbers, bank details (IBAN), salaries, and family situations. Everything needed for large-scale identity theft.

But directly attacking a well-protected payroll application is hard. The indirect approach — going through one of its suppliers — is often easier.

Anatomy of a supply chain attack

The classic scenario

The attacker identifies an open-source component used by the payroll vendor (an npm package, a Ruby gem, a Composer package)

They compromise the package maintainer (phishing, credential theft)

They publish a malicious version that exfiltrates environment variables (API keys, database tokens)

The vendor auto-updates its dependencies

The attacker retrieves production database access

Variants observed in 2026

Typosquatting: publishing a package with a name very similar to a popular dependency (lodash → l0dash)

CI/CD compromise: the attacker accesses the deployment pipeline via a compromised GitHub Action

Dependency confusion: injecting a package with the same name as a private package, but on a public registry

Real cases in the HR sector

In 2025, a French digital payslip vendor was compromised via a Node.js dependency. The attacker had access for 11 days to the payslips of 14,000 employees before the leak was detected. Total cost: CNIL notification, individual notification to every affected employee, remediation audit, lost contracts.

In another case, an ATS (recruiting software) was compromised via a WordPress plugin used on its marketing site. The plugin had a backdoor that gave access to the server, and from there, to the candidate database hosted on the same infrastructure.

How to protect yourself

Level 1: the basics

Lock your dependencies: use lock files (package-lock.json, composer.lock) and never run npm install without checking what changed

Audit regularly: npm audit, composer audit, bundler audit — integrate them into your CI

Separate environments: your marketing site should not be on the same infrastructure as your payroll application

Level 2: going further

Sign your dependencies: use tools like Sigstore to verify package integrity

Minimize dependencies: every dependency is an attack surface. Before adding a package, ask if you really need it

Dependency monitoring: tools like Dependabot or Snyk alert you when a CVE is published on one of your dependencies

Level 3: proactive posture

Code review: a third-party code review can detect suspicious behaviors in your critical dependencies

Regular penetration testing: an external audit verifies your deployment chain is airtight

Incident plan: if one of your dependencies is compromised, how quickly can you identify affected data and notify the CNIL?

CleanIssue's role

During a Full Audit, we check your complete attack surface — including supply chain vectors. We test deployment configurations, package registry access, and update mechanisms.

Three adjacent analyses to keep exploring the same attack surface.

supply chainnpm