Cybersecurity researchers have uncovered a sustained, highly targeted campaign in which threat actors turned packages hosted on the npm registry into phishing delivery mechanisms designed to harvest login credentials from users in critical sectors. Rather than behaving like typical malware, these packages are being abused to serve browser-executed lures and phishing pages that mimic legitimate services — leveraging npm’s trusted infrastructure and content delivery networks (CDNs) to evade detection and prolong their availability. According to threat analysts at Socket Threat Intelligence, the operation involved 27 malicious npm packages published under multiple aliases over a five-month period. These packages were not intended to be installed by developers; instead, they were built to act as hosting infrastructure for credential-harvesting pages embedded in web views when accessed via browser CDNs. The campaign targeted employees — particularly in sales and commercial roles — at organizations across multiple industries, including manufacturing, industrial automation, healthcare, and polymers. This incident highlights a significant evolution in software supply chain abuse: attackers are discovering that package repositories aren’t only vectors for malware installation scripts, but can also be repurposed as trusted distribution platforms for phishing and credential theft — a shift that security experts are calling “supply chain misuse.” How the Attack Worked — Hosting Phishing Lures on npm CDNs Unlike previous npm-related threats that rely on installation or direct execution of malicious code, this campaign leveraged npm’s content delivery infrastructure to host embedded HTML and obfuscated JavaScript that serves phishing content to visitors. Here’s how the process unfolded: Publishing Malicious PackagesAttackers uploaded 27 npm packages using six distinct publisher accounts. Each package contained minimal legitimate code but included embedded client-side content (HTML/JS) designed to look like a secure document-sharing portal or business application. Serving Phishing Pages via npm CDNBecause npm packages are automatically served via a global CDN, threat actors exploited this trusted delivery mechanism to serve phishing pages directly from npm’s domain. A victim clicking a link would receive HTML/JS that appeared to be hosted legitimately. Mimicking Enterprise Services and Redirecting to Credential HarvestersThe content in these packages displayed convincing user interfaces mimicking services like Microsoft 365 sign-in screens or secure document viewers. Victims who engaged with these pages were then redirected to fake authentication portals pre-filled with context-specific email fields and prompted to enter credentials. Credential Capture and ExfiltrationOnce credentials were entered, the captured data was immediately exfiltrated to attacker-controlled servers — effectively harvesting login details without ever requiring victims to download or install the npm packages themselves. This represents a strategic shift in how open-source repositories can be exploited: instead of inserting malicious behavior into runtime dependencies, attackers are simply hosting malicious content served through trusted infrastructure that many networks and browsers inherently trust. Who Was Targeted and Why It Matters The packages did not indiscriminately target developers or public users. Instead, experts found that the phishing infrastructure was pre-configured to target specific individuals within organizations — particularly sales, account management, and business development personnel. Hard-coded email addresses tied to these roles were embedded in the phishing workflows, meaning that the fake login interfaces would pre-fill the email field to make the page seem more legitimate and customized. Targets were located in countries including: Austria Belgium Canada France Germany Italy Portugal Spain Sweden Taiwan Turkey United Kingdom United States These details suggest the threat actors had detailed reconnaissance on individual victims — a hallmark of spear-phishing rather than broad, opportunistic mass spam. Researchers believe that some of the data for these targeted campaigns may have been gathered from publicly available sources such as trade show directories, professional networking sites, and open web disclosures. Why npm’s Infrastructure Was Abused The npm registry — used by JavaScript developers worldwide to share modules and libraries — is inherently trusted by developer tools, CI/CD pipelines, and security scanners. Its content delivery network distributes package assets with high uptime and global reach. Threat actors took advantage of several characteristics of npm: Trusted Domain (npmjs.com): Links pointing directly to npm-hosted content are less likely to trigger blocking or scrutiny by enterprise web filters. Globally Distributed CDN: npm’s infrastructure ensures fast delivery of content worldwide, which attackers exploited to ensure wide reach. Unrestricted Package Content Hosting: npm packages can contain arbitrary content, including HTML and JavaScript, which served as the backbone of the phishing page infrastructure. This method avoids the need for traditional attack vectors like installation scripts or post-install hooks, instead using browser execution contexts to load phishing pages directly. How the Campaign Evaded Detection Several techniques helped the malicious infrastructure avoid early detection: Client-Side Anti-Analysis Checks The packages incorporated browser executes scripts that perform anti-bot and anti-sandbox checks, such as: Detecting whether a human user triggered the interaction (e.g., requiring mouse or touch events). Filtering out automated crawlers that might alert analysis tools. These controls make it harder for automated security scanners and analysts to identify malicious behavior merely by loading the package. Obfuscated and Minified Code The JavaScript delivered by these packages was heavily minified and obfuscated, making static analysis challenging. Detection tools often struggle to flag obfuscated JavaScript without runtime analysis. Multiple Publisher Aliases Threat actors used different npm accounts to publish the 27 packages, allowing them to rotate identities if one account was taken down, reducing the effectiveness of reactive remediation. How This Differs from Traditional npm Malware Recent supply chain attacks involving npm have primarily focused on injecting malware into install scripts, credential theft after package installation, or using postinstall hooks to execute malicious code on developer machines. In contrast, this campaign never required anyone to install the packages. Instead: Packages were used as phishing infrastructure hosted directly on npm’s CDN. Victims were tricked into visiting npm-hosted content via external links — not importing the packages into their projects. The attack targeted browser contexts and credential pages, not local development environments. According to security analysts, this method illustrates how trusted supply chain services can be repurposed into phishing platforms without ever violating typical “installation behavior,” making defense more complex. Broader Context: npm Security Challenges This incident follows a period of heightened malicious activity in the npm ecosystem, including: Large-scale spam package pollution campaigns that flooded the registry with tens of thousands of fake packages. Self-propagating “worm-like” malware campaigns that targeted npm packages and credentials. Traditional credential-stealing packages hidden under obfuscation layers mimicking popular libraries. State-linked threat actors deploying malware variants through npm packages to steal developer secrets and wallet data. Together, these trends show that the open and trusting nature of public registries like npm continues to be exploited by attackers in creative ways. Defensive Measures: What Organizations Should Do Given the evolving abuse of npm infrastructure, organizations and developers should adopt layered defensive controls: 1. Enforce Rigorous Dependency Verification Check that dependencies are: Published by verified and trusted entities. Signed and cryptographically validated where possible. Scoped to known sets of packages used in your projects. Automated tools can flag unusual or newly published dependencies for review. 2. Block and Inspect CDN-Hosted Phishing Content Network blockers and DNS filters should block known malicious domains and CDN endpoints used in phishing campaigns. Look for patterns such as unexpected npm URL paths serving HTML content. 3. Implement Phishing-Resistant Authentication Use multi-factor authentication (MFA) to prevent credential abuse even if initial usernames and passwords are compromised. 4. User Awareness and Training Employees — particularly in sales, customer relations, and business development roles — should be trained to recognize suspicious links and avoid entering credentials into unfamiliar or unsolicited login prompts. 5. Monitor Third-Party Infrastructure Abuse Keep an eye on unusual inbound links, traffic from unexpected repositories, or unknown content delivery endpoints being referenced in phishing emails or messages. Final Thoughts: A New Phase of Supply Chain Abuse The discovery of these 27 malicious npm packages used as phishing infrastructure underscores a growing trend: attackers are increasingly exploiting trusted platforms for non-traditional attack vectors that don’t rely on code execution within a victim’s system, but rather on trusted content delivery and social engineering to harvest credentials. This campaign should serve as a wake-up call for developers, security teams, and organizations that public software repositories are not just vectors for code reuse — they can also be weaponized to host content that deceives and compromises users. As the threat landscape continues to evolve, defenders must adapt strategies to protect both development ecosystems and end-user environments against these hybrid phishing and supply chain misuse attacks. Post navigation MongoDB “MongoBleed” Vulnerability (CVE-2025-14847) Under Active Exploitation – What You Need to Know The Breach You Didn’t Expect: Why Your AppSec Stack Could Fail You in 2026 — A Deep Dive