The discovery of 18 malicious npm packages targeting users of Alibaba developer tools demonstrates how software supply-chain attacks are becoming more targeted, modular and capable of compromising development environments across Windows, Linux and macOS. 

The malicious packages were designed to resemble internal packages associated with Alibaba’s private `@ali` npm scope. Rather than attacking a broad population of ordinary internet users, the campaign appears to have focused on developers working within Alibaba-related environments or organizations using similar internal development tools.

Once installed, the packages activated a layered malware-delivery chain that ultimately deployed a sophisticated cross-platform remote-access trojan. The final payload could execute commands, upload and download files, collect information about the infected system, stage additional malware and support movement into connected systems.

The campaign illustrates why developer workstations and software dependencies have become valuable targets. Developers frequently possess access to source-code repositories, cloud platforms, CI/CD systems, internal applications, deployment credentials and production infrastructure. Compromising one developer can therefore provide an attacker with far more than control of a single endpoint.

The packages impersonated internal Alibaba tools

One of the packages involved in the campaign was `lib-mtop`, an unscoped npm package using the same name as a private Alibaba package published under the `@ali` scope.

The public package was initially published in November 2023 without meaningful functionality. New versions containing malicious behaviour were later uploaded during March and April 2026.

Researchers could not conclusively determine whether the original maintainer account had been compromised or whether the publisher intentionally introduced the malicious changes. Regardless of how the packages were altered, the new versions included functionality that downloaded and executed remote JavaScript code.

The same npm maintainer account also published packages named `aone-kit`, `aone-kit-cli`, `aone-sandbox` and `local-config-parser`. Several of these packages shared names with private Alibaba-scoped packages and depended on the legitimate private versions.

This gave the malicious packages an appearance of authenticity. A developer searching for an internal tool, working with incomplete documentation or copying a package name without its scope could install the attacker-controlled public package instead.

The technique differs slightly from traditional dependency confusion, where a package manager automatically selects a public package instead of a private dependency. In this campaign, the public packages acted as wrappers or decoys that still loaded the legitimate private dependency while quietly adding malicious functionality through additional packages.

The application could therefore continue behaving as expected, reducing the chance that the developer would immediately notice anything unusual.

Malicious behaviour was divided across multiple dependencies

The attack did not place the entire malware loader inside one obviously suspicious npm package. Instead, the functionality was distributed across several packages within the dependency tree.

Top-level packages impersonated private Alibaba tools and initiated installation of the remaining dependencies. A package called `smart-config-manager` acted as a middle-layer bridge between the lure packages and lower-level packages containing the actual loader components.

Another package contacted a GitHub repository and downloaded what appeared to be a rule-engine configuration. That configuration was then processed through Node.js functionality capable of executing JavaScript inside a virtual-machine context.

The rule engine eventually triggered the download of a secondary payload from remote infrastructure controlled by the attackers.

Dividing the attack across several packages made analysis more difficult because no single dependency necessarily contained the complete malicious sequence. One package appeared to provide configuration handling, another retrieved a rules file, and another executed the resulting instructions.

Security tools inspecting packages individually may therefore classify each component as low risk while failing to recognise the malicious behaviour that appears when they operate together.

This modular design also gives attackers flexibility. Individual components can be changed, removed or replaced without rebuilding the complete campaign. A top-level lure package may look harmless while the malicious functionality remains hidden several levels deeper in the dependency graph.

Organizations must therefore assess complete dependency trees rather than reviewing only the package that a developer explicitly requested.

Installation scripts provide automatic execution

npm packages can define lifecycle scripts that execute automatically during installation. These scripts support legitimate tasks such as compiling native components, generating files and preparing the package for use.

Attackers abuse the same mechanism to execute code as soon as a developer or automated build process installs a malicious dependency.

The victim may not need to import the package, run a function or start an application. The malicious activity can begin during `npm install`, often before anyone reviews the package’s source code.

This creates particular risk in CI/CD pipelines, where dependencies may be installed automatically whenever a project is built or deployed. A malicious package could therefore execute inside a build runner containing cloud credentials, repository tokens, signing keys and deployment secrets.

