ghsa

### Impact The Trix editor, in versions prior to 2.1.16, is vulnerable to XSS attacks through attachment payloads. An attacker could inject malicious code into a data-trix-attachment attribute that, when rendered as HTML and clicked on, could execute arbitrary JavaScript code within the context of the user's session, potentially leading to unauthorized actions being performed or sensitive information being disclosed. ### Patches Update Recommendation: Users should upgrade to Trix editor version 2.1.16 or later. ### Resources The XSS vulnerability was reported by HackerOne researcher [michaelcheers](https://hackerone.com/michaelcheers?type=user).

### Summary A command injection vulnerability exists in the Serverless Framework's built-in MCP server package (@serverless/mcp). This vulnerability only affects users of the experimental MCP server feature (serverless mcp), which represents less than 0.1% of Serverless Framework users. The core Serverless Framework CLI and deployment functionality are not affected. The vulnerability is caused by the unsanitized use of input parameters within a call to `child_process.exec`, enabling an attacker to inject arbitrary system commands. Successful exploitation can lead to remote code execution under the server process's privileges. The server constructs and executes shell commands using unvalidated user input directly within command-line strings. This introduces the possibility of shell metacharacter injection (`|`, `>`, `&&`, etc.). ### Details The MCP Server exposes several tools, including the `list-project`. The values of the parameter `workspaceRoots` (controlled by the user) is ...

### Summary When a CBORDecoder instance is reused across multiple decode operations, values marked with the shareable tag (28) persist in memory and can be accessed by subsequent CBOR messages using the sharedref tag (29). This allows an attacker-controlled message to read data from previously decoded messages if the decoder is reused across trust boundaries. ### Details The issue is in the decoder's handling of the shareables list, which stores values tagged with CBOR tag 28 (shareable) for later reference by tag 29 (sharedref). When decode_from_bytes() is called or when .fp is set to a new stream, the shareables list is not cleared. This allows references to persist across separate decode operations. The issue exists in both the C extension and the pure Python decoder. In the C extension (source/decoder.c), the _CBORDecoder_set_fp function (line ~202) updates the file pointer but does not reset the shareables state: ``` static int _CBORDecoder_set_fp(CBORDecoderObject *self,...

### Impact **Vulnerability Type:** Local Privilege Escalation (LPE) / Arbitrary Code Execution. The application loads custom Python rules and configuration files from user-writable locations (e.g., `~/.config/theshit/`) without validating ownership or permissions when executed with elevated privileges. If the tool is invoked with `sudo` or otherwise runs with an effective UID of root, it continues to trust configuration files originating from the unprivileged user's environment. This allows a local attacker to inject arbitrary Python code via a malicious rule or configuration file, which is then executed with root privileges. **Who is impacted:** Any system where this tool is executed with elevated privileges is affected. In environments where the tool is permitted to run via `sudo` without a password (`NOPASSWD`), a local unprivileged user can escalate privileges to root without additional interaction. ### Patches The issue has been fixed in version **0.1.1**. The patch introdu...

### Summary Magick fails to check for circular references between two MVGs, leading to a stack overflow. ### Details After reading mvg1 using Magick, the following is displayed: ``` ./magick -limit memory 2GiB -limit map 2GiB -limit disk 0 mvg:L1.mvg out.png AddressSanitizer:DEADLYSIGNAL ================================================================= ==3564123==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x5589549a4458 bp 0x7ffcc61f34a0 sp 0x7ffcc61efdd0 T0) #0 0x5589549a4458 in GetImagePixelCache MagickCore/cache.c:1726 #1 0x5589549b02c1 in QueueAuthenticPixelCacheNexus MagickCore/cache.c:4261 #2 0x5589549a2f24 in GetAuthenticPixelCacheNexus MagickCore/cache.c:1368 #3 0x5589549bae98 in GetCacheViewAuthenticPixels MagickCore/cache-view.c:311 #4 0x558954afb3a5 in DrawPolygonPrimitive._omp_fn.1 MagickCore/draw.c:5172 #5 0x7f62dd89fa15 in GOMP_parallel (/lib/x86_64-linux-gnu/libgomp.so.1+0x14a15) #6 0x558954ae0f41 in DrawPo...

