PolinRider Update: Cross-Ecosystem Poisoning (npm, Go, Chrome)
Has anyone else dug into the latest escalation regarding the PolinRider campaign? The shift from standard npm typosquatting to compromising legitimate maintainer accounts is concerning. We’re now seeing malicious payloads across four distinct vectors: npm, Packagist (PHP), Go modules, and Google Chrome Extensions.
The attackers are leveraging trusted reputations to push 108 unique malicious artifacts. Since this targets the build pipeline and the browser, standard endpoint EDR might miss the initial ingress if the package is pulled down by a dev or CI/CD runner.
I’ve updated our CI pipeline to reject any new dependencies that haven't been signed, but the browser extension vector is tricky. Here is a quick PowerShell snippet I’m using to audit for Chrome extensions modified in the last 7 days on our endpoints:
# Audit for Chrome extensions modified in the last 7 days
$basePath = "$env:LOCALAPPDATA\Google\Chrome\User Data\*"
Get-ChildItem -Path "$basePath\Extensions" -Directory -ErrorAction SilentlyContinue | ForEach-Object {
$verPath = Get-ChildItem -Path $_.FullName -Directory | Sort-Object LastWriteTime -Descending | Select-Object -First 1
$manifest = Join-Path -Path $verPath.FullName -ChildPath "manifest."
if (Test-Path $manifest) {
$verPath | Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } | Select-Object FullName, LastWriteTime
}
}
How are you all handling the Chrome extension piece in your corp environments? Are you whitelisting by ID or just blocking the Web Store entirely?
We are strictly whitelisting by Extension ID in our Google Admin console. It’s heavy on the ops side initially, but given the rise in malicious extensions (even legitimate ones getting bought out), it's the only way to be safe. On the npm side, we use npm ci exclusively in builds and lock our package-lock. files in Git, forcing manual PR reviews for any dependency updates.
Good catch on the maintainer compromise angle. We've been seeing similar IOCs in our telemetry—dev boxes reaching out to unusual CDN endpoints right after an npm install. If you can, enable SBOM generation for your builds. It helps immensely when you need to triage if a bad package actually made it into production.
# Example Syft command to generate an SBOM
docker scan -- ./local-build > sbom.
This allows you to quickly cross-reference your artifacts against the reported PolinRider package lists.
The Packagist (PHP) angle is what worries me most. Legacy internal apps often don't have strict dependency locking like Node apps do. I'd recommend running composer audit on your internal repos immediately if you haven't already. The Contagious Interview group is persistent; they won't stop at just 108 packages.
The shift to maintainer compromise makes hardware keys non-negotiable for your team. Regarding the Go modules, ensure GOSUMDB is strictly enforced. We added a CI gate running
go mod verify
to ensure downloaded artifacts match the official checksum database. It’s a quick step that helps detect tampered dependencies. Is anyone seeing these modules attempt to bypass the Go sum database via direct version replacements?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access