PolinRider Spreads Through Compromised GitHub Accounts and Packagist

Summary

The PolinRider campaign has expanded to compromise developer accounts on GitHub, leading to the injection of malicious code into the development branches of the Packagist package visanduma/nova-two-factor. This package has over 700,000 cumulative downloads. The attackers leverage Git-based intrusions, including history rewriting and payload concealment, to spread malware and maintain persistence, often targeting PHP projects. The campaign's primary objective appears to be cryptocurrency theft, with broader information-stealing capabilities also present.

Full text

BackResearchSecurity NewsPolinRider Spreads Through Compromised GitHub Accounts and PackagistOperators behind PolinRider used a compromised GitHub account to plant malware in four development versions of a Packagist package with 700,000+ downloads.Karlo ZankiSep 17, 2026|5 min readExport IOCs10Socket researchers identified malicious code in the dev-main version of visanduma/nova-two-factor, a Packagist package with more than 700,000 cumulative downloads, as the PolinRider campaign continues to spread through compromised developer accounts and Git repositories.The Socket Threat Research Team continues to track malicious activity associated with PolinRider. In our July research post, we provided initial technical details about this persistent campaign, which distributes malware across npm, PyPI, Go modules, Packagist, and Chrome extensions. We also documented its expansion into the Packagist ecosystem. Among the latest affected projects is visanduma/nova-two-factor, a Packagist package with more than 700,000 cumulative downloads. The malicious code is present in the unstable dev-* versions; no stable malicious release has been identified at the time of writing. This distinction limits conclusions about exposure through normal stable package installation, but users consuming the development branches directly may be affected.Analysis of the Visanduma GitHub organization indicates that its repositories have been compromised since mid-June 2026. The malicious changes were introduced through the LaHiRu developer account. Public contribution activity shows hundreds of contributions to private repositories after the account was compromised, preventing researchers from determining the campaign’s full repository-level reach.The activity reinforces a defining characteristic of PolinRider: package-registry compromise is often a consequence of a broader Git-based intrusion rather than the campaign’s primary objective. The operators use ordinary source-code collaboration to reach developer environments, spread into additional repositories, and maintain access over time.Git-Based Infection and Persistence#PolinRider is designed to blend into routine development activity. The operators compromise developer accounts, insert malicious content into source repositories, and use common actions—cloning a repository, opening it in an integrated development environment (IDE), or running a normal build or test—to begin the infection chain.The campaign repeatedly uses four techniques:Git history rewriting. Operators force-push rewritten history to introduce or replace malicious code while making review and recovery more difficult.Payload concealment. Malicious JavaScript is hidden in configuration files or files presented as .woff2 fonts, locations developers are less likely to inspect during code review.Automatic execution. Patched configuration files execute during build activity. Other samples use "runOn": "folderOpen" in .vscode/tasks.json, triggering code when a developer opens the repository in a VS Code–compatible IDE.Staged payload delivery. The initial code resolves C2 infrastructure through a dead-drop mechanism, using techniques including EtherHiding and, more recently, NullReceiver. It then downloads later-stage infostealer payloads from the resolved servers.Repeated force-pushes visible in affected repository activity are consistent with the campaign’s use of history rewriting. This continued activity indicates that new malware variations are being delivered to repositories that are already compromised. Because the same account also interacted with private repositories, public GitHub data provides only a partial view of the intrusion.New PHP Execution Technique#PHP projects have been recurring targets of PolinRider, but earlier infections generally crossed ecosystem boundaries by planting malicious JavaScript in project configuration files. Socket researchers recently identified a variation in which heavily obfuscated JavaScript was inserted directly into index.php and executed through PHP’s shell_exec function.This technique allows a PHP entry point to launch the JavaScript infection chain directly. Its appearance suggests that the operators adapt execution methods to the opportunities available in each compromised project rather than relying on one fixed delivery path.Why Package Registries Are a Secondary Spread Channel#Many software supply-chain attacks prioritize rapid distribution: compromise a popular package, publish a malicious version, and reach as many downstream users as possible before defenders respond. PolinRider follows a slower model.The campaign’s primary spread channel is developer collaboration in Git-based services. Compromised source repositories give the operators opportunities to infect contributors, access private projects, and propagate through normal development workflows. Package publication becomes an additional distribution path when a compromised repository produces a new release.Go modules and Packagist can resolve code directly from Git repositories. That behavior allows malicious source code already planted in a repository to become available through another ecosystem without requiring the operators to steal registry publishing credentials or tokens.The visanduma/nova-two-factor compromise fits this pattern. Malicious code is present on dev-main, but no stable malicious version has been released at the time of writing. The operators appear willing to maintain access and wait for routine developer or release activity to carry the payload forward.Impact#The campaign’s complete impact remains difficult to measure. GitHub code search reflects current public repository state and therefore misses at least three important categories:Private repositories touched by compromised accounts.Repositories that were infected and later cleaned.Developer systems on which malicious code executed before repository cleanup.Cleaning the source repository also does not establish that affected workstations or CI environments are clean. Once a later-stage payload executes, the host may remain compromised independently of the repository. Public reports from affected developers describe difficulty removing later-stage components, consistent with the campaign’s persistent design.The campaign’s apparent primary objective remains cryptocurrency theft. The broader information-stealing capabilities of the delivered malware may also expose credentials, source code, and other data useful to the operators.Immediate Guidance#Avoid the affected development branch. Do not install or resolve visanduma/nova-two-factor from dev-main until the repository is confirmed clean. Pin dependencies to a reviewed, known-good commit or stable release according to organizational policy.Audit repository history, not only the current tree. Review force-push events, branch-protection changes, reflogs, workflow changes, and commits from compromised or unfamiliar accounts.Inspect automatic execution paths. Search for unexpected .vscode/tasks.json entries, especially "runOn": "folderOpen"; modified build or test configuration; executable content in .woff2 files; and shell_exec calls that launch Node.js or decoded commands.Treat execution as a host compromise. If a developer opened an affected repository or ran its build or test workflow, isolate and investigate the workstation.Rebuild from a known-good state. Repository cleanup alone is insufficient after payload execution. Reimage affected developer systems where investigation cannot establish integrity.Rotate accessible credentials. Revoke and replace GitHub tokens, package-registry credentials, cloud keys, cryptocurrency wallet secrets, SSH keys, and other credentials available to affected users or processes.Harden Git and IDE workflows. Enforce branch protection, restrict force-pushes, require review for workflow and editor-configuration changes, and prevent untrusted repository tasks from running automatically.Review account activi

Indicators of Compromise

• ip — 193.247.144.38
• ip — 166.88.73.46
• ip — 166.88.134.62
• ip — 23.27.13.135
• hash_sha256 — 7d47c430e6e404dc2fa8b4837678d1cbdb4d0aeacec9b405655cab79d54a2ad9
• hash_sha256 — b7ede935d4979146b55f12b9eec7c83b61962b478f5dc9b8db251e539ec2abd3
• hash_sha256 — ccb187dc9de0cc7477c9817ae53365d273e121407c0305f863e2ab67c35d6395
• hash_sha256 — 139ea03dcddf4aa810d55740be3cf6c92ce7a9f3cbcbbb35440e25b769a87683
• hash_sha256 — 515a53291d25d229e1f9fa72e66407e1cfd7e77c91478400b24d5185af68531a

Entities