PolinRider: The Supply Chain Surge – 108 Malicious Packages and Counting
Just caught the report on the PolinRider campaign. It looks like the threat actors behind the notorious "Contagious Interview" operation are expanding their playbook significantly. We’re seeing a massive influx of malicious artifacts—specifically 108 unique packages and extensions—published across the npm, Packagist, and Go registries, along with the Chrome Web Store.
The core issue here isn't just code quality; it's identity. They are actively compromising maintainer accounts to push malware directly into trusted sources. Since the campaign targets the supply chain, the blast radius is potentially massive.
I’ve been updating our internal scanning utilities to flag anomalies in package. and go.mod files. Specifically, we're looking for packages that spawn child processes or perform network calls during installation. Here is a quick Python snippet we’re using to audit local node_modules for obfuscated post-install scripts (a common IoC in these attacks):
import
import os
import re
def scan_node_modules(directory):
for root, dirs, files in os.walk(directory):
if 'package.' in files:
path = os.path.join(root, 'package.')
try:
with open(path, 'r', encoding='utf-8') as f:
data = .load(f)
scripts = data.get('scripts', {})
for key, value in scripts.items():
# Heuristic: Look for base64 strings or encoded commands in install scripts
if 'install' in key.lower():
if re.search(r'eval\(|atob\(|Buffer\.from', value):
print(f"[!] Suspicious script in {path}: {key}")
except Exception as e:
continue
scan_node_modules('./node_modules')
Since they are also hitting Chrome extensions, relying solely on registry scanning isn't enough. We need to lock down developer accounts.
How are you handling maintainer account security? Are we at the point where 2FA/FIDO2 should be mandatory for publishing to public registries?
We're seeing similar attempts in our SOC, specifically targeting npm. I recommend adding a KQL rule to your SIEM to track npm install or pip install commands originating from unusual user agents or outside of your CI/CD build agent IP ranges.
Here is a basic query we use to flag unexpected package installations:
DeviceProcessEvents
| where FileName in~ ('npm.exe', 'npm', 'pip', 'pip3')
| where ProcessCommandLine contains 'install'
| where InitiatingProcessAccountName != 'build-service'
This won't catch the compromised maintainer directly, but it stops the malware execution on the endpoint if a developer accidentally pulls a bad package.
The extension angle is terrifying because it bypasses most network security controls. We've started enforcing a strict allow-list via GPO, but managing the hashes is a nightmare.
For the supply chain side, we've moved to a "reproducible builds" model. We pin dependency hashes in our lock files and block PRs that modify them without a security review. It’s tedious, but it stops typosquatting and these injected packages from getting into master.
I manage a few repos on Packagist. The scary part about the maintainer compromise is how convincing the phishing emails are. They pretend to report a critical vulnerability in your package and ask you to review a 'patch'.
If you maintain open source libs, never run code sent to you via email/DM. Always verify the source, and ideally, review patches on the platform itself, not via zip files.
Jay, that’s exactly why we moved critical build pipelines to an air-gapped environment. If a maintainer account is compromised, the malicious package never touches our production infrastructure unless manually vetted and transferred. To verify integrity post-deployment, we script file hash comparisons against known-good baselines. Here is a quick PowerShell snippet we use to monitor for drift:
Get-ChildItem -Path "C:\App" -Recurse | Get-FileHash -Algorithm SHA256 | Select-Object Path, Hash
Has anyone else looked into SBOM (Software Bill of Materials) enforcement tools to automatically block these compromised dependencies?
Great points on air-gapping. For those running K8s, consider enforcing supply chain security at the image level using Sigstore/Cosign. We require all dependencies to be verified before a build can proceed. Here’s a snippet of what we block in our CI pipeline:
cosign verify --key cosign.pub
This stops unsigned or modified artifacts from ever reaching the cluster.
To catch these artifacts locally, I recommend auditing lockfiles with osv-scanner. It compares your dependencies against a database of vulnerabilities and malware advisories.
osv-scanner --lockfile=package-lock.
Since the OP highlighted identity, enforcing hardware keys (FIDO2) for maintainers is crucial. It neutralizes the phishing impact even if credentials get phished, protecting the registry account itself.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access