ghsa

# Impact ## Summary A vulnerability in Apollo Gateway allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically during named fragment expansion. This could lead to excessive resource consumption and denial of service. ## Details Named fragments were being expanded once per fragment spread during query planning, leading to exponential resource usage when deeply nested and reused fragments were involved. ## Fix/Mitigation A new **Query Fragment Expansion Limit** metric has been introduced: - This metric computes the number of selections a query would have if its fragment spreads were fully expanded. - The metric is checked against a limit to prevent excessive computation. # Patches This has been remediated in `@apollo/gateway` version 2.10.1. # Workarounds No known direct workarounds exist. # References [Query Planning Documentation](https://www.apollographql.com/docs/graphos/reference/federation/query-plans) ...

# Impact ## Summary A vulnerability in Apollo Router's usage of Apollo Compiler allowed queries with deeply nested and reused named fragments to be prohibitively expensive to validate. This could lead to excessive resource consumption and denial of service. ## Details Named fragments were being processed once per fragment spread in some cases during query validation, leading to exponential resource usage when deeply nested and reused fragments were involved. ## Fix/Mitigation Apollo Router's usage of Apollo Compiler has been updated so that validation logic processes each named fragment only once, preventing redundant traversal. # Patches This has been remediated in `apollo-router` versions 1.61.2 and 2.1.1. # Workarounds The only known workaround is "Safelisting with IDs only" per [Safelisting with Persisted Queries - Apollo GraphQL Docs](https://www.apollographql.com/docs/graphos/routing/security/persisted-queries#router-security-levels). The "Safelisting" security level is ...

# Impact ## Summary A vulnerability in Apollo Router allowed certain queries to bypass configured operation limits, specifically due to integer overflow. ## Details The operation limits plugin uses unsigned 32-bit integers to track limit counters (e.g. for a query's height). If a counter exceeded the maximum value for this data type (4,294,967,295), it wrapped around to 0, unintentionally allowing queries to bypass configured thresholds. This could occur for large queries if the payload limit were sufficiently increased, but could also occur for small queries with deeply nested and reused named fragments. ## Fix/Mitigation Logic was updated to ensure counter overflow is handled correctly and does not wrap around to 0. # Patches This has been remediated in `apollo-router` versions 1.61.2 and 2.1.1. # Workarounds The only known workaround is "Safelisting" or "Safelisting with IDs only" per [Safelisting with Persisted Queries - Apollo GraphQL Docs](https://www.apollographql.com/...

# Impact ## Summary A vulnerability in Apollo Router allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically during named fragment expansion. This could lead to excessive resource consumption and denial of service. ## Details Named fragments were being expanded once per fragment spread during query planning, leading to exponential resource usage when deeply nested and reused fragments were involved. ## Fix/Mitigation A new **Query Fragment Expansion Limit** metric has been introduced: - This metric computes the number of selections a query would have if its fragment spreads were fully expanded. - The metric is checked against a limit to prevent excessive computation. # Patches This has been remediated in `apollo-router` versions 1.61.2 and 2.1.1. # Workarounds The only known workaround is "Safelisting" or "Safelisting with IDs only" per [Safelisting with Persisted Queries - Apollo GraphQL Docs](https://www.ap...

# Impact ## Summary A vulnerability in Apollo Router allowed queries with deeply nested and reused named fragments to be prohibitively expensive to query plan, specifically due to internal optimizations being frequently bypassed. This could lead to excessive resource consumption and denial of service. ## Details The query planner includes an optimization that significantly speeds up planning for applicable GraphQL selections. However, queries with deeply nested and reused named fragments can generate many selections where this optimization does not apply, leading to significantly longer planning times. Because the query planner does not enforce a timeout, a small number of such queries can exhaust router's thread pool, rendering it inoperable. ## Fix/Mitigation - A new **Query Optimization Limit** metric has been added: - This metric approximates the number of selections that cannot be skipped by the existing optimization. - The metric is checked against a limit to prevent ex...