## Vulnerability Overview ### Description RustFS implements gRPC authentication using a hardcoded static token `"rustfs rpc"` that is: 1. **Publicly exposed** in the source code repository 2. **Hardcoded** on both client and server sides 3. **Non-configurable** with no mechanism for token rotation 4. **Universally valid** across all RustFS deployments Any attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes. --- ## Vulnerable Code Analysis ### Server-Side Authentication (rustfs/src/server/http.rs:679-686) ```rust #[allow(clippy::result_large_err)] fn check_auth(req: Request<()>) -> std::result::Result<Request<()>, Status> { let token: MetadataValue<_> = "rustfs rpc".parse().unwrap(); // ⚠️ HARDCODED! match req.metadata().get("authorization") { Some(t) if token == t => Ok(req), _ => Err(Status::una...

### Summary Using Magick to read a malicious SVG file resulted in a DoS attack. ### Details bt obtained using gdb: ``` #4 0x0000555555794c9c in ResizeMagickMemory (memory=0x7fffee203800, size=391344) at MagickCore/memory.c:1443 #5 0x0000555555794e5a in ResizeQuantumMemory (memory=0x7fffee203800, count=48918, quantum=8) at MagickCore/memory.c:1508 #6 0x0000555555acc8ed in SVGStartElement (context=0x517000000080, name=0x5190000055e3 "g", attributes=0x0) at coders/svg.c:1254 #7 0x00007ffff6799b1c in xmlParseStartTag () at /lib/x86_64-linux-gnu/libxml2.so.2 #8 0x00007ffff68c7bb8 in () at /lib/x86_64-linux-gnu/libxml2.so.2 #9 0x00007ffff67a03f1 in xmlParseChunk () at /lib/x86_64-linux-gnu/libxml2.so.2 ``` This is related to the SVGStartElement and ResizeQuantumMemory functions. ### PoC 1. Generate an SVG file 2. Read this file using Magick: ``` ./magick /data/ylwang/Tools/LargeScan/targets/ImageMagick/test++/1.svg null ``` 3. Causes a DoS Attack My server has a large amount of ...

When frontend.enableExecuteMultiOperation is enabled, the server can apply namespace-scoped validation and feature gates for the embedded StartWorkflowExecutionRequest using its Namespace field rather than the outer, authorized ExecuteMultiOperationRequest.Namespace. This allows a caller authorized for one namespace to bypass that namespace's limits/policies by setting the embedded start request's namespace to a different namespace. The workflow is still created in the outer (authorized) namespace; only validation/gating is performed under the wrong namespace context. This issue affects Temporal: from 1.24.0 through 1.29.1. Fixed in 1.27.4, 1.28.2, 1.29.2.

### Impact In affected URI version, a bypass exists for the fix to CVE-2025-27221 that can expose user credentials. When using the `+` operator to combine URIs, sensitive information like passwords from the original URI can be leaked, violating RFC3986 and making applications vulnerable to credential exposure. The vulnerability affects the `uri` gem bundled with the following Ruby series: * 0.12.4 and earlier (bundled in Ruby 3.2 series) * 0.13.2 and earlier (bundled in Ruby 3.3 series) * 1.0.3 and earlier (bundled in Ruby 3.4 series) ### Patches Upgrade to 0.12.5, 0.13.3 or 1.0.4 ### References * https://www.ruby-lang.org/en/news/2025/02/26/security-advisories/ * https://hackerone.com/reports/2957667

### Summary The `arrayLimit` option in qs does not enforce limits for bracket notation (`a[]=1&a[]=2`), allowing attackers to cause denial-of-service via memory exhaustion. Applications using `arrayLimit` for DoS protection are vulnerable. ### Details The `arrayLimit` option only checks limits for indexed notation (`a[0]=1&a[1]=2`) but completely bypasses it for bracket notation (`a[]=1&a[]=2`). **Vulnerable code** (`lib/parse.js:159-162`): ```javascript if (root === '[]' && options.parseArrays) { obj = utils.combine([], leaf); // No arrayLimit check } ``` **Working code** (`lib/parse.js:175`): ```javascript else if (index <= options.arrayLimit) { // Limit checked here obj = []; obj[index] = leaf; } ``` The bracket notation handler at line 159 uses `utils.combine([], leaf)` without validating against `options.arrayLimit`, while indexed notation at line 175 checks `index <= options.arrayLimit` before creating arrays. ### PoC **Test 1 - Basic bypass:** ```bash npm i...