#git

## Description ### Cause of the Vulnerability The `CustomMCP` node allows users to input configuration settings for connecting to an external MCP (Model Context Protocol) server. This node parses the user-provided `mcpServerConfig` string to build the MCP server configuration. However, during this process, it executes JavaScript code without any security validation. Specifically, inside the `convertToValidJSONString` function, user input is directly passed to the `Function()` constructor, which evaluates and executes the input as JavaScript code. Since this runs with full Node.js runtime privileges, it can access dangerous modules such as `child_process` and `fs`. ### Vulnerability Flow 1. **User Input Received**: Input is provided via the API endpoint `/api/v1/node-load-method/customMCP` through the `mcpServerConfig` parameter. 2. **Variable Substitution**: The `substituteVariablesInString` function replaces template variables like `$vars.xxx`, but no security filtering is applie...

### Summary --- A Server-Side Request Forgery (SSRF) vulnerability was discovered in the `/api/v1/fetch-links` endpoint of the Flowise application. This vulnerability allows an attacker to use the Flowise server as a proxy to access internal network web services and explore their link structures. The impact includes the potential exposure of sensitive internal administrative endpoints. ### Details --- #### Vulnerability Overview The `fetch-links` feature in Flowise is designed to extract links from external websites or XML sitemaps. It performs an HTTP request from the server to the user-supplied URL and parses the response (HTML or XML) to extract and return links. The issue arises because the feature performs these HTTP requests **without validating the user-supplied URL**. In particular, when the `relativeLinksMethod` parameter is set to `webCrawl` or `xmlScrape`, the server directly calls the `fetch()` function with the provided URL, making it vulnerable to SSRF attacks. ###...

## Summary An authenticated admin user of **FlowiseAI** can exploit the **Supabase RPC Filter** component to execute **arbitrary server-side code** without restriction. By injecting a malicious payload into the filter expression field, the attacker can directly trigger JavaScript's `execSync()` to launch reverse shells, access environment secrets, or perform any OS-level command execution. This results in **full server compromise** and severe breach of trust boundaries between frontend input and backend execution logic. ## Details FlowiseAI includes a component called `Supabase.ts`, located at: `packages/components/nodes/vectorstores/Supabase/Supabase.ts#L237` <img width="622" height="177" alt="image(3)" src="https://github.com/user-attachments/assets/f30ccd12-4709-44ac-a6ef-8f57a1cb5c3b" /> This creates a function from user-provided string `supabaseRPCFilter` with no filtering, escaping, or sandboxing in place. Any injected JavaScript in this string is compiled and executed **im...

Remote staging in Liferay Portal 7.4.0 through 7.4.3.105, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions does not properly obtain the remote address of the live site from the database which, which allows remote authenticated users to exfiltrate data to an attacker controlled server (i.e., a fake “live site”) via the _com_liferay_exportimport_web_portlet_ExportImportPortlet_remoteAddress and _com_liferay_exportimport_web_portlet_ExportImportPortlet_remotePort parameters. To successfully exploit this vulnerability, an attacker must also successfully obtain the staging server’s shared secret and add the attacker controlled server to the staging server’s whitelist.

A vulnerability in Apache Fory allows a remote attacker to cause a Denial of Service (DoS). The issue stems from the insecure deserialization of untrusted data. An attacker can supply a large, specially crafted data payload that, when processed, consumes an excessive amount of CPU resources during the deserialization process. This leads to CPU exhaustion, rendering the application or system using the Apache Fory library unresponsive and unavailable to legitimate users. Users of Apache Fory are strongly advised to upgrade to version 0.12.2 or later to mitigate this vulnerability. Developers of libraries and applications that depend on Apache Fory should update their dependency requirements to Apache Fory 0.12.2 or later and release new versions of their software.

### Summary A use-after-free (UAF) vulnerability in Envoy's DNS cache causes abnormal process termination. Envoy may reallocate memory when processing a pending DNS resolution, causing list iterator to reference freed memory. ### Details The vulnerability exists in Envoy's Dynamic Forward Proxy implementation starting from version v1.34.0. The issue occurs when a completion callback for a DNS resolution triggers new DNS resolutions or removes existing pending resolutions. This condition may occur in the following configuration: 1. Dynamic Forwarding Filter is enabled. 2. `envoy.reloadable_features.dfp_cluster_resolves_hosts` runtime flag is enabled. 3. The Host header is modified between the Dynamic Forwarding Filter and Router filters. ### Impact Denial of service due to abnormal process termination. ### Attack vector(s) Request to Envoy configured as indicated above. ### Patches Users should upgrade to v1.35.1 or v1.34.5. ### Workaround Set the `envoy.reloadable_features.df...

North Korea’s Kimsuky hackers use AI-generated fake military IDs in a new phishing campaign, GSC warns, marking a…

Using `serde_yml::ser::Serializer.emitter` can cause a segmentation fault, which is unsound. The GitHub project for `serde_yml` was archived after unsoundness issues were raised. If you rely on this crate, it is highly recommended switching to a maintained alternative. ## Recommended alternatives - [`serde_norway`](https://crates.io/crates/serde_norway) - Maintained fork of `serde_yaml`, using `unsafe-libyaml-norway` - [`serde_yaml_ng`](https://crates.io/crates/serde_yaml_ng) - Maintained fork of `serde_yaml`, using unmaintained `unsafe-libyaml` ## Incomplete pure Rust alternatives These implementation do not rely on C `libyaml`. - [`serde_yaml2`](https://crates.io/crates/serde_yaml2) - [`yaml-peg`](https://crates.io/crates/yaml-peg)

In version 0.0.4, `libyml::string::yaml_string_extend` was revised resulting in undefined behaviour, which is unsound. The GitHub project for `libyml` was archived after unsoundness issues were raised. If you rely on this crate, it is highly recommended switching to a maintained alternative. ## Recommended alternatives - [`libyaml-safer`](https://crates.io/crates/libyaml-safer) - [`unsafe-libyaml-norway`](https://crates.io/crates/unsafe-libyaml-norway) - Maintained fork of `unsafe-libyaml`

### Who is affected? This advisory only applies to developers who use MetaMask SDK in the browser and who, on Sept 8th 2025 between 13:00–15:30 UTC, performed one of the following actions and then deployed their application: - Installed MetaMask SDK into a project with a lockfile for the first time - Installed MetaMask SDK in a project without a lockfile - Updated a lockfile to pull in `debug@4.4.2` (e.g., via `npm update` or `yarn upgrade`) ### What happened? On Sept 8th, 2025 (13:00–15:30 UTC), a malicious version of the `debug` package (v4.4.2) was published to npm. The injected code attempts to interfere with dApp-to-wallet communication when executed in a browser context. While MetaMask SDK itself was not directly impacted, projects installing the SDK during this window may have inadvertently pulled in the malicious version of `debug`. ### Mitigation - If your application was rebuilt and redeployed after Sept 8th, 2025, 15:30 UTC, the malicious version of debug should no longe...