### Summary import functions are vulnerable. * [importChatflows](https://github.com/FlowiseAI/Flowise/blob/main/packages/server/src/services/chatflows/index.ts#L219) * [importTools](https://github.com/FlowiseAI/Flowise/blob/main/packages/server/src/services/tools/index.ts#L85) * [importVariables](https://github.com/FlowiseAI/Flowise/blob/main/packages/server/src/services/variables/index.ts) ### Details **Authenticated user** can call importChatflows API, import json file such as `AllChatflows.json`. but Due to insufficient validation to chatflow.id in importChatflows API, 2 issues arise. **Issue 1 (Bug Type)** 1. Malicious user creates `AllChatflows.json` file by adding `../` and arbitrary path to the chatflow.id of the json file. ```json { "Chatflows": [ { "id": "../../../../../../apikey", "name": "clickme", "flowData": "{}" } ] } ``` 2. Victim download this file, and import this to flowise. 3. When victim cli...

### Summary An unsafe deserialization vulnerability in Python’s pickle module allows an attacker to bypass static analysis tools like Picklescan and execute arbitrary code during deserialization. This can be exploited by import some built-in function in Numpy library that indrectly call some dangerous function like exec() to execute some python code as a parameter, which the attacker can import dangerous library inside like os library and execute arbitrary OS commands. ### Details Pickle’s deserialization process is known to allow execution of function via **reduce** method. While Picklescan is meant to detect such exploits, this attack evades detection by calling function in Numpy library that call dangerous function like exec(). And since Numpy library wasn't inside unsafe globals blacklist, it may not raise red flag in the security scan. The attack payload executes in the following steps: - First, the attacker craft the payload by import **runstring** function in **numpy.testing._p...

### Summary Picklescan does not detect malicious pickles that exfiltrate sensitive information via DNS after deserialization. ### Details picklescan’s blacklist can be bypassed to exfiltrate sensitive information (like file contents, secrets, or credentials) during model deserialization by leveraging `ssl.get_server_certificate` as the callable function in the pickle payload. Since `ssl` is a standard Python library used for legitimate TLS operations, it is rarely blacklisted by static scanners or runtime monitors. The payload avoids flagged modules and instead uses `linecache` (also unflagged) to read local files. The exfiltrated data is added to DNS-safe chunks, and embedded as subdomains in a crafted FQDN. When passed to `ssl.get_server_certificate`, the Python runtime performs a DNS resolution to the attacker-controlled domain, leaking the encoded content. The payload executes the following steps: - Reads sensitive local file content using `linecache` module - Encodes the d...

**Vulnerability type:** Prototype Pollution **Affected Package:** * Product: js-object-utilities * Version: 2.2.0 **Remedy:** Update package to version 2.2.1. **Vulnerability Location(s):** ```js at module.exports (/node_modules/js-object-utilities/dist/set.js:16:29) ``` **Description:** The latest version of `js-object-utilities (2.2.0)`, (previous versions are also affected), is vulnerable to Prototype Pollution through the entry function(s) `lib.set`. An attacker can supply a payload with Object.prototype setter to introduce or modify properties within the global prototype chain, causing denial of service (DoS) a the minimum consequence. Moreover, the consequences of this vulnerability can escalate to other injection-based attacks, depending on how the library integrates within the application. For instance, if the polluted property propagates to sensitive Node.js APIs (e.g., exec, eval), it could enable an attacker to execute arbitrary commands within the application's conte...

# Server-Side Request Forgery via LNURL Authentication Callback in LNbits Lightning Network Payment System ## Disclaimer This vulnerability was detected using **[XBOW](https://xbow.com/)**, a system that autonomously finds and exploits potential security vulnerabilities. The finding has been thoroughly reviewed and validated by a security researcher before submission. While XBOW is intended to work autonomously, during its development human experts ensure the accuracy and relevance of its reports. ## Description A Server-Side Request Forgery (SSRF) vulnerability has been discovered in LNbits' LNURL authentication handling functionality. The vulnerability exists in the LNURL authentication callback process where the application makes HTTP requests to user-provided callback URLs and follows redirects without proper validation. When processing LNURL authentication requests, the application accepts a callback URL parameter and makes an HTTP request to that URL using the httpx library ...