The discovery of hundreds of malicious packages in the npm ecosystem demonstrates how software supply-chain attacks are evolving from isolated typosquatting incidents into large-scale malware distribution operations capable of targeting developers across Windows, macOS and Linux simultaneously. Researchers initially identified nearly 800 packages associated with the campaign, with OpenSourceMalware tracking 788 packages and other security researchers subsequently identifying an even larger number. The packages use names that appear randomly generated, typo-squatted or influenced by the growing volume of AI-generated package suggestions, increasing the probability that a developer searching for a library, copying generated code or following an automated dependency recommendation could accidentally install one of them. Once imported into an application, the malicious package launches a downloader that profiles the operating system and processor architecture before retrieving and executing a compatible native payload. 

One of the most important aspects of the campaign is that it does not rely on the npm lifecycle hooks commonly associated with malicious packages. Security teams have increasingly learned to scrutinize `preinstall`, `install` and `postinstall` scripts because attackers frequently abuse these mechanisms to execute code automatically when a package is installed. The newly identified packages avoid this obvious indicator. Their README documentation instructs developers to import the package using Node.js's standard `require()` function, and that ordinary-looking import is enough to trigger the malicious helper code. The package therefore appears relatively quiet during installation and becomes dangerous only when a developer actually loads it into an application or development environment.

This technique is significant because many package-security controls focus heavily on installation behaviour. Organizations may disable lifecycle scripts or flag dependencies containing suspicious installation hooks and assume that doing so substantially reduces npm execution risk. Those protections remain useful, but they do not stop malicious code that executes through the package's ordinary exported functionality. Any dependency imported by a Node.js application is effectively executable code running with the privileges of that application, regardless of whether npm itself executed an installation script.

The campaign takes advantage of this fundamental trust model. Developers routinely import hundreds or thousands of third-party packages indirectly through dependency trees, and reviewing every line of code manually is unrealistic. Attackers therefore do not need to exploit a vulnerability in npm itself. They need only convince a developer or automated system to select the wrong package, after which the package manager performs exactly what it was designed to do: download and make attacker-controlled code available for execution.

After activation, the malicious downloader identifies the host operating system and processor architecture so it can select a compatible second-stage payload. The operation supports Linux x64, Linux ARM64, macOS on both Intel and Apple Silicon, and Windows systems. Cross-platform capability considerably increases the potential victim population because modern development environments are highly heterogeneous. Developers may write code on Macs, build it on Linux CI/CD runners and test or deploy portions of it on Windows systems, meaning one compromised dependency can potentially appear across several operating environments inside the same organization.

The first-stage downloader attempts to retrieve native executables through attacker-controlled Cloudflare Workers infrastructure. Using a legitimate cloud platform provides several advantages to the operators because connections to `workers.dev` domains are common in enterprise networks and may attract less immediate suspicion than traffic toward newly registered or obviously malicious servers. Cloud infrastructure also allows attackers to rotate endpoints quickly and benefit from a large provider's availability and TLS infrastructure without operating their own exposed command-and-control servers.

The downloader does not verify a cryptographic signature or expected hash before executing the retrieved binary. Any payload returned by the configured infrastructure can therefore be written to disk and launched. This gives the attackers considerable flexibility to change second-stage malware without republishing the npm packages themselves. A package that delivers one payload today could distribute a different infostealer, remote-access tool or ransomware component later while retaining the same first-stage JavaScript.

What makes the campaign particularly interesting is the fallback mechanism used when HTTPS payload delivery fails. Instead of simply terminating, the malware switches to DNS TXT records hosted beneath attacker-controlled domains. It first queries a special record indicating how many payload chunks are available and then requests numbered TXT records containing Base64-encoded portions of the executable. The fragments are concatenated, decoded and written into a native binary, allowing the malware to reconstruct its next stage entirely through DNS responses.

DNS TXT records are legitimate mechanisms designed to store arbitrary textual information and are widely used for email security, domain verification and service configuration. Because DNS is required by almost every enterprise environment, outbound queries are often less restricted than arbitrary web traffic. Attackers have repeatedly exploited this trust for command-and-control and data exfiltration, but using DNS as a complete fallback software-delivery channel demonstrates how much functionality can be hidden inside a protocol administrators may still consider routine infrastructure.

The use of DNS also increases resilience. Blocking the identified Cloudflare Worker domains may interrupt the primary HTTPS path while leaving the secondary delivery mechanism operational. Organizations that investigate only web proxy logs could therefore believe the infection failed while the package successfully reconstructed the same payload through DNS. Effective detection requires correlating application execution with DNS behaviour rather than treating the two channels as unrelated events.