Package installation should never be treated as passive file retrieval. It can involve immediate code execution with the permissions of the user or automation account running the command.

Organizations should restrict lifecycle scripts where practical, review packages that require them and isolate dependency installation from sensitive credentials and production systems.

A domain resembling Alibaba infrastructure concealed the payload

The malware downloaded its secondary payload from a domain designed to resemble legitimate Alibaba cloud infrastructure.

The hostname used terminology associated with Alibaba’s Aone tooling and was placed under an Aliyun Object Storage Service domain. This gave the traffic a stronger appearance of legitimacy than communication with an unfamiliar or newly registered attacker domain.

Developers working with Alibaba products may reasonably expect their tools to communicate with Alibaba Cloud services. Security teams may also be reluctant to block such traffic because the wider domain belongs to a legitimate cloud platform.

Attackers increasingly abuse trusted hosting services, code repositories and cloud-storage platforms because those destinations are commonly permitted through enterprise networks.

Domain reputation alone is therefore insufficient. A connection to a legitimate cloud provider does not guarantee that the specific account, storage bucket or object being accessed is trustworthy.

Security monitoring must consider which process initiated the connection, which package created it, when it occurred and whether the requested object is consistent with the application’s expected behaviour.

An npm installation process downloading executable content from an unfamiliar storage location deserves scrutiny even when the parent cloud domain is legitimate.

The payload adapted itself to the victim’s operating system

The malicious rule engine identified whether the infected system was running Windows, Linux or macOS and selected an appropriate payload and persistence method.

Cross-platform capability significantly increases the campaign’s potential reach because modern development teams frequently use a mixture of operating systems. Developers may use macOS laptops, Linux workstations, Windows endpoints and Linux-based CI/CD runners within the same organization.

An attacker targeting only one platform would risk losing access when the package was installed elsewhere. By providing separate execution paths, the campaign could compromise a broader range of developer and build environments.

The platform-specific behaviour also demonstrates that the operation was not a simple proof of concept. The attackers developed tailored methods for interfering with applications, maintaining persistence and hiding execution on each supported operating system.

Windows systems faced application replacement

On Windows, the malware attempted to terminate Alilang, an Alibaba enterprise application providing security, VPN and office-productivity functions. It then replaced parts of the application with a trojanized version.

This technique is particularly dangerous because the malicious code becomes associated with software that users already recognise and trust.

Replacing or modifying an enterprise application can provide persistence while making malicious activity appear to originate from an approved program. Security tools may also treat the application differently because of its expected role within the organization.

An attacker controlling a trusted enterprise communication or access application may gain opportunities to intercept information, execute code and interact with internal services using the application’s established permissions.

Organizations investigating affected Windows systems should verify the integrity and digital signatures of Alilang components and other applications that may have been modified. Reinstalling the npm package or deleting the project directory would not restore software that the malware altered elsewhere on the endpoint.

Linux payloads attempted fileless-style execution

On Linux, the campaign downloaded a binary payload into the `/tmp` directory, launched it as a detached process and deleted the original file after execution.

Temporary directories are convenient staging locations because legitimate applications frequently write files there, and their contents may receive less scrutiny than standard application directories.

Deleting the payload after it has been loaded does not necessarily stop the running process. On Linux, a process can continue operating even after the corresponding file has been removed from the filesystem.

This reduces the amount of evidence available during casual inspection. An administrator may search for the downloaded file and find nothing while the malicious process remains active in memory.

Endpoint monitoring should therefore record process execution and file events rather than relying only on periodic filesystem scans. Executables launched from `/tmp` or other writable directories should receive scrutiny, particularly when they follow npm installation or outbound downloads.

Incident responders should also examine memory, process trees, open network connections and deleted-but-still-running files when compromise is suspected.

macOS systems received shell and Launch Agent persistence

On macOS, the malware inserted a malicious background script into the user’s `.zshrc` file and created a Launch Agent configured to run every ten minutes.

The `.zshrc` file is executed whenever a user starts an interactive Z shell. Modifying it allows malicious commands to run repeatedly as the developer opens Terminal sessions.

