Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN673 _____________________________________________________________________ DATE : 25/06/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running n8n (npm) versions prior to 2.28.1, 2.27.4. ===================================================================== https://github.com/n8n-io/n8n/security/advisories/GHSA-mq3m-f8x3-579w https://github.com/n8n-io/n8n/security/advisories/GHSA-75qm-gp28-rcq9 https://github.com/n8n-io/n8n/security/advisories/GHSA-h44j-f5r5-ph73 https://github.com/n8n-io/n8n/security/advisories/GHSA-q3j5-8vrg-4p9q https://github.com/n8n-io/n8n/security/advisories/GHSA-2434-3x6q-8r99 https://github.com/n8n-io/n8n/security/advisories/GHSA-jp7m-xcgx-57qm https://github.com/n8n-io/n8n/security/advisories/GHSA-w867-jm58-p9pv _____________________________________________________________________ Cross-Issuer Token Exchange Account Binding via Subject-Only Identity Resolution High Jubke published GHSA-mq3m-f8x3-579w yesterday Package n8n (npm) Affected versions < 2.28.1 < 2.27.4 Patched versions >= 2.28.1 >= 2.27.4 Description Impact When an n8n instance is configured with more than one trusted token-exchange issuer, external identities are resolved to local accounts using only the JWT sub claim, ignoring the issuer (iss). As a result, two different issuers that emit the same subject value map to the same local account. An attacker who can obtain a valid token from one trusted issuer with a sub matching a victim registered under a different issuer can authenticate as that victim and access their account. This issue only affects instances where the token exchange feature is enabled and more than one trusted external issuer is configured. Patches The issue has been fixed in n8n version 2.28.1. Users should upgrade to this version or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: If multiple trusted issuers are not required, reduce the token exchange configuration to a single trusted issuer. Disable the token exchange feature entirely if it is not in active use. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. Severity High 7.6/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required Low User interaction None Vulnerable System Impact Metrics Confidentiality High Integrity High Availability None Subsequent System Impact Metrics Confidentiality None Integrity None Availability None CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N CVE ID No known CVE Weaknesses No CWEs Credits @bearsyankees bearsyankees Reporter _____________________________________________________________________ Prototype Pollution via Workflow Credentials Leads to Unauthenticated User and Project Enumeration High Jubke published GHSA-75qm-gp28-rcq9 Package n8n (npm) Affected versions < 1.123.61 < 2.28.1 < 2.27.4 Patched versions >= 1.123.61 >= 2.28.1 >= 2.27.4 Description Impact An authenticated user with the default workflow:create permission could pollute Object.prototype through a crafted workflow saved, updated, or imported via the workflow API. This can be leveraged to bypass authentication, allowing unauthenticated requests to be treated as a privileged user and exposing endpoints such as the user and project listings. As a result, every account's personal data (email, role, MFA status) and all projects on the instance may be disclosed to unauthenticated callers. The pollution can also corrupt global state, making parts of the instance unresponsive until restarted. Patches The issue has been fixed in n8n versions 1.123.61, 2.27.4, and 2.28.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Restrict workflow creation and editing permissions to fully trusted users only. Restrict network access to the n8n instance to trusted users only. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. Severity High 7.1/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements None Privileges Required Low User interaction None Vulnerable System Impact Metrics Confidentiality High Integrity Low Availability None Subsequent System Impact Metrics Confidentiality Low Integrity Low Availability None CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:L/SI:L/SA:N CVE ID No known CVE Weaknesses No CWEs Credits @assakafpix assakafpix Reporter _____________________________________________________________________ "Allowed HTTP Request Domains" Restriction Bypass via AI Agents MCP Connector High Jubke published GHSA-h44j-f5r5-ph73 Package n8n (npm) Affected versions < 2.28.1 < 2.27.4 Patched versions >= 2.28.1 >= 2.27.4 Description Impact The AI Agents feature did not enforce the "Allowed HTTP Request Domains" restriction configured on credentials. As a result, a member-level user who had been granted use-only access to a shared credential could cause its secret to be sent to an external server they control, by pointing an MCP tool at an arbitrary URL and running the agent. This issue only affects instances where the AI Agents module is enabled via N8N_ENABLED_MODULES=agents and at least one credential with domain restrictions has been shared with a member-level user. Patches The issue has been fixed in n8n version 2.28.1 and 2.27.4. Users should upgrade to this version or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Disable the AI Agents module by removing agents from the N8N_ENABLED_MODULES environment variable. Restrict credential sharing to fully trusted users only. Audit credentials with domain restrictions for unexpected sharing relationships. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. Severity High 7.1/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required Low User interaction None Vulnerable System Impact Metrics Confidentiality High Integrity Low Availability None Subsequent System Impact Metrics Confidentiality High Integrity Low Availability None CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N CVE ID No known CVE Weaknesses No CWEs Credits @trap-bytes trap-bytes Reporter _____________________________________________________________________ Shared Credential Header Leak via HTTP Request Pagination Expression High Jubke published GHSA-q3j5-8vrg-4p9q Package n8n (npm) Affected versions < 1.123.61 < 2.28.1 < 2.27.4 Patched versions >= 1.123.61 >= 2.28.1 >= 2.27.4 Description Impact An authenticated member with use-only editor access to a shared workflow could read credential-populated headers exposed via the $request object inside an HTTP Request node's pagination expression. When an HTTP Header Auth credential is applied to a paginated request, the secret is present in $request.headers when pagination expressions are evaluated. A user-controlled expression could read that secret, copy it into item data, and exfiltrate it through a later HTTP Request node, bypassing credential domain restrictions, since the secret leaves via item data rather than the credential's own request mechanism. This issue only affects instances with N8N_EXPRESSION_ENGINE=vm set, where paginated HTTP Request workflows using shared credentials are accessible to non-owner users. Patches The issue has been fixed in n8n versions 1.123.61, 2.27.4, and 2.28.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Restrict workflow sharing to fully trusted users only. Avoid sharing credentials with use-only access to untrusted users on workflows that use HTTP Request nodes with pagination enabled. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. Severity High 7.1/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements None Privileges Required Low User interaction None Vulnerable System Impact Metrics Confidentiality High Integrity None Availability None Subsequent System Impact Metrics Confidentiality None Integrity None Availability None CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N CVE ID No known CVE Weaknesses No CWEs Credits @sm1ee sm1ee Reporter _____________________________________________________________________ External Secrets Accessible via Workflow Expressions Outside Credentials Moderate Jubke published GHSA-2434-3x6q-8r99 Package n8n (npm) Affected versions < 2.28.1 < 2.27.4 Patched versions >= 2.28.1 >= 2.27.4 Description Impact External secrets were incorrectly resolved in workflow node expressions, where they are not intended to be available. An authenticated user with project editor access could read the plaintext value of external secrets by referencing them in a node expression, without needing explicit secrets access permissions. This issue only affects instances with the external secrets feature configured. Patches The issue has been fixed in n8n versions 2.27.4 and 2.28.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Restrict project membership to fully trusted users only. Avoid granting editor access to projects on instances where external secrets are configured. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. Severity Moderate 6.3/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements None Privileges Required Low User interaction None Vulnerable System Impact Metrics Confidentiality None Integrity None Availability None Subsequent System Impact Metrics Confidentiality High Integrity None Availability None CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N CVE ID No known CVE Weaknesses No CWEs _____________________________________________________________________ External Secrets Permission Bypass via Expression Parser Mismatch Moderate Jubke published GHSA-jp7m-xcgx-57qm Package n8n (npm) Affected versions < 1.123.61 < 2.28.1 < 2.27.4 Patched versions >= 1.123.61 >= 2.28.1 >= 2.27.4 Description Impact Due to a mismatch between the static validation check and the runtime expression engine, an authenticated user with credential create or update permissions, but without the externalSecret:list scope, could embed external secret references into credentials in forms the validation did not detect. These references would resolve at workflow execution time, exposing secret values the user was not authorized to access. This issue only affects instances where an external secrets provider is configured and Advanced Permissions are in use. Patches The issue has been fixed in n8n versions 1.123.61, 2.27.4, and 2.28.1. Users should upgrade to one of these versions or later to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Restrict credential creation and update permissions to fully trusted users only. Audit existing credentials for unexpected external secret references. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. Severity Moderate 6.0/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements Present Privileges Required Low User interaction None Vulnerable System Impact Metrics Confidentiality High Integrity None Availability None Subsequent System Impact Metrics Confidentiality None Integrity None Availability None CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N CVE ID No known CVE Weaknesses No CWEs Credits @YLChen-007 YLChen-007 Reporter _____________________________________________________________________ Authenticated Users Can Exhaust Temporary Disk Storage via Data-Table File Uploads Moderate Jubke published GHSA-w867-jm58-p9pv Package n8n (npm) Affected versions < 2.28.0 < 1.123.58 Patched versions >= 2.28.0 >= 1.123.58 Description Impact An authenticated user can repeatedly upload files to the data-table upload endpoint, bypassing the per-request quota check, which does not account for files already written to the shared temporary directory. This causes temporary files to accumulate on disk until the periodic cleanup runs, potentially exhausting available disk space on the host. Patches Users should upgrade to the patched version once available to remediate the vulnerability. Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Restrict n8n instance access to fully trusted users only. Set uploadMaxFileSize to a low value to limit individual upload size. Monitor and alert on disk usage in the n8n temporary upload directory. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures. Severity Moderate 5.3/ 10 CVSS v4 base metrics Exploitability Metrics Attack Vector Network Attack Complexity Low Attack Requirements None Privileges Required Low User interaction None Vulnerable System Impact Metrics Confidentiality None Integrity None Availability Low Subsequent System Impact Metrics Confidentiality None Integrity None Availability None CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N CVE ID No known CVE Weaknesses No CWEs Credits @CodeByMoriarty CodeByMoriarty Reporter ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================