The DNS pattern itself provides useful hunting opportunities because the malware retrieves a count record followed by sequentially numbered TXT records. Repeated queries for `c.` followed by `0.`, `1.` and additional numerical labels are unusual for ordinary developer tooling and can provide a stronger behavioural signal than the destination domain alone. DNS security systems should examine query patterns and TXT response volumes, particularly when they originate from developer workstations or build servers immediately after Node.js processes begin running.

Once the second stage has been retrieved, the downloader stores it under deliberately inconspicuous temporary filenames and launches it as a detached process. Linux and macOS systems receive files using hidden `.cache_` style names under `/var/tmp`, while Windows systems receive executables resembling diagnostic components under the user's temporary directory. The naming convention is intended to blend into environments containing numerous temporary files and avoid immediately attracting administrator attention during a superficial investigation.

The malware also creates a marker file with an analytics-related name that prevents the downloader from running repeatedly for several hours. This behaviour likely reduces noisy network activity and makes repeated testing less likely to reproduce the infection immediately. Security researchers or automated sandboxes executing the same package several times within a short interval may therefore observe different behaviour after the first run, which can complicate automated analysis.

The campaign contains additional camouflage in the form of an oversized `telemetry.js` file presenting itself as a plausible analytics SDK. The file contains similar downloader functionality but is not part of the primary execution path. Its presence appears designed to create noise and make malicious networking or system-profiling behaviour look consistent with ordinary telemetry code. Attackers increasingly understand that code reviewers expect analytics libraries to collect system details and communicate with external services, making telemetry terminology useful camouflage for behaviour that would otherwise appear suspicious.

The second-stage payload behaviour differs across operating systems. On Windows, Sonatype observed malware capable of attempting to interfere with Event Tracing for Windows and the Antimalware Scan Interface, performing checks for virtual machines and analysis environments, establishing persistence through Registry Run keys and scheduled tasks, and retrieving additional encrypted malware. These capabilities indicate that the operation is not merely collecting basic environment information but is attempting to establish durable access while reducing visibility into its execution.

AMSI and ETW are important components of Windows security visibility. AMSI allows security products to inspect script content before execution, while ETW provides extensive telemetry used by endpoint products and Windows itself. Malware that attempts to patch or disable these interfaces is explicitly trying to blind defensive controls. Organizations should therefore monitor for processes modifying AMSI or ETW-related memory rather than relying entirely on the telemetry those mechanisms normally provide.

The macOS infection chain uses similar anti-analysis techniques, checking for debuggers, instrumentation tools, packet capture utilities and VMware artifacts before retrieving an additional beacon payload. The malware establishes persistence through a LaunchAgent using filenames deliberately chosen to resemble legitimate Apple services. This technique exploits an administrator's familiarity with `com.apple` naming conventions, although genuine Apple components should reside in expected system locations and carry appropriate signatures.

Security teams managing Macs should therefore evaluate both the process name and its filesystem location. A binary named `com.apple.runtime` stored inside a user's `.local` directory or a LaunchAgent named `com.apple.windowserver.helper` created in the user's Library should not be trusted merely because its name resembles Apple software. Endpoint tools can identify these discrepancies by validating signatures, paths and parent processes together.

The Linux payload is a UPX-packed ELF executable that eventually leads to deployment of Sliver, according to analysis referenced by researchers. Sliver is a legitimate open-source command-and-control framework developed for penetration testing and red-team operations, but it has also become popular among criminal and state-linked attackers because it provides mature remote-control capabilities without requiring development of a proprietary implant. Once deployed, such a framework can give attackers interactive command execution, file transfer and additional post-exploitation functionality.

The abuse of legitimate offensive-security tools illustrates why defenders cannot classify software based solely on whether it has a legitimate origin. Cobalt Strike, Sliver and commercial remote-management tools all have valid purposes, yet attackers routinely use them because they provide tested capabilities and may blend into security environments more effectively than unfamiliar custom malware. Detection should focus on how and where the tool appears rather than treating the software name itself as proof of malicious or legitimate intent.

The campaign appears related to an earlier operation referred to as Moika, in which more than 250 npm packages were published during April and May 2026. Researchers identified similarities in naming, telemetry camouflage, infrastructure patterns and targeting themes. If the relationship is correct, the growth from hundreds of packages to nearly 800 or more suggests that the operators are scaling their package-publishing infrastructure rather than conducting one short-lived experiment.

Mass package publication changes the economics of typosquatting. Traditional attacks often create one or a few packages that imitate a popular dependency with a slightly misspelled name. Publishing hundreds of packages allows attackers to occupy a much larger namespace and increases the probability of accidental discovery. Some package names may also target terms generated by AI coding assistants, where developers accept package recommendations without independently verifying that the suggested library is well established.

This emerging problem is sometimes described as slopsquatting. Generative AI systems can hallucinate package names that sound plausible but do not actually exist. Attackers can monitor or predict these hallucinated names, register corresponding packages and wait for developers to install them. A developer asking an AI assistant for a library recommendation may therefore receive a syntactically convincing but nonexistent package name that has subsequently been claimed by an attacker.