Launch Agents are legitimate macOS mechanisms used to start user-level applications and background services. Attackers abuse them because they provide reliable execution after login and can be configured to run at regular intervals.

The ten-minute execution schedule would allow the malware to return even if one process was terminated. It could also check for updated instructions or re-establish communication with attacker infrastructure.

Organizations examining affected Macs should review shell configuration files, Launch Agent property lists, login items and unfamiliar files inside user Library directories.

Removing only the malicious npm package would not delete persistence established in the user’s shell profile or Launch Agent configuration.

The final RAT provided extensive attacker control

The final payload operated as a full-featured remote-access trojan rather than a simple downloader or credential stealer.

Its capabilities included remote command execution, arbitrary file upload and download, system reconnaissance, payload staging and lateral movement.

Remote command execution allows the attacker to run programs and scripts according to the opportunities available on the compromised system. File-transfer functionality can support both data theft and delivery of additional tools.

Reconnaissance helps the attacker identify the victim, operating system, installed software, network configuration and available credentials. This information can determine whether the compromised environment is valuable enough for continued attention.

Payload staging enables the RAT to retrieve additional malware after the initial infection. Attackers may deploy credential stealers, tunnelling utilities, keyloggers or tools for accessing internal systems.

Lateral-movement capability is especially concerning in a developer environment. Developers frequently connect to internal repositories, testing infrastructure and remote servers, creating routes that an attacker can attempt to reuse.

The final objective may therefore extend beyond stealing information from one workstation. The compromised developer endpoint can become an entry point into the wider software-development and enterprise environment.

The malware targeted enterprise collaboration applications

The malware could reportedly establish persistence by injecting malicious code into commonly used enterprise collaboration and development applications such as DingTalk, Wukong and Qoder.

These applications are likely to run frequently and may already be permitted to access corporate communication, project and development environments.

Injecting into commonly used software allows malicious functionality to blend with normal user activity. The malware can execute when the legitimate application starts and may inherit some of its trusted network access.

Collaboration platforms also contain valuable information, including employee identities, internal discussions, file attachments, project details and links to other systems.

A compromised collaboration application could help attackers understand organizational relationships and impersonate trusted colleagues. It may also support phishing or social engineering from accounts and systems already accepted within the organization.

Security teams should verify application integrity and investigate unexpected modifications, plugins or injected scripts in tools used by developers and employees.

The campaign appears targeted rather than widespread

The affected packages did not accumulate extremely high download numbers, but download counts alone may not reflect the seriousness of the campaign.

A targeted supply-chain attack does not require millions of installations. Compromising a small number of developers with privileged access to valuable systems may provide a far greater return than infecting thousands of ordinary users.

The package names and infrastructure indicate a focus on Chinese-speaking developers using Alibaba-related tools. Chinese-language comments within the malicious source code and GitHub activity aligned with the UTC+08:00 time zone suggest that the operator may also have been Chinese-speaking.

However, these indicators are not sufficient to establish the attacker’s nationality or organizational affiliation. Language, working hours and code comments can be misleading or intentionally planted.

The available evidence supports describing the campaign as targeted at Chinese-speaking Alibaba-tool users, but not conclusively attributing it to a particular country, company or government-linked group.

Researchers assessed that industrial espionage may be the likely objective. The malware’s focus on developer systems, internal tools and lateral movement is consistent with an operation seeking source code, corporate intelligence or access to internal infrastructure.

Developer endpoints are high-value targets

Developers often receive more technical freedom than ordinary employees because their work requires installing tools, running scripts and accessing multiple environments.

This flexibility creates a valuable attack surface. A developer may possess GitHub or GitLab tokens, SSH keys, cloud credentials, package-registry tokens, database passwords and access to CI/CD systems.

Many of these secrets are stored in environment variables, configuration files, shell histories and local credential stores. Malware running under the developer’s account may be able to collect them without exploiting an additional vulnerability.

A compromised source-code repository token can allow attackers to modify projects, publish malicious releases or access proprietary software. Stolen cloud credentials may provide access to production resources and sensitive data.

CI/CD credentials can be even more dangerous because build systems often have permission to publish software and deploy applications automatically.

