#vulnerability

### 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.

When system.enableCrossNamespaceCommands is enabled (on by default), the Temporal server permits certain workflow task commands (e.g. StartChildWorkflowExecution, SignalExternalWorkflowExecution, RequestCancelExternalWorkflowExecution) to target a different namespace than the namespace authorized at the gRPC boundary. The frontend authorizes RespondWorkflowTaskCompleted based on the outer request namespace, but the history service later resolves and executes the command using the namespace embedded in command attributes without authorizing the caller for that target namespace. This can allow a worker authorized for one namespace to create, signal, or cancel workflows in another namespace. This issue affects Temporal: 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

A stored cross-site scripting (XSS) vulnerability exists in the product file upload functionality. Authenticated users can upload crafted XML files containing executable JavaScript. These files are later rendered by the application without sufficient sanitization or content-type enforcement, allowing arbitrary JavaScript execution when the file is accessed. Because product files uploaded by regular users are visible to administrative users, this vulnerability can be leveraged to execute malicious JavaScript in an administrator’s browser session.

### Summary The callback and **jsonp** request parameters are directly concatenated into the response without any sanitization that allowing attackers to inject arbitrary JS code. When **YOURLS_PRIVATE** is set to **false** (public API mode), this vulnerability can be exploited by any unauthenticated attacker. In private mode, the XSS payload is still injected into the 403 response body though browser execution is blocked. ### Details Vulnerability exists in the JSONP callback handling chain: ``` yourls-api.php:127-128 if( isset( $_REQUEST['callback'] ) ) $return['callback'] = $_REQUEST['callback']; elseif ( isset( $_REQUEST['jsonp'] ) ) $return['callback'] = $_REQUEST['jsonp']; ``` --- ``` includes/functions-api.php:127-128 $callback = isset( $output['callback'] ) ? $output['callback'] : ''; $result = $callback . '(' . json_encode( $output ) . ')'; ``` ### PoC I. YOURLS instance with YOURLS_PRIVATE set to false in config.php or user authenticated to a private YOURLS...

### Summary A Zip Slip vulnerability in PsiTransfer allows an unauthenticated attacker to upload files with path traversal sequences in the filename (e.g. `../../../.ssh/authorized_keys`). When a victim downloads the bucket as a **.tar.gz** archive and extracts it, malicious files are written outside the intended directory, potentially leading to RCE. ### Details The vulnerability exists in the archive download functionality in **lib/endpoints.js** where user controlled metadata.name is used directly without sanitization when creating TAR archive entries. ``` lib/endpoints.js:275 const entry = pack.entry({ name: info.metadata.name, size: info.size }); ``` ``` lib/endpoints.js:372 assert(meta.name, 'tus meta prop missing: name'); ``` ### PoC I. Upload file with malicious filename (no authentication required). ``` MALICIOUS_NAME=$(echo -n "../../../tmp/dp.txt" | base64) SID=$(echo -n "evil" | base64) RETENTION=$(echo -n "3600" | base64) curl -X POST http://TARGET:3000/files \ ...

### Impact Attackers controlling remote sources that Composer downloads from might in some way inject ANSI control characters in the terminal output of various Composer commands, causing mangled output and potentially leading to confusion or DoS of the terminal application. There is no proven exploit and this has thus a low severity but Composer still published a CVE as it has potential for abuse, and Composer wants to be on the safe side informing users that they should upgrade. ### Patches 2.2.26 for 2.2 LTS or 2.9.3 for mainline.