Malicious Packages and Extensions Show How Developer Environments Become Targets for Credential Theft

Overview

A new wave of software supply chain activity linked to North Korean threat actors and the Contagious Interview campaign is putting developer environments under pressure. The campaign, known as PolinRider, uses malicious packages, browser extensions, and compromised or manipulated repositories to reach developers, cryptocurrency companies, and organizations with software engineering teams.

Public analysis links the campaign to more than 100 unique packages and extensions across multiple ecosystems, including npm, Packagist, Go modules, and Chrome extensions. The objective is to execute malicious code inside developer workstations or development environments, where secrets, tokens, credentials, wallet data, source code, and repository access may be available.

The issue matters because the attack does not begin at the traditional perimeter. It begins with the tools developers use every day.

What Happened

PolinRider is part of broader activity linked to Contagious Interview, a campaign in which attackers pose as recruiters, technical interviewers, or collaborators and convince developers to run code as part of a “technical assessment,” “interview,” or “project.”

In the latest wave, attackers broadened the approach. Instead of relying only on direct social engineering, they are abusing open-source ecosystems, package registries, browser extensions, and developer tooling.

Public analysis describes several core techniques:

• publishing malicious npm, Go, and Packagist packages;
• using a browser extension as part of the attack chain;
• adding obfuscated JavaScript loaders into repositories;
• abusing VS Code tasks that may execute when a workspace is opened;
• hiding payloads as font files or harmless project assets;
• manipulating Git history to make malicious commits appear older or less suspicious.

This makes the campaign harder to detect by reviewing only the GitHub landing page or visible commit history.

Why This Matters

Developer environments often contain more access than they appear to. A developer laptop or build environment may have access to:

• GitHub, GitLab, or Bitbucket repositories;
• npm, PyPI, Go, Packagist, or container registries;
• cloud credentials;
• SSH keys;
• API tokens;
• CI/CD secrets;
• cryptocurrency wallets;
• production or staging configurations;
• internal documentation;
• customer-facing code.

Compromising a developer environment can therefore become a software supply chain risk. The attacker is not only looking for local files. They are looking for a path into repositories, build pipelines, cloud environments, and downstream users of the software.

How the Attack Works

PolinRider combines package-based infection, repository manipulation, and developer tooling execution.

A typical scenario may look like this:

• a developer installs a package that appears legitimate;
• the package contains a hidden JavaScript loader or install-time logic;
• malicious code executes inside the developer environment;
• the loader fetches a second stage from an external source or blockchain-backed infrastructure;
• the malware searches for secrets, wallet data, tokens, and developer configuration files;
• in some cases, project files or VS Code tasks are modified;
• the changes may be hidden through Git history manipulation;
• access is used for new packages, compromised repositories, or follow-on attacks.

The abuse of developer tools is especially important. If a malicious task executes when a project is opened in VS Code or a similar environment, simply inspecting a repository may create risk.

Potential Impact

Impact depends on where the malicious package was installed and what access the affected environment had.

Possible consequences include:

• theft of GitHub, npm, or cloud tokens;
• theft of secrets from local configuration files;
• access to private repositories;
• compromise of CI/CD pipelines;
• publication of new malicious package versions;
• theft of cryptocurrency wallet data;
• backdoors added to source code;
• downstream attacks against customers or users;
• compromise of developer identity.

For organizations with internal development teams, this is not only an open-source community problem. It is a risk to the internal software supply chain.

Why Git History Is Not Enough

One important finding is that visible Git history can be misleading. Attackers may use force pushes, anti-dated commits, or other techniques to make malicious changes appear older, legitimate, or less suspicious.

This means reviews should not stop at how a repository looks. Security teams should inspect:

• repository activity logs;
• package release metadata;
• new or unusual maintainers;
• changes to .vscode/tasks.json;
• hidden or obfuscated JavaScript loaders;
• unexpected changes to configuration files;
• package install scripts;
• GitHub Actions and CI/CD changes;
• suspicious outbound connections from developer workstations.

Recommended Actions

Organizations that use open-source packages or maintain development teams should treat PolinRider as a supply chain risk, not only as a malware campaign.

Priority actions include:

