Hackers Abuse GitHub Actions to Backdoor Trusted AsyncAPI npm Packages

A newly uncovered software supply-chain attack shows why downloading a package from a familiar name is no longer enough to guarantee that the code is safe. Attackers reportedly compromised part of AsyncAPI's release workflow and used its legitimate npm publishing process to distribute malicious versions of several trusted packages. Rather than creating imitation packages under suspicious accounts, the attackers managed to place harmful code inside packages published through the project's expected npm namespace.

The affected code was linked to Miasma, a malware family capable of providing remote access to compromised development systems. The incident is particularly concerning because the packages may run inside developer workstations, automated build servers, documentation systems and CI/CD pipelines where sensitive credentials are often available.

This Was Not a Typical Fake-Package Attack

Many npm supply-chain incidents begin with typosquatting. An attacker publishes a package with a name that looks almost identical to a popular dependency, hoping that developers will install it by mistake.

This campaign took a more dangerous route.

The malicious packages came from the legitimate AsyncAPI namespace and were released through the project's own automated publishing process. To users and dependency-management tools, they could appear no different from an ordinary software update.

That distinction matters because many security checks rely heavily on package names, publisher identities and official release channels. In this case, those signals were not sufficient because the trusted process itself had reportedly been compromised.

A Vulnerable GitHub Actions Workflow Opened the Door

The attack began with an unsafe GitHub Actions configuration that allowed content from an untrusted pull request to interact with a privileged workflow environment.

This reportedly gave the attacker an opportunity to obtain or misuse an AsyncAPI automation identity. The attacker then introduced unauthorized changes into a branch connected to the project's release process, while making the activity resemble normal development work.

AsyncAPI's automated publishing workflow subsequently released the modified packages to npm.

This highlights one of the most serious risks associated with improperly secured CI/CD systems: an attacker may not need direct access to every developer account if they can manipulate a workflow that already has permission to modify code, publish packages or access secrets.

Why pull_request_target Requires Special Care

GitHub Actions workflows triggered through pull_request_target can be useful because they run within the context of the target repository rather than the contributor's fork.

That also makes them sensitive.

When such a workflow checks out or executes code supplied through an untrusted pull request while retaining access to privileged tokens or secrets, an attacker may be able to cross the boundary between untrusted contribution content and the trusted repository environment.

The issue is therefore not that GitHub Actions is inherently unsafe. The danger comes from combining untrusted code with permissions, credentials or automation identities that can perform sensitive actions.

Any workflow handling external pull requests should be designed so that unreviewed code cannot access publishing tokens, cloud credentials or repository write permissions.

Malware Waited Until the Package Was Imported

One of the more unusual characteristics of this campaign was that the malware did not rely on familiar npm lifecycle scripts such as postinstall.

Instead, the malicious JavaScript was designed to execute when the affected module was imported.

That means installing the package alone might not immediately trigger the payload. It could remain inactive until the module was later loaded by an application, build process, documentation generator or CI/CD task.

This behaviour can make detection more difficult.

A security team might examine installation logs and see no suspicious lifecycle script. The actual execution may occur hours or days later when a developer builds the project or an automated pipeline loads the dependency.

It also means investigators need to determine not only whether an affected version was downloaded, but whether it was actually imported or executed.

The Payload Created a Detached Node.js Process

Once triggered, the first-stage JavaScript launched a detached Node.js process and attempted to download an encrypted secondary payload through the InterPlanetary File System, better known as IPFS.

Running as a detached process allows the malware to continue operating independently of the application or terminal session that originally loaded the compromised package.

Researchers reported that the secondary payload could:

Based on the configuration examined during the investigation, the malware behaved primarily like a remote-access Trojan rather than a self-propagating worm.

That means infection of one computer would not necessarily cause automatic spread to every connected system. However, an attacker with remote-command access to a development workstation or build server could still use stolen credentials and trusted access to move deeper into an organization.

Ethereum Was Used as a Backup Configuration Channel

The malware also used an Ethereum smart contract as an alternative source of command-and-control information.

The contract could provide updated server addresses, relay information and other bootstrap configuration if the main communication infrastructure became unavailable.

This technique makes disruption more difficult because blockchain data is distributed and cannot be removed as easily as a conventional web page or centralized server.

The attacker does not necessarily need to send commands directly through the blockchain. Instead, the contract can act as a resilient directory telling the malware where its current command infrastructure can be found.