The risk reinforces an increasingly important principle for AI-assisted software development: generated dependency names must be verified independently before installation. Developers should confirm that packages exist in official registries, have meaningful publication histories, recognizable maintainers and legitimate repositories. AI-generated code should never be permitted to introduce new dependencies into production automatically simply because the package name appears plausible.

Organizations should consider enforcing approved dependency lists or private package registries rather than allowing every developer and CI/CD job unrestricted access to the public npm ecosystem. Internal repositories can proxy approved packages and block newly published or unknown dependencies until they have passed security review. This creates some administrative overhead but significantly reduces the chance that one mistaken package name results in arbitrary code execution across developer systems.

Dependency lockfiles provide another useful control by preventing package versions from changing unexpectedly after review. However, lockfiles protect only when the original dependency selection was legitimate. If the malicious package is intentionally added to `package.json` and locked, the lockfile faithfully preserves the attacker-controlled package. Security review must therefore occur before approval, not merely after version resolution.

Organizations should maintain a software bill of materials or equivalent dependency inventory so they can determine quickly whether any of the identified packages have entered applications or build environments. Large enterprises may have thousands of Node.js projects, making manual searching difficult. Central package telemetry and repository scanning can identify references to malicious package names across source repositories and artifact caches.

Simply removing the dependency from `package.json` is not sufficient if it was previously imported. Once the package executes, native malware may persist independently of npm. Incident responders should therefore treat the presence of any package from the campaign as evidence of potential endpoint compromise rather than merely a dependency hygiene problem.

Affected systems should be examined for suspicious temporary executables, analytics marker files, unusual LaunchAgents, scheduled tasks and Registry Run entries associated with the campaign. Network logs should be searched for connections to the identified Cloudflare Worker infrastructure and DNS TXT queries toward the `wel1.ru` delivery domains. Because attackers can rotate infrastructure, behavioural indicators should receive equal or greater priority than static domain blocklists.

Developer workstations deserve particularly careful investigation because they often contain credentials with significant enterprise value. A compromised developer machine may expose GitHub or GitLab access tokens, SSH keys, package-publishing credentials, cloud accounts and local copies of proprietary source code. An attacker who initially compromises the workstation through npm malware may therefore move into the software supply chain and compromise additional repositories or packages.

CI/CD runners are even more sensitive because they frequently operate with automated secrets required to build, sign and deploy software. A malicious dependency executing within a pipeline may access environment variables, registry credentials, GitHub Actions tokens or cloud deployment keys without first compromising a human account. This can convert a package-registry attack into a broader software supply-chain incident affecting downstream customers.

Build systems should therefore use short-lived credentials with the narrowest possible permissions and expose secrets only to the stages that genuinely require them. A dependency installation or test stage should not automatically receive production deployment credentials. Separating build stages limits the value of compromising an early dependency-processing step.

Ephemeral CI runners can reduce persistence because each build begins from a clean environment, but they do not prevent credential theft during the build itself. A malicious npm package can execute, collect secrets and transmit them before the runner is destroyed. Ephemeral infrastructure therefore needs outbound network controls and secret minimization in addition to disposable execution environments.

Outbound network restrictions can substantially reduce the effectiveness of package malware. Developer and build systems rarely need unrestricted access to every internet destination. Organizations can allow approved package repositories and required development services while blocking arbitrary Cloudflare Workers, newly registered domains and direct DNS resolution where not necessary. Such controls must be designed carefully because cloud development workflows legitimately use many external services, but completely unrestricted egress gives malicious dependencies an easy route to retrieve second stages and exfiltrate credentials.

DNS should be forced through approved enterprise resolvers so suspicious TXT queries can be logged and blocked. Systems capable of sending DNS requests directly to external resolvers can bypass central monitoring. Firewall policies should prevent unauthorized outbound DNS and encrypted DNS where corporate policy requires visibility.

Package reputation should also consider age and publication velocity. A newly created package with minimal downloads, no meaningful repository history and a version number that suddenly appears highly mature should receive additional scrutiny. The example package analysed by OpenSourceMalware presented itself as a mobile checkout SDK despite containing little meaningful functionality. Automated scoring can identify discrepancies between claimed purpose, package history and actual behaviour.

Static code analysis can detect imports that immediately trigger network requests or spawn child processes. A library described as formatting data or providing a simple SDK has little reason to determine the host CPU architecture, download an executable and invoke `/bin/sh` or `cmd.exe`. Security tooling can flag these behaviours even when the package name itself has never previously been identified as malicious.