• check whether affected packages or extensions were used in development environments;
• review lockfiles and package release history;
• remove affected versions and rebuild from a known-good dependency state;
• inspect .vscode/tasks.json and other auto-run developer configurations;
• review package install scripts and postinstall hooks;
• look for obfuscated JavaScript loaders and suspicious .woff2 or fake asset files;
• check changes in configuration files such as vite.config.js, eslint.config.js, next.config.js, tailwind.config.js, and similar files;
• rotate secrets, tokens, and credentials from a clean machine;
• review GitHub, npm, cloud, and CI/CD access logs;
• restrict package registry publishing permissions;
• enforce MFA and fine-grained tokens for developer accounts;
• monitor developer endpoints for abnormal activity.

If a malicious package was installed in a developer environment, removing the package alone is not enough. The environment should be treated as potentially compromised until accessible secrets are reviewed.

DIAMATIX Perspective

PolinRider shows how developer environments are becoming part of the organization’s attack surface. This is not only a dependency hygiene issue. The risk affects identities, endpoints, repositories, CI/CD processes, and cloud access.

In many companies, a developer workstation has access to critical systems but is not monitored with the same attention as a production server. This creates a gap: the attacker can enter through a tool that looks like part of the normal development process.

Protection requires:

• visibility into developer endpoints;
• control over package installation;
• secrets management;
• monitoring of repositories and CI/CD pipelines;
• review of dependency changes;
• an incident response process for developer compromise;
• clear separation of personal, test, and production credentials.

The core lesson is clear: software supply chain risk does not begin only in production. It often begins on a developer machine.

CISO Analysis

From a CISO perspective, PolinRider is a risk to the software supply chain, developer identity, and access to internal systems.

Key questions include:

• Do we know which open-source packages are used in development and build environments?
• Do we control package installation and package publishing?
• Is MFA enforced for GitHub, npm, cloud, and CI/CD accounts?
• Do developers use long-lived tokens or locally stored secrets?
• Are changes to .vscode/tasks.json, GitHub Actions, and package scripts monitored?
• Can we detect a malicious dependency before it reaches the build pipeline?
• If a developer machine is compromised, do we know which secrets must be rotated?
• Does the SOC have visibility into developer endpoints and repository activity?

These questions matter because modern software delivery depends on many external dependencies. Any one of them can become an entry point if code installation, execution, and publishing are not controlled.

What This Means for Your Environment

• This type of risk relies on trust in open-source packages, developer tooling, and repository workflows to execute code in an environment with access to secrets and source code.
• Detection depends on visibility into developer endpoints, package metadata, install scripts, repository activity, VS Code tasks, Git history changes, and outbound connections.
• Response requires removal of affected packages, rebuild from a known-good state, secret rotation, repository review, and monitoring of developer accounts after the incident.

Do you know which developer environments in your organization can publish code or packages to production-facing systems?

Can you detect a malicious package before it steals tokens from a developer workstation?

See how software supply chain risks like this are investigated and handled in real operational environments.

Developer environments are now part of the attack surface.

The PolinRider campaign shows how malicious npm, Go and Packagist packages, browser extensions, and manipulated repositories can be used to steal secrets, tokens, and source code access.

The risk does not start only in production. It often starts on a developer machine with access to GitHub, cloud environments, and CI/CD pipelines.

Review:
🔹 used packages and lockfiles
🔹 .vscode/tasks.json
🔹 package install scripts
🔹 locally stored secrets
🔹 abnormal activity from developer endpoints

DIAMATIX helps organizations build visibility across endpoints, identities, repositories, and cloud activity.

Contact DIAMATIX
Trusted · Innovative · Vigilant

Sources

• Socket. PolinRider: North Korea-Linked Supply Chain Campaign Expands Across Open Source Ecosystems.
• OpenSourceMalware. PolinRider technical dossier.
• SecurityWeek. North Korean hackers target open source developers in supply chain attacks.
• eSentire. DEV#POPPER and Contagious Interview campaign analysis.
• Sonatype. Hijacked npm package attempts to deliver PolinRider-linked RAT.

This article is based on publicly available technical information and analysis as of July 2026.