Security
Headlines
HeadlinesLatestCVEs

Latest News

Deja Vu: Salesforce Customers Hacked Again, Via Gainsight

In a repeat of similar attacks during the summer, threat actors affiliated with the ShinyHunters extortion group used a third-party application to steal organizations' Salesforce data.

DARKReading
LINE Messaging Bugs Open Asian Users to Cyber Espionage

In a potential gift to geopolitical adversaries, the encrypted messaging app uses a leaky custom protocol that allows message replays, impersonation attacks, and sensitive information exposure from chats.

Cloudflare's One-Stop-Shop Convenience Takes Down Global Digital Economy

Even the most advanced systems like Cloudflare can fall victim to software issues and become a global point of failure, Dr. David Utzke argues, adding that the recent outage should be a warning for enterprises.

#git
Hack the Hackers: 6 Laws for Staying Ahead of the Attackers

A new security framework responds to a shift in attackers' tactics, one that allows them to infiltrate enterprises "silently" through their own policies.

AI teddy bear for kids responds with sexual content and advice about weapons

FoloToy's AI teddy bear, Kumma, crossed serious lines, raising fresh concerns about how little oversight exists for AI toys marketed to children.

GHSA-jf9p-2fv9-2jp2: thread-amount Vulnerable to Resource Exhaustion (Memory and Handle Leaks) on Windows and macOS

Affected versions of this crate contain resource leaks when querying thread counts on Windows and Apple platforms. ### Windows The `thread_amount` function calls `CreateToolhelp32Snapshot` but fails to close the returned `HANDLE` using `CloseHandle`. Repeated calls to this function will cause the handle count of the process to grow indefinitely, eventually leading to system instability or process termination when the handle limit is reached. ### macOS / iOS The `thread_amount` function calls `task_threads` (via Mach kernel APIs) which allocates memory for the thread list. The function fails to deallocate this memory using `vm_deallocate`. Repeated calls will result in a steady memory leak, eventually causing the process to be killed by the OOM (Out of Memory) killer. ### Impact Long-running applications (such as servers, daemons, or monitoring tools) that use this crate to periodically check thread counts will eventually crash due to resource exhaustion. ### Resources - https://git...

GHSA-9m7r-g8hg-x3vr: SpiceDB: LookupResources with Multiple Entrypoints across Different Definitions Can Return Incomplete Results

### Impact If a schema includes the following characteristics: 1. Permission defined in terms of a union (`+`) 1. That union references the same relation on both sides, but one side arrows to a different permission Then you might have missing `LookupResources` results when checking the permission. This only affects `LookupResources`; other APIs calculate permissionship correctly. A small concrete example: ``` relation doer_of_things: user | group#member permission do_the_thing = doer_of_things + doer_of_things->admin ``` A CheckPermission on `do_the_thing` will return the correct permissionship, but a LookupResources on `do_the_thing` may miss resources. #### A Comprehensive Example If you have a schema with a structure like this: ``` definition special_user {} definition user { relation special_user_mapping: special_user permission special_user = special_user_mapping } definition group { relation member: user permission membership = member + member->special_user } ...

GHSA-j842-xgm4-wf88: MLX has Wild Pointer Dereference in load_gguf()

## Summary Segmentation fault in `mlx::core::load_gguf()` when loading malicious GGUF files. Untrusted pointer from external gguflib library is dereferenced without validation, causing application crash. Environment: - OS: Ubuntu 20.04.6 LTS - Compiler: Clang 19.1.7 ## Vulnerability **Location**: `mlx/io/gguf.cpp` - Function `extract_tensor_data()` at lines 59-79 - Vulnerable memcpy at lines 64-67 - Called from `load_arrays()` at line 177 **The Bug**: ```cpp std::tuple<allocator::Buffer, Dtype> extract_tensor_data(gguf_tensor* tensor) { std::optional<Dtype> equivalent_dtype = gguf_type_to_dtype(tensor->type); if (equivalent_dtype.has_value()) { allocator::Buffer buffer = allocator::malloc(tensor->bsize); memcpy( buffer.raw_ptr(), tensor->weights_data, // untrusted pointer from gguflib tensor->num_weights * equivalent_dtype.value().size()); return {buffer, equivalent_dtype.value()}; } // ... } ``` ## Possible Fix ```cpp std::tuple<allo...

GHSA-w6vg-jg77-2qg6: MLX has heap-buffer-overflow in load()

## Summary Heap buffer overflow in `mlx::core::load()` when parsing malicious NumPy `.npy` files. Attacker-controlled file causes 13-byte out-of-bounds read, leading to crash or information disclosure. Environment: - OS: Ubuntu 20.04.6 LTS - Compiler: Clang 19.1.7 ## Vulnerability The parser reads a 118-byte header from the file, but line 268 uses `std::string(&buffer[0])` which stops at the first null byte, creating a 20-byte string instead. Then line 276 tries to read `header[34]` without checking the length first, reading 13 bytes past the allocation. **Location**: `mlx/io/load.cpp:268,276` **Bug #1** (line 268): ```cpp std::string header(&buffer[0]); // stops at first null byte ``` **Bug #2** (line 276): ```cpp bool col_contiguous = header[34] == 'T'; // No bounds check ``` ## Possible Fix ```cpp // Line 268 std::string header(&buffer[0], header_len); // Line 276 if (header.length() < 35) throw std::runtime_error("Malformed header"); ``` ## PoC ```bash pip install mlx...

New Sturnus Android Malware Reads WhatsApp, Telegram, Signal Chats via Accessibility Abuse

Sturnus, an advanced Android banking trojan, has been discovered by ThreatFabric. Learn how this malware bypasses end-to-end encryption on Signal and WhatsApp, steals bank credentials using fake screens, and executes fraudulent transactions.