| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| When the Strimzi cluster operator is deployed with watchAnyNamespace=true (or a multi-namespace list), any namespace editor can set Kafka.spec.entityOperator.userOperator.watchedNamespace (or topicOperator.watchedNamespace) to an arbitrary namespace. The cluster operator then creates a Role granting full CRUD on Secrets in the target namespace and a RoleBinding pointing to a ServiceAccount in the attacker's namespace — effectively granting cluster-admin-equivalent access via kube-system secret exfiltration. The RBAC objects created cross-namespace have their ownerReferences deliberately stripped, making the privilege grant persistent even after the Kafka CR or attacker namespace is deleted. Fixed in Strimzi 1.0.1 and 1.1.0 by adding a dedicated environment variable to explicitly enable the watched namespace feature (disabled by default). |
| When deploying only the Topic Operator or only the User Operator via the Kafka custom resource, the Entity Operator's ServiceAccount retains RBAC rights for both operators rather than scoping permissions to the one actually deployed. This allows the ServiceAccount to access KafkaUser custom resources and Secrets even when the User Operator is not deployed, or access KafkaTopic custom resources when the Topic Operator is not deployed, violating the principle of least privilege. There is no workaround for this issue. Fixed in Strimzi 1.0.1 and 1.1.0. |
| picklescan before 0.0.29 fails to detect malicious idlelib.calltip.Calltip.fetch_tip calls in pickle files, allowing remote code execution. Attackers can embed undetected payloads in pickle files that execute arbitrary code when loaded via pickle.load(). |
| n8n before 1.123.25 (1.x) and before 2.11.2 (2.x), with the fix also included in 2.12.0, contains a stored cross-site scripting vulnerability in the Form Trigger node's CSS sanitization that allows authenticated users to inject malicious scripts. Attackers with workflow creation permissions can inject XSS payloads that execute persistently for all form visitors, enabling form hijacking and phishing attacks. |
| When using the "tarfile" module with a file opened in "streaming mode" (mode="r|") the tarfile module did not properly handle EOF, making archive parsing take exponentially longer. |
| n8n is an open source workflow automation platform. Prior to 2.24.0, an authenticated user with workflow edit access could supply a malicious filter value in the MongoDB node's Find And Replace operation. The value was not validated before being passed to MongoDB as a query filter, allowing unintended documents to be matched and overwritten with attacker-controlled content. This vulnerability is fixed in 2.24.0. |
| n8n is an open source workflow automation platform. Prior to 2.24.0, an endpoint in the Meta and Microsoft Teams trigger nodes reflects a query parameter into the HTTP response without sanitization or Content-Security-Policy headers, enabling reflected XSS in the n8n origin when a logged-in user visits a crafted URL. This vulnerability is fixed in 2.24.0. |
| n8n is an open source workflow automation platform. Prior to 2.24.0, an authenticated user with permission to create or modify workflows could achieve global prototype pollution via the Microsoft SQL node by supplying a crafted value as the table parameter. This pollutes Object.prototype process-wide for the lifetime of the n8n server process, causing application-wide validation failures and rendering the n8n instance completely non-functional until restarted. This vulnerability is fixed in 2.24.0. |
| n8n is an open source workflow automation platform. Prior to 2.24.0, the Compression node's Decompress operation expanded attacker-controlled archives into memory without enforcing limits on decompressed output size. An unauthenticated attacker could send a small compressed archive to a public webhook workflow using this node, causing the n8n process to terminate due to memory exhaustion and disrupting all workflows in the same instance. This vulnerability is fixed in 2.24.0. |
| NanoClaw before 2.1.17 contains a privilege escalation vulnerability in the handleApprovalsResponse function that fails to verify responder role authorization. Attackers with a valid questionId can approve or reject privileged actions like package installation by submitting approval response payloads without proper role validation. |
| NanoClaw before 2.1.17 contains a symlink following vulnerability in forwardAttachedFiles that allows container-controlled agents to exfiltrate host-readable files. The host validates attachment filenames using only isSafeAttachmentName before copying with fs.copyFileSync, which follows symlinks without containment checks, allowing malicious agents to disclose arbitrary host files. |
| NanoClaw before 2.1.17 contains a privilege escalation vulnerability in the create_agent delivery-action handler that performs privileged central-database writes without host-side authorization checks. Confined agent containers can invoke create_agent to create arbitrary agent groups, container configurations, and destinations, escalating beyond their intended confinement boundary. |
| NanoClaw before 2.1.0 contains a privilege escalation vulnerability in the channel-registration approval flow where handleChannelApprovalResponse fails to validate admin privileges over target agent groups. Scoped admins can submit forged or stale connect callback values to wire messaging channels into out-of-scope agent groups, exposing unauthorized groups to unapproved channels and enabling unauthorized observation or control of restricted agent group activity. |
| n8n is an open source workflow automation platform. Prior to 2.25.7 and 2.26.2, when @n8n/mcp-browser is run in HTTP transport mode, the MCP endpoint accepts session initialization and tool invocation requests without any authentication. Any network-reachable client, or any website visited by the user, can establish an MCP session and invoke browser-control tools. Where the n8n AI Browser Bridge extension is installed and a browser connection is active, an unauthenticated caller can access browser-control capabilities including navigation, JavaScript evaluation, and cookie and storage access against the user's real browser profile. This issue only affects instances where @n8n/mcp-browser is run with the HTTP transport (--transport http). This vulnerability is fixed in 2.25.7 and 2.26.2. |
| n8n is an open source workflow automation platform. Prior to 2.25.7 and 2.26.2, an authenticated user with permission to create or modify workflows could supply a crafted parameters to the TimescaleDB and/or legacy Postgres v1 node's allowing arbitrary SQL to be injected and executed against the connected database within the privileges of the configured database account. This vulnerability is fixed in 2.25.7 and 2.26.2. |
| n8n is an open source workflow automation platform. Prior to 2.25.7 and 2.26.2, an authenticated user with permission to create or modify workflows could pollute the sandbox used by the Merge node's SQL Query mode. Because the sandbox context was cached and reused across all workflow executions on the instance, prototype mutations introduced by one user's workflow persist into subsequent Merge SQL executions belonging to other users or projects. This allowed a low-privileged attacker to intercept workflow data processed by other users on the same instance. This issue only affects multi-user n8n instances where more than one user has permission to create and execute workflows containing the Merge node in SQL Query mode. This vulnerability is fixed in 2.25.7 and 2.26.2. |
| n8n is an open source workflow automation platform. Prior to 2.25.7 and 2.26.2, the MicrosoftAgent365Trigger and StripeTrigger node did not validate that inbound requests. As a result, an unauthenticated attacker who knows the webhook URL could submit a forged payload and cause the workflow to execute with attacker-controlled data. This vulnerability is fixed in 2.25.7 and 2.26.2. |
| n8n is an open source workflow automation platform. Prior to 2.25.7 and 2.26.2, a prototype pollution vulnerability allowed a crafted public webhook payload to inject attacker-controlled fields into workflow data during internal object copying. These fields could be surfaced and consumed as normal values by downstream built-in nodes. Where a workflow combines a public webhook with action nodes that consume the resulting fields, an attacker could cause the workflow to act as a confused deputy — targeting unintended records or issuing outbound requests using the workflow owner's configured credentials. This vulnerability is fixed in 2.25.7 and 2.26.2. |
| n8n is an open source workflow automation platform. Prior to 1.123.55, 2.25.7, and 2.26.2, an authenticated user with workflow edit access could configure a Respond to Webhook node to serve binary content with an attacker-controlled Content-Type. The binary response path bypassed the central Content-Security-Policy sandbox header, allowing a public webhook to execute JavaScript in the n8n origin when visited by an authenticated user, with access to that user's session. This vulnerability is fixed in 1.123.55, 2.25.7, and 2.26.2. |
| n8n is an open source workflow automation platform. Prior to 1.123.55, 2.25.7, and 2.26.2, three EE endpoints used by the Dynamic Credentials feature accepted any authenticated n8n session without performing per-resource ownership or scope checks on the target workflow or credential. An authenticated user with no project membership or credential sharing relationship could enumerate credential identifiers, names, and types referenced by any private workflow in the instance, initiate an OAuth authorization flow against another user's credential to overwrite its stored tokens with tokens bound to an account they control, or revoke another user's stored credential tokens entirely. Workflows relying on a hijacked credential would subsequently execute under the attacker's OAuth identity, enabling data exfiltration to attacker-controlled external services and persistent takeover of integrations. Token revocation would break affected workflows. This vulnerability is fixed in 1.123.55, 2.25.7, and 2.26.2. |