Runtime controls provide another layer because static analysis can be evaded through obfuscation or delayed execution. Endpoint monitoring should identify Node.js processes writing native executables to temporary directories and launching them through shells. Such behaviour may occasionally be legitimate during native package installation, but it is unusual enough to warrant correlation with package origin and developer activity.

The cross-platform design of this campaign is also a warning against treating developer operating systems differently according to outdated assumptions. Windows, Linux and macOS are all explicitly supported by the downloader. Attackers are not choosing one platform because developers increasingly work across all three, and the valuable target is the development identity and credentials rather than the desktop operating system itself.

The macOS support is particularly notable because Macs are widely used by software engineers and may contain high-value Git, cloud and production credentials. Linux systems dominate CI/CD and cloud infrastructure, while Windows remains common in enterprise development. Supporting all three gives the attacker access to virtually the entire modern software-development chain.

The campaign also demonstrates how legitimate cloud and internet infrastructure can provide redundancy for malware. Cloudflare Workers deliver the primary executable, DNS supplies a fallback path, and open-source offensive tools provide post-exploitation capabilities. None of these technologies was designed for malicious activity, but attackers combine them because each one provides reliability, scalability or camouflage.

Security architectures should therefore avoid simplistic allowlisting based solely on provider reputation. Traffic to a major cloud provider is not automatically safe, just as a package from npm is not automatically trustworthy merely because it appears in the official registry. Trust must be applied to specific applications, packages, identities and destinations rather than inherited from the platform hosting them.

npm and other public repositories face an increasingly difficult moderation challenge because creating and publishing packages is intentionally easy. Open ecosystems benefit enormously from low barriers to contribution, but attackers exploit the same openness to publish large batches of disposable packages. Registry operators need automated behavioural analysis capable of identifying coordinated publication patterns, suspicious package similarity and malware-like execution before packages accumulate significant downloads.

Removing known malicious packages is necessary but reactive. Attackers can change names and republish the same payload quickly. Registry-level detection should examine common code fragments, infrastructure, maintainer relationships and publication timing so that a campaign can be disrupted as a cluster rather than requiring individual reports for hundreds of packages.

Organizations should also consider maintaining internal mirrors that can quarantine packages when an upstream dependency is later identified as malicious. A package already cached inside an enterprise repository may remain available even after npm removes it publicly. Security teams need processes for revoking known malicious versions from internal artifact stores and identifying applications that previously downloaded them.

The incident-response process should include credential rotation when package execution is confirmed. Development tokens, Git credentials, cloud keys, npm publishing tokens and SSH keys accessible from the affected host should be assumed potentially exposed. Secrets should be rotated from a known-clean system after the infected endpoint has been isolated.

Repository audit logs should then be examined for unexpected clones, token use, commits or workflow modifications following the suspected compromise. Attackers may use stolen developer credentials to create persistence through source repositories or CI/CD configurations even after the original endpoint malware has been removed.

Organizations publishing their own npm packages should protect maintainer accounts with phishing-resistant multi-factor authentication and narrowly scoped automation tokens. While this particular campaign relied largely on malicious new package names rather than confirmed takeover of established packages, stolen publisher credentials could allow attackers to move from typosquatting to poisoning trusted dependencies.

The broader cybersecurity lesson from this campaign is that open-source dependency management has become part of endpoint and supply-chain security. Installing a package is not equivalent to downloading passive source code. It is often equivalent to granting third-party code execution inside a developer workstation, build system or production application.

The absence of lifecycle scripts does not make an npm package safe, just as the presence of a professional README or plausible telemetry code does not prove legitimacy. Developers must evaluate what a dependency does when imported, what network access it requires and whether its origin can be trusted.

The DNS fallback is especially instructive because it demonstrates how attackers design redundancy from the beginning. Blocking one malicious domain or delivery mechanism may not stop a professionally constructed campaign. Defenders need to understand the complete execution chain and prevent both the initial dependency compromise and the secondary payload delivery.

Organizations should respond by searching source repositories and package inventories for identified malicious dependencies, hunting endpoints for associated execution artifacts, reviewing DNS and outbound network logs, and rotating development credentials where execution occurred. They should also strengthen package approval, dependency provenance and egress controls so the next cluster of malicious packages does not need to be individually known before it can be stopped.

Nearly 800 malicious packages are alarming, but the larger problem is that the campaign demonstrates how cheaply attackers can manufacture package identities at scale. The defensive challenge is therefore not to memorize hundreds of malicious names. It is to ensure that an unknown dependency cannot quietly progress from one `require()` statement to native malware execution and then into the credentials that control the organization’s software supply chain.

The Head Mare hacktivist group has been exploiting vulnerabilities in unpatched TrueConf video conferencing servers to replace client installers with malicious versions that deliver backdoors. [...]

Source: Hackers breach TrueConf to trojanize client installers with backdoors via Bleeping Computer — published 08 Aug 2026.