在 n8n 中保证代理 AI 工作流: 从泄露的 API 密钥到加密密钥折中

Agentic AI expands the security boundary of workflow automation. An n8n agentic workflow does not just generate an answer. It uses stored credentials to act across source control, databases, cloud platforms, AI providers, and SaaS applications. A leaked n8n API key is therefore only the beginning of the attack path. At the center of that access is a single root of trust: the . Our research examined how an attacker could move from initial API access to that key and the credentials it protects. We found three weaknesses in the way n8n derives signing and session secrets, demonstrated how weak encryption keys can be recovered offline from public artifacts, and identified 129 internet-accessible instances using known weak keys. We also reproduced an attack using CVE-2026-25053 that allowed an API key associated with a sufficiently privileged account to be escalated into access to the encryption key and encrypted credential records. The result is a concrete picture of the risk behind agentic automation: the more systems an agent can reach, the more consequential a failure in its credential and execution layer becomes. This report traces the attack chain from exposed API credentials to encryption key compromise, then provides a hardened configuration designed to break it at multiple points. The is n8n's root of trust At the time of this research, n8n had received 48 CVEs since January 2026. Several allowed attackers to escape the workflow execution environment and gain code execution or filesystem access on the host. Once an attacker reaches the filesystem, two assets become primary targets: , which contains stored credentials in encrypted form on default SQLite deployments The , provided through the environment or stored in the n8n configuration, which decrypts them Together, they provide offline access to the plaintext value of every credential stored in the database. The encryption key also carries responsibilities beyond credential encryption. In the implementation we analyzed, it contributes to the secret used to sign JSON Web Tokens and to the value used to generate the public instance ID. Concentrating those functions in one key makes it the central trust anchor for an n8n instance. Compromising it can affect stored credentials, token integrity, session authentication, and the confidentiality of every connected integration. Our analysis identified three weaknesses in that trust model. Three weaknesses in n8n's key derivation and session authentication Flaw 1: JWT secret derivation discards half the key The JWT signing secret is derived from the by taking every other character. Under this derivation path, a 32-character encryption key produces a 16-character signing secret. Half of the input characters make no contribution to the derived value, reducing its effective entropy. The practical severity depends heavily on how the original encryption key was generated. A long, randomly generated key remains difficult to recover. A short or human-memorable value is much more vulnerable to offline guessing. Flaw 2: Sessions can be forged for OIDC-provisioned users For users provisioned through OpenID Connect, n8n stores the literal string in the password field. The session token is derived using this password value and the . Because the password component is known, an attacker who obtains or recovers the encryption key can reproduce the derivation and forge a session for an OIDC-provisioned user without knowing that user's identity provider password. Flaw 3: Sessions can be forged for pending users Invited users who have not completed registration have a null password value. During session derivation, JavaScript coerces that null value into an empty string. As with OIDC-provisioned users, the password component becomes predictable. An attacker with the encryption key can therefore derive a valid session token for a pending user without knowing a password. These weaknesses do not reveal the encryption key on their own. Their impact emerges when the key is exposed through a vulnerable host, recovered from weak key material, or obtained through another attack path. Recovering weak encryption keys offline The is often generated automatically, but self-hosted administrators can replace it with a custom value. When that value is human-memorable or follows a predictable pattern, public artifacts can make offline recovery possible. A leaked n8n JWT acts as a verification oracle. An attacker can generate a candidate encryption key, apply n8n's JWT secret derivation, and test whether the leaked token's signature verifies. A successful verification confirms that the candidate produces the correct signing secret. Before n8n v2.25.6, unauthenticated requests to could also return the public instance ID, which was derived from the same encryption key. That provided a second independent way to confirm a candidate. Based on our validation, that public instance ID behavior was no longer present in the same form beginning with v2.25.6. Once the JWT and instance ID had been collected, testing key candidates required no further requests to the target. We evaluated the exposure at scale: 31,793 n8n instances identified through Shodan 4,398 instances exposing their public instance ID 13.8% of the observed instances affected 129 internet-accessible instances whose IDs matched known weak values previously exposed on GitHub These were not merely instances that had once used weak keys. At the time of testing, the public artifacts still matched the known key patterns. Leaked API keys provide a realistic starting point Weak encryption keys provide one route to n8n's root of trust. Leaked API tokens provide another starting point, particularly when they belong to users who can create or modify workflows. In a separate scan of public GitHub commits, we identified 4,576 unique n8n API tokens associated with 1,255 hostnames. Of the 896 instances reachable at the time of testing, 321 accepted at least one exposed token. That represents approximately 36% of the reachable instances and 26% of all hostnames identified in the commits. A valid token provides access according to the permissions of the user who created it. Many exposed tokens appeared to belong to owners or administrators, likely because those were the users configuring integrations and committing API credentials. Depending on those permissions, an attacker may be able to enumerate users, read complete workflow definitions, inspect execution data, list stored credential objects, create workflows, or activate new automations. Against a fully patched instance, that functionality can already be enough to abuse stored credentials or expose sensitive workflow data. Against a vulnerable instance, the same API access can become the first step toward host and encryption key compromise. CVE-2026-25053 demonstrates that escalation path. CVE-2026-25053: From workflow access to arbitrary file read CVE-2026-25053 is a critical vulnerability in n8n's Git node. It affects versions earlier than 1.123.10 in the 1.x line and earlier than 2.5.0 in the 2.x line. The vulnerability allows an authenticated user with permission to create or modify workflows to execute system commands or read arbitrary files accessible to the n8n process. n8n fixed it in versions 1.123.10 and 2.5.0. For our proof of concept, we focused on the arbitrary file-read path. The Git command-line option instructs Git to read path specifications from another file. When Git attempts to stage a path that does not exist in the repository, it includes that path in an error message. The behavior can be used to disclose a file one line at a time. The first command reveals , the first unmatched line in the target file. After a file named is created in the repository, Git moves to the next path and reveals . The same behavior can be reproduced through an n8n workflow. An attacker with a valid API key associated with an account that can create or modify workflows can: Clone an empty attac