Between late 2025 and April 11, 2026, North Korean threat actors published 108 malicious packages and extensions across npm, PyPI, Chrome Web Store, and other platforms as part of the PolinRider campaign. According to Socket's research, this activity compromised 1,951 public GitHub repositories—a scale that should concern any team managing open source dependencies.
What Happened
The PolinRider campaign targeted developers through fake job recruitment emails. Recipients who engaged with these offers were directed to download what appeared to be legitimate development tools or project files. Instead, they received malicious packages that established persistence in their local development environments.
Once installed, the malware harvested credentials, modified existing repositories, and published additional malicious packages under the compromised developer's identity. This created a cascading effect—each compromised account became a distribution point for new attacks.
The campaign specifically targeted cryptocurrency developers and organizations, though the repository compromise count suggests broader impact across the development community.
Timeline
Late 2025: Initial malicious packages appear on npm and PyPI registries. Early packages use names similar to legitimate cryptocurrency and development tools.
January-March 2026: Campaign accelerates with Chrome extensions and Visual Studio Code extensions added to the attack infrastructure. Fake recruitment emails intensify, using realistic job descriptions from legitimate cryptocurrency firms.
April 11, 2026: Socket identifies the campaign and documents 108 unique malicious artifacts across multiple platforms. Repository compromise count reaches 1,951 public repositories.
Post-disclosure: Registries begin removing identified packages, but the decentralized nature of the attack means cleanup requires coordination across platforms and individual repository owners.
Which Controls Failed or Were Missing
No package verification workflow: The compromised organizations lacked automated verification of package integrity before installation. Developers installed packages directly from recruitment emails without validation against known-good hashes or signatures.
Missing repository access controls: Once attackers gained initial access through compromised developer credentials, they had sufficient permissions to modify repositories and publish packages. This indicates overly permissive access policies—developers held both read and write access to critical repositories when read-only would have sufficed for their daily work.
Absent anomaly detection: 1,951 repositories were modified without triggering alerts. No monitoring detected unusual commit patterns, publishing activity from new locations, or credential usage outside normal working hours.
No social engineering awareness: Developers clicked through fake recruitment emails and installed unverified code. This points to missing or ineffective security awareness training specific to supply chain attack vectors.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software be developed based on industry standards and incorporate information security throughout the software development lifecycle. For teams handling payment card data, this includes verifying the integrity of all software components before deployment—not just production code, but development dependencies and tools.
NIST 800-53 Rev 5 control SA-12 (Supply Chain Protection) requires organizations to employ supply chain protection measures including conducting supplier reviews, employing anti-counterfeit technologies, and limiting harm from potential adversaries. Installing packages from unverified sources based on recruitment emails violates this control entirely.
ISO 27001 Annex A.8.30 (Outsourcing) addresses risks related to third-party code, requiring that changes to services and suppliers be managed to maintain information security. While recruitment scams aren't traditional outsourcing, the control's principle applies: verify the source before integrating external code into your environment.
SOC 2 Type II CC6.6 requires logical access controls that restrict access to authorized users. The ability of compromised accounts to modify nearly 2,000 repositories suggests inadequate implementation of least privilege and separation of duties.
Lessons and Action Items for Your Team
Implement mandatory package verification. Before any developer installs a package—especially from an external communication—require verification against the official registry's hash. Add this to your onboarding checklist and CI/CD pipeline. For npm, this means checking package-lock.json integrity hashes. For PyPI, verify against the SHA256 hash listed on the package page.
Enforce repository access boundaries. Audit your GitHub organization permissions this week. Developers should have write access only to repositories they actively maintain. Use branch protection rules that require pull request reviews even for maintainers. Enable push protection to prevent accidental credential commits.
Deploy package installation monitoring. Configure alerts for package installations from your developer machines. Tools like Socket, Snyk, or GitHub's Dependabot can flag suspicious packages, but you need monitoring at the workstation level to catch malicious installs before they reach your repositories. Log all npm install, pip install, and similar commands to your SIEM.
Build recruitment-scam awareness. Add supply chain attack scenarios to your security training. Show developers what these emails look like. Establish a protocol: any recruitment communication that asks you to download code goes to security@ first. Make reporting these attempts easier than clicking through them.
Require signed commits. GitHub supports GPG signature verification. Require it for all commits to production repositories. This won't prevent a compromised developer account from pushing code, but it creates an audit trail that ties commits to specific keys, making post-incident investigation faster.
Separate development and publishing credentials. Your developers need to install packages; they don't all need to publish them. Create separate accounts with publishing rights for designated maintainers only. Use hardware security keys for these accounts. Enable two-factor authentication organization-wide—no exceptions.
Test your detection capabilities. Run a tabletop exercise this quarter: assume a developer account is compromised. How quickly would you detect unusual repository modifications? Unauthorized package publications? Credential usage from a new geographic location? If the answer is "we wouldn't," you have the same gap PolinRider exploited at scale.
The 1,951 compromised repositories represent 1,951 teams that now need to audit their commit history, rotate credentials, and notify downstream users. Your team can avoid joining that count by implementing these controls before the next campaign launches.
