CVEs

A security vulnerability has been detected in syncfusion ej2-javascript-ui-controls up to 33.2.3. This affects the function child_process.exec of the file package.json. The manipulation leads to os command injection. An attack has to be approached locally. The exploit has been disclosed publicly and may be used.

JupyterLab 4.5+ allows notebook settings to be shared and applied through an `overrides.json` file using the `Import` button in the Settings Editor. Certain notebook display settings were not properly validated before being applied. As a result, a crafted settings file could contain hidden instructions that run as code inside JupyterLab when imported, instead of only changing a display preference. Because importing a settings file appears harmless, a user could import a file shared by another

JupyterLab's image viewer allows for cross-site scripting (XSS) when a specially-crafted image file is opened through the image viewer and then opened in a new tab. This XSS issue can be used to cause remote code execution (RCE) on the JupyterLab server. ### Impact This vulnerability allows for arbitrary code execution. ### Patches JupyterLab [`v4.6.2`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.6.2) and [`v4.5.10`](https://github.com/jupyterlab/jupyterlab/releases/tag/v4.5.10)

JupyterLab's PyPI extension manager enforces `blocked_extensions_uris` by comparing the requested install name to blocklist entries with a custom string normalization that is weaker than PyPI package-name canonicalization. An authenticated user can request a PyPI-equivalent spelling such as `JupyterLab.Git` for a blocklisted package such as `jupyterlab-git`; JupyterLab accepts the install request even though pip resolves the variant to the same package. This has security implications only for d

JupyterLab's plugin manager exposes administrator controls intended to prevent users from enabling or disabling selected plugins. Two server-side enforcement gaps let an authenticated user bypass those controls with direct requests to `/lab/api/plugins`. ### Impact Users could workaround the plugin manager lock rules via direct API access for either: - child plugins of extensions covering multiple plugins - when "lock all" was issued by the administrator The integrity of data can be impacted,

The extension allowlist/blocklist check inside `PyPIExtensionManager.install()` was not enforced due to a missing await. For purposes of JupyterLab this was a secondary defense-in-depth check: `install()` was intended to enforce the allowlist/blocklist itself for any future uses and users calling this method directly (in addition to the separate check handling requests arriving through the HTTP API). The only runtime symptom was a `RuntimeWarning: coroutine 'is_install_allowed' was never awaite

WordPress 6.9.x before 6.9.5 and 7.0.x before 7.0.2 is affected by a REST API batch endpoint route confusion issue which, combined with the author__not_in WP_Query SQL Injection (CVE-2026-60137), could allow an attacker to perform SQL Injection and achieve Remote Code Execution.

A vulnerability was detected in oclif up to 4.23.16. Affected by this vulnerability is the function child_process.exec of the component JIT Plugin Entry Handler. Performing a manipulation of the argument jitPlugins results in os command injection. The attack is only possible with local access. The exploit is now public and may be used. The patch is named 939b045725e065baebc4587b8bccfd56731eed3d. To fix this issue, it is recommended to deploy a patch.

## Impact The component `@n8n/computer-use` file-search tool confined searches to a configured base directory. A crafted search pattern could bypass the confinement check and expand to locations outside that directory, causing the tool to return the names and contents of files anywhere the daemon's OS user could read. Any deployment where an actor could influence the tool's search input was affected; the result was disclosure of arbitrary local files outside the intended sandbox. ## Patches T

## Impact An authenticated user able to create or edit a workflow expression could abuse the expression engine's array-element access to obtain a reference to a host built-in and pollute its prototype in the main n8n process, leading to a denial of service. Both self-hosted and cloud instances running the VM expression engine are affected. ## Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the

## Impact The Edit Fields (Set) node assigned output fields through a dot-notation path setter without restricting the field name, so an authenticated user could name a field after an inherited built-in method path and corrupt a shared global in the main Node.js process. Because that global was used on the request-authentication path, the instance then failed every authenticated request, causing a instance-wide denial of service for all users until the process was restarted. ## Patches The is

## Impact The n8n Edit Image node passed its output format to the underlying image library without validation, so a crafted value could write bytes to a location outside the node's working directory. An authenticated user able to run workflows could use this to write arbitrary files in the n8n instance. ## Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. ## Workarounds If upg

## Impact n8n's credential-access checks validated only a node's top-level credentials, not credentials referenced inside an Execute Sub-workflow node's inline workflow JSON. A member with editor access to a shared workflow could reference a credential they were not permitted to use inside that inline JSON; it passed both save-time and runtime validation and resolved in the parent workflow's project context, letting the member use or exfiltrate a credential they could not otherwise access. Exp

## Impact An authenticated member with edit access to a shared workflow could reference another user's credential in an HTTP Request node while specifying the credential type through an expression. Because the pre-execution permission check compared the unresolved expression instead of the real credential type, the ownership check was skipped and the credential was loaded at execution time, letting the member use or exfiltrate a credential they were never granted. Exploitation required knowing

## Impact An authenticated user with permission to create or modify workflows could abuse crafted expressions using arrow functions to bypass the expression sandbox, triggering unintended system command execution on the host running n8n. ## Patches The issue has been fixed in n8n versions 2.31.5 and 2.32.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 followi

## Impact The n8n Send Email node did not enforce that its message fields were strings, so a crafted untrusted non-string value from a workflow expression could be treated by the underlying mail library as a file path or URL. This could allow disclosure of local files on the n8n host. Exploitation requires a pre-existing active workflow with an unauthenticated webhook, valid SMTP credentials configured on the Send Email node, and untrusted input mapped directly into the text or HTML body field

## Impact Authenticated n8n users with rights to create and execute workflows could achieve code execution on the n8n host. Using the Git node, under the default `git` security settings, by staging a crafted local repository, an attacker could cause `git` to run hooks, executing arbitrary commands as the n8n process user. Both self-hosted and cloud instances are affected where authenticated users can create and execute workflows using the Git node. ## Patches The issue has been fixed in n8n

## Impact On an n8n instance with SSRF protection enabled, the MCP Client node sent requests to a user-supplied endpoint without routing them through that protection and without pinning the resolved address. An authenticated user who could create or edit a workflow could therefore cause the server to connect to internal or otherwise blocked hosts and read the responses back through the workflow, exposing internal services the SSRF protection was meant to protect. ## Patches The issue has been