Attackers infiltrated n8n's community node ecosystem this week with a malicious npm package that masqueraded as a Google Ads integration. The package, n8n-nodes-hfgjf-irtuinvcm-lasdqewriit, tricked developers into entering OAuth credentials through what appeared to be a legitimate credential form, then silently exfiltrated them during workflow execution to an attacker-controlled server. This novel supply chain attack—targeting users beyond n8n's recently disclosed remote code execution (RCE) flaws—demonstrates how threat actors are exploiting trust in community-maintained integrations.

Multiple malicious packages have been removed from the npm registry, one of them is tracked through GHSA-77g5-qpc3-x24r. But even if known malicious packages (see here) were taken down, it doesn’t mean attackers won’t continue to use this tactic.

The attack represents a significant escalation in supply chain threats. Unlike traditional npm malware that targets individual credentials, this campaign exploited workflow automation platforms that act as centralized credential vaults—holding OAuth tokens, API keys, and sensitive credentials for dozens of integrated services like Google Ads, Stripe, and Salesforce in a single location. By compromising a single community node, attackers gained a gateway into victims' entire connected digital ecosystems.

This mirrors the tactics we saw in the Shai-Hulud campaign that abused GitHub Actions workflows, which ultimately pushed GitHub to tighten npm security controls. Attackers are now expanding beyond traditional ecosystems into workflow automation platforms, where security scrutiny is often lower but the credential exposure is far greater.

This blog is a deep-dive into how attackers weaponize n8n workflow automation platforms to steal credentials, and walks through an example of credential theft npm malware package abusing n8n via community nodes. 

Why n8n is an attractive target

Before looking at the attack itself, it helps to understand why n8n is such an attractive and high-risk target for supply chain attacks. n8n is built on Node.js and depends heavily on npm, not just for its core installation but also for extending functionality through community nodes. These nodes are published as npm packages, installed directly into the n8n environment, and executed as part of active workflows. In practice, this means that any npm package installed for n8n becomes trusted code inside the automation platform. 

According to security researchers at data security company Cyera, there were more than 100,000 n8n servers vulnerable to CVE-2026-21858. However, it is unclear how many of those install random npm packages as community nodes in their environments.Still, it shows that the n8n ecosystem is active and thriving.

The n8n’s community node ecosystem offers powerful flexibility but introduces significant supply chain risk for the following reasons:

• No code review: npm packages are not audited before being listed
• Trust inheritance: Users trust n8n, and that trust implicitly extends to community nodes
• Credential access: Nodes receive decrypted credentials at runtime
• Network access: Nodes can make arbitrary outbound HTTP requests
• System access: Nodes run in Node.js with full operating system access

Community nodes run with the same level of access as n8n itself. They can read environment variables, access the file system, make outbound network requests, and, most critically, receive decrypted API keys and OAuth tokens during workflow execution. There is no sandboxing or isolation between node code and the n8n runtime.

Because of this, a single malicious npm package is enough to gain deep visibility into workflows, steal credentials, and communicate externally without raising immediate suspicion. For attackers, the npm supply chain offers a quiet and highly effective entry point into n8n environments.

Affected packages and indicators of compromise

Indicators of Compromise (IOC) Summary

Package Name: n8n-nodes-hfgjf-irtuinvcm-lasdqewriit

C2 Domain: n8n-license-validator.onrender.com

C2 Endpoint: /validate-license (POST)

C2 Hosting: onrender.com

Malicious Files

1. dist/nodes/GoogleNode/GoogleNode.node.js - b435f95ad1dc9b1830798b2ed0dd2c891ef158dd7b622bd135c2214c26fe7998
2. dist/nodes/GoogleNode/handlers/shared/GoogleAdsClient.js - f458ee2b1cf41e00de31e1bb727a876f6927ac61d53a502817180f6b8ebbb72b
3. dist/credentials/GoogleAdsApi.credentials.js - 38931ec67a3ebdb344fd0a2c92865cc3cfb07e8e6d161c91ad36425c11fb0ef6

Similar packages

Below is a list of additional malicious packages identified by Endor Labs that target the n8n ecosystem:

How to reduce change of exposure to n8n attacks

Users should follow these practices:

• Use official nodes, prefer n8n's built-in integrations
• Audit packages before installing them by reviewing source code on npm or GitHub
• Scrutinize package metadata for red flags such as empty descriptions, random names, low download counts, or missing documentation, and prefer official n8n integrations whenever possible. 
• Monitor outbound network traffic from n8n instances can help detect suspicious activity
• Use isolated service accounts with the least privileges required to minimize credential risk.

Attack analysis

Here's the attack sequence we reconstructed:

1. Attacker publishes the malicious package to npm
2. Victim installs it as a community node in n8n
3. Plugin configuration form collects real Google Ads OAuth tokens and saves to n8n credential store.
4. Credentials get decrypted from the n8n credential store at runtime and exfiltrated to the attacker's server.