Organizations should therefore treat developer workstations as privileged assets. They require strong endpoint protection, application control, secret management and network segmentation rather than fewer controls in the name of productivity.

Private package names should not be easily guessable or exposed

The campaign relied partly on knowledge of private package names associated with the `@ali` scope.

Private package names may be revealed through public source code, documentation, error messages, job postings, copied configuration files and accidental publication of lockfiles.

Once attackers learn the name of an internal dependency, they can create public packages that imitate it or use related naming to deceive developers.

Organizations should configure package managers so private scopes always resolve through approved internal registries. Public registries should not be allowed to satisfy internal package requests automatically.

Developers should use the complete scoped package name and avoid installing unscoped alternatives merely because documentation or an error message suggests a similar name.

Internal documentation should clearly identify the approved registry and package namespace. Uncertainty around how to obtain a private tool creates precisely the opportunity that attackers need.

Package sources should also be locked through configuration and repository controls so a project cannot silently switch from an internal dependency to a public imitation.

Dependency lockfiles reduce unexpected changes

Lockfiles record the precise package versions and integrity hashes used by a project. When properly maintained, they reduce the chance that an installation retrieves a newly published malicious version unexpectedly.

Organizations should require committed lockfiles and use deterministic installation commands such as `npm ci` in automated build environments.

However, lockfiles are not a complete defence. A malicious package may already be present when the lockfile is created, and developers can update dependencies without adequate review.

Attackers may also compromise an existing package version or maintainer account, although registry immutability controls can limit some forms of replacement.

Dependency changes should therefore be reviewed like source-code changes. Pull requests adding new packages, changing package sources or modifying lockfiles should receive security scrutiny.

Automated systems should identify newly introduced maintainers, unusual publication histories, install scripts and dependencies that do not match the package’s claimed purpose.

Package reputation cannot depend only on age

The `lib-mtop` package existed for several years before malicious versions appeared. Its earlier history may have made it appear less suspicious than a newly created package.

Attackers may publish dormant packages and wait before introducing malware, or they may compromise maintainers of legitimate existing projects.

Security assessments should therefore examine each new version rather than assuming an older package remains trustworthy forever.

A sudden addition of install scripts, remote downloads, obfuscated code or new dependencies should trigger review even when the package name has existed for years.

Organizations should monitor changes in package ownership and maintainer accounts. A new maintainer or unexpected publishing pattern may indicate account takeover or project transfer.

Version updates should be staged and tested rather than applied automatically to production development and build environments.

CI/CD environments require isolation

Build runners should operate in isolated, disposable environments with only the credentials required for the current job.

Long-lived self-hosted runners create greater risk because malware installed during one build may persist and affect future projects. Ephemeral runners reduce this persistence by destroying the environment after each job.

Secrets should be injected only into trusted workflows and should not be available during untrusted dependency installation where possible.

Network access from build environments should also be restricted. A package installation process should not automatically be able to communicate with arbitrary internet destinations or internal production systems.

Outbound allowlists, package proxies and internal artifact repositories can limit direct contact with untrusted infrastructure.

Build outputs should be signed and verified so downstream users can confirm that software came from an approved pipeline. However, signing provides limited value when attackers control the authorised build process itself, which is why protecting the pipeline remains essential.

Systems that installed the packages should be treated as compromised

Removing a malicious npm package is not sufficient because the loader may already have installed the final RAT and established operating-system persistence.

Affected organizations should isolate the developer workstation or build runner and preserve logs and forensic evidence.

The investigation should identify when the package was installed, which user or automation account executed it and which secrets were available at that time.

Security teams should inspect shell profiles, Launch Agents, Windows application files, Linux processes, temporary directories and enterprise applications that the malware may have modified.

Outbound connections to the campaign’s GitHub resources and payload infrastructure should be reviewed across network, proxy and DNS logs.

Where the integrity of the endpoint cannot be established confidently, rebuilding from a trusted image is safer than attempting limited cleanup.

Credentials must be rotated from a clean system

Every credential accessible to the compromised developer or build environment should be considered potentially exposed.

This may include source-code repository tokens, npm publishing tokens, SSH keys, cloud access keys, database credentials, CI/CD secrets and internal application passwords.

Credentials should be rotated only after the affected environment has been isolated. Changing them while malware remains active may simply expose the replacements.

Active sessions and authentication tokens should also be revoked. Password changes alone may not invalidate all forms of persistent access.

Organizations should examine whether stolen package-registry credentials were used to publish malicious versions of internal or public packages.

Code repositories should be reviewed for unauthorized commits, workflow changes, deploy keys and newly created access tokens.

Cloud logs should be examined for access from unfamiliar devices, locations and user agents beginning from the earliest suspected compromise.

Software released from an affected pipeline may require review

If a malicious package executed inside a build or release environment, organizations should evaluate whether produced software was modified.

The attacker may have changed source code, injected additional dependencies or altered build artifacts. A clean repository does not prove that previously produced binaries are trustworthy when the build environment itself was compromised.

Organizations should compare affected releases with reproducible builds from a clean environment where possible.

Published package versions, container images and software installers produced during the exposure period should be reviewed and potentially replaced.

Signing keys available within the compromised environment may also need rotation. Attackers who obtain a signing key can make malicious software appear officially authorised.

Customers and downstream users should be notified when there is credible evidence that distributed artifacts may have been affected.

Network monitoring can expose dependency-based attacks

Software supply-chain attacks still generate network activity that can provide valuable detection opportunities.

A package manager contacting an unfamiliar GitHub repository, remote JavaScript resource or object-storage location during installation should be investigated.

Security systems should establish expected communication patterns for developer tools and build environments. New destinations, unusual file downloads and executable content retrieved from cloud-storage services deserve scrutiny.

The initiating process is important. A browser accessing a cloud-storage object may be ordinary, while `node`, `npm` or a build runner retrieving executable payloads during dependency installation represents a different context.

Endpoint and network telemetry should be correlated. The combination of npm installation, remote script download, shell modification and persistent outbound communication provides much stronger evidence than any single alert.

Encrypted traffic may limit content inspection, but destination, process, timing and transfer behaviour can still reveal suspicious activity.

The wider cybersecurity lesson

The 18 malicious npm packages demonstrate how attackers can use open-source ecosystems to conduct precise attacks against developers working within specific organizations and technology communities.

The campaign did not depend on one obviously malicious package. It used trusted naming, private-package impersonation, layered dependencies, remote configuration and platform-specific payloads to conceal the complete attack chain.

This modular structure reflects the direction of modern supply-chain attacks. Malicious functionality is increasingly distributed across packages, infrastructure and runtime stages so that each component appears less suspicious when examined alone.

Organizations must respond by reviewing dependency relationships as complete systems. They need controlled package registries, deterministic builds, isolated CI/CD environments, lifecycle-script monitoring and strict protection of developer credentials.

Developers should not assume that a package is safe because it has a plausible name, performs some legitimate functionality or depends on an authentic internal tool.

Security must also continue after installation. Package-based malware can modify operating-system files, enterprise applications and shell configurations that remain active even after the original dependency is removed.

The incident reinforces why developers are attractive targets for industrial espionage and broader enterprise compromise. Their endpoints sit at the intersection of source code, credentials, cloud platforms and software distribution.

Compromising one developer dependency can therefore provide attackers with access not only to the developer’s machine but also to the systems, applications and users that trust the software they produce.

Open-source dependencies remain essential to modern development, but convenience cannot be allowed to replace verification. Every package introduced into a project extends the organization’s software supply chain and grants some level of trust to code written, maintained and distributed by someone else.

That trust should be limited, monitored and continuously reassessed. Otherwise, a package installed to simplify development may quietly provide attackers with a cross-platform remote administration system of their own.

Cybersecurity researchers have discovered a new set of malicious npm packages that target users of Alibaba developer tools with a cross-platform remote access trojan (RAT) as part of a sophisticated, targeted software supply chain attack targeting Chinese-speaking environments. One of the packages in question is "lib-mtop," an unscoped package with the same name as a private Alibaba package

Source: 18 Malicious npm Packages Deliver Cross-Platform RAT to Alibaba Tool Users via The Hacker News — published 03 Aug 2026.