The PolinRider campaign involves compromise of developer GitHub accounts to inject malicious code into development versions of widely used packages, notably visanduma/nova-two-factor on Packagist. The operators leverage multiple ecosystems (npm, PyPI, Go modules, Packagist, Chrome extensions) and employ advanced techniques such as rewriting Git history, hiding payloads in configuration and font files, and triggering execution automatically via IDE tasks. Payload delivery is staged using dead-drop mechanisms like EtherHiding and NullReceiver. Infection primarily occurs through Git-based collaboration workflows rather than direct compromise of package registries. PHP projects are specifically targeted with obfuscated JavaScript executed via shell_exec calls. Attribution points to North Korean actors with a focus on cryptocurrency theft.

This campaign enables attackers to distribute malicious code through trusted development workflows, potentially compromising software supply chains across multiple programming ecosystems. The injected code can execute obfuscated JavaScript in PHP projects, facilitating information theft and unauthorized actions. The use of compromised developer accounts and Git repositories increases the risk of widespread infection and stealthy persistence. The campaign's link to North Korean actors suggests a focus on cryptocurrency theft, posing financial and reputational risks to affected organizations and developers.

No official patch or remediation is indicated. Since the infection vector is through compromised developer accounts and Git-based collaboration, mitigation should focus on securing developer accounts with strong authentication (e.g., multi-factor authentication), monitoring for unauthorized Git history rewriting, and auditing code changes in development branches. Developers should verify the integrity of dependencies, especially development versions, and be cautious of unexpected changes in Git repositories. Vendor or package registry advisories should be monitored for updates. There is no indication that direct package registry compromise is the primary vector, so registry-level mitigations are less relevant.