Malicious NPM package analysis

Below is a screenshot of the malicious npm package as listed in the npm registry. Despite having 2,500+ downloads, the package lacks a clear description or README and has 32 published versions, which is a strong red flag.

Installation as a community node

n8n allows users to extend its functionality by installing "community nodes", npm packages that follow n8n's node specification, below is the image of installing n8n community package via GUI.

Once installed, n8n automatically discovers the node by reading its package.json file. The node appears in the workflow editor alongside legitimate integrations, indistinguishable from official nodes

When a user adds the "Google Ads" node to their workflow, they're prompted to configure credentials, below is the form request to configure the plugin.

Aside: how credentials are stored in n8n ecosystem

When users click "Save" after filling the configuration form, n8n performs the following:

• Validation: Basic field validation (required fields, format)
• Encryption: Credentials are encrypted using AES-256
• Storage: Encrypted blob is saved to ~/.n8n/database.sqlite
• Reference: A credential ID is linked to the node in the workflow

At this point, the credentials are safely encrypted and stored in n8n ecosystem. The attack doesn't happen during storage, it happens during execution.

File structure of the npm package

The npm package.json file serves as n8n's entry point, explicitly declaring which credential forms and node executables to load into the workflow editor. The fields specific to n8n workflow mentioned in package.json file are:

• n8n.credentials: Defines the credential form schema (doesn't have any credentials, just the schema file)
• n8n.nodes: Defines the executable node logic
• scripts.build: Build process
• prepublishOnly: Automatically runs before npm publish

The attacker made a fatal mistake: they included .js.map files in the published package. Source maps are designed to help debuggers map minified/obfuscated code back to the original source. This allowed us to fully reconstruct the original TypeScript code.

‍

Execution flow

When a user clicks "Execute Workflow" in n8n, the framework executes dist/nodes/GoogleNode/GoogleNode.node.js as mentioned in n8n.nodes field in package.json which internally call the execute() method of each node in the workflow. This function has 2 steps (see below for details):

1. Retrieve the credentials stored in n8n environment
2. Data exfiltration

Step 1: Retrieve the credentials stored in n8n environment

The this.getCredentials('googleAdsOAuth2Api') call is a standard n8n API that:

1. Looks up the credential reference from the workflow in n8n environment
2. Retrieves the encrypted blob from SQLite
3. Decrypts the credentials using n8n's master key
4. Returns a plain JavaScript object

The attacker receives:

credentials = {    
	licenseKey: "user-entered-value",
    developerToken: "XXXXXXXXXXXXXXXX",    // Real Google token    
    clientId: "xxxxx.apps.googleusercontent.com",  // OAuth cred    
    clientSecret: "GOCSPX-XXXXXXXXX",      // OAuth cred    
    refreshToken: "1//XXXXXXXXXXXXXXX",    // OAuth cred - persistent access!    
    loginCustomerId: "123-456-7890"        // Account identifier
 }

This is the critical moment: n8n trusts the node code to handle credentials responsibly. The malicious node exploits this trust, which is similar to the Shai-Hulud campaign's exploitation of GitHub Actions workflows, where attackers leveraged pull_request_target’ triggers and ${{ toJSON(secrets)}} expressions to dump environment variables and repository secrets. This attack weaponizes n8n's legitimate extensibility mechanism for credential theft. 

For additional background on the Shai-Hulud campaign, read our analysis in Shai-Hulud 2 Malware Campaign Targets GitHub and Cloud Credentials Using Bun Runtime..

Step 2: Data exfiltration

The core malicious logic resides in GoogleAdsClient.js, it collects system information (MAC address and hostname) and exfiltrates ALL credentials to C2 server. 

Conclusion

Automation is a double-edged sword. On the positive side, the rise of workflow automation platforms such as n8n, Zapier, and Make has fundamentally changed how organizations operate. Marketing teams can synchronize campaigns without writing code. DevOps teams can orchestrate deployments using visual workflows. Data analysts can build ETL pipelines in minutes instead of days.

However, this convenience comes at a cost. Every integration introduces a new attack surface.

When a workflow node is granted access to Google Ads credentials, the organization is implicitly trusting the node’s author with its advertising budget. Installing a community node means executing third-party code on internal infrastructure. Importing a prebuilt workflow inherits not only functionality, but also someone else’s security assumptions.

The malicious package analyzed in this report n8n-nodes-hfgjf-irtuinvcm-lasdqewriit was not particularly advanced. It relied on basic JavaScript obfuscation, exposed source maps, and used a single hardcoded command-and-control domain. Despite these shortcomings, it would likely have succeeded against the majority of organizations.

While automation accelerates business workflows, it also expands the attack surface. Organizations must balance convenience against the security implications of community-provided integrations.