Similar methods have appeared in other malware campaigns because public blockchain networks can provide attackers with a durable and globally accessible configuration channel.

Affected AsyncAPI Packages

The advisory identifies five malicious package versions:

These versions should be checked across package manifests, lockfiles, dependency caches, container images and existing build artifacts.

It is not enough to update the package in the main project directory. Older copies may still exist in cached CI/CD environments, archived builds, developer workspaces or prebuilt container layers.

Millions of Weekly Downloads Increased the Potential Exposure

The affected packages reportedly had a combined reach of approximately 2.9 million downloads per week.

That figure illustrates how widely used the packages were, but it should not be interpreted as 2.9 million confirmed infections. A package download can be generated by automated builds, mirrors, repeated installations or systems that never actually executed the malicious code.

The real number of compromised systems may therefore be much lower.

Even so, the potential impact remains serious because software-development environments commonly store high-value information, including:

A single compromised developer workstation or build runner may provide an attacker with a route into additional repositories and deployment systems.

What Development Teams Should Check Immediately

Organizations using AsyncAPI packages should begin by searching all repositories and build environments for the affected versions.

The investigation should include:

Teams should then determine whether the packages were merely present or whether an application, build command or pipeline imported them.

The advisory specifically recommends looking for the NodeJS/sync.js payload and unexplained detached Node.js processes, reviewing outbound network connections, inspecting repository audit logs and examining CI/CD activity.

Known Malware File Locations

The payload may appear in different locations depending on the operating system:

Finding the file would be a strong reason to isolate the affected system and begin a formal incident-response investigation.

Its absence, however, should not automatically be treated as proof that the system is clean. Attackers may remove files, change paths or deploy updated variants after an initial compromise.

Credentials Should Be Treated as Potentially Exposed

Any credential available to an affected workstation or CI/CD runner should be reviewed and potentially rotated.

This may include GitHub tokens, npm tokens, cloud API keys, deployment credentials, SSH keys and secrets stored in environment variables.

Credential rotation should take place after the affected system has been contained or rebuilt. Rotating secrets while the attacker may still have access could simply expose the new credentials as well.

Teams should also review where those credentials were used. Repository audit logs, cloud access logs and package-publishing history may reveal whether an attacker attempted to use them elsewhere.

Network Indicators Can Support Threat Hunting

The advisory lists several indicators that defenders can use during investigation, including the IPFS gateway ipfs.io, the paste-style service rentry.co and command infrastructure associated with 85.137.53[.]71 on several ports.

These indicators can be searched across:

A match does not always confirm infection. For example, ipfs.io is a legitimate service that may be accessed for harmless reasons.

Indicators should therefore be evaluated alongside process behaviour, file activity, timing and the presence of affected packages.

Review GitHub Actions Before the Next Attack

Removing the malicious dependency addresses the immediate risk, but organizations should also review the workflow weakness that made the campaign possible.

Privileged GitHub Actions workflows should follow several basic principles:

Release automation is effectively part of the organization's privileged infrastructure. It should receive the same level of security review as a production server or administrative account.

The Attack Followed Several Recognized Techniques

The activity described in the advisory maps to multiple MITRE ATT&CK techniques, including software supply-chain compromise, JavaScript execution, ingress tool transfer, obfuscated files, hidden artifacts, persistence through system services, Unix shell execution and data exfiltration over command-and-control channels.

This combination suggests that the campaign was designed to do more than simply execute one malicious command.

It included mechanisms for gaining initial access, hiding its presence, maintaining persistence, receiving additional tools and transferring information back to the attacker.

That broader behaviour is why affected systems should not be cleaned by deleting one file alone. A full investigation or trusted rebuild may be necessary.

Final Thoughts

This incident is a reminder that software supply-chain security cannot stop at checking whether a package name looks legitimate.

The compromised AsyncAPI versions were reportedly published through a trusted namespace and an expected release process. From a developer's perspective, they may have appeared to be ordinary updates.

The deeper problem was the security boundary around the automation responsible for publishing those updates.

Organizations should treat CI/CD pipelines, GitHub Actions workflows and package-publishing identities as high-value systems. A weakness in any one of them can allow attackers to distribute malicious code through channels that developers already trust.

The most important response is therefore twofold: identify and investigate the affected package versions, then strengthen the release workflows and credentials that could otherwise make the next supply-chain attack just as convincing.