Security
Headlines
HeadlinesLatestCVEs

Latest News

U.S. Treasury Lifts Sanctions on Three Individuals Linked to Intellexa and Predator Spyware

The U.S. Department of the Treasury's Office of Foreign Assets Control (OFAC) on Tuesday removed three individuals linked to the Intellexa Consortium, the holding company behind a commercial spyware known as Predator, from the specially designated nationals list. The names of the individuals are as follows - Merom Harpaz Andrea Nicola Constantino Hermes Gambazzi Sara Aleksandra Fayssal Hamou

The Hacker News
#web#mac#google#git#intel#asus#sap#The Hacker News
GHSA-95qg-89c2-w5hj: theshit vulnerable to unsafe loading of user-owned Python rules when running as root

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

GHSA-7rvh-xqp3-pr8j: ImageMagick's failure to limit MVG mutual causes Stack Overflow

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

GHSA-h956-rh7x-ppgj: RustFS has a gRPC Hardcoded Token Authentication Bypass

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

GHSA-p27m-hp98-6637: ImageMagick's failure to limit the depth of SVG file reads caused a DoS attack

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

GHSA-p2gr-hm8g-q772: Temporal has a namespace policy bypass allowing requests to be authorized for incorrect contexts

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.

GHSA-j4pr-3wm6-xx2r: URI Credential Leakage Bypass over CVE-2025-27221

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

GHSA-6rw7-vpxm-498p: qs's arrayLimit bypass in its bracket notation allows DoS via memory exhaustion

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

GHSA-2267-xqcf-gw2m: FacturaScripts is Vulnerable to Stored Cross-Site Scripting (XSS) via XML File Upload

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.

GHSA-6mp4-q625-mxjp: YOURLS is vulnerable to XSS through JSONP and Callback request parameters

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