ghsa

An issue was discovered in Free5GC v4.0.0 and v4.0.1 allowing an attacker to cause a denial of service via crafted POST request to the Npcf_BDTPolicyControl API.

An issue was discovered in Free5GC v4.0.0 and v4.0.1 allowing an attacker to cause a denial of service via the Nudm_SubscriberDataManagement API.

Apache Syncope can be configured to store the user password values in the internal database with AES encryption, though this is not the default option. When AES is configured, the default key value, hard-coded in the source code, is always used. This allows a malicious attacker, once obtained access to the internal database content, to reconstruct the original cleartext password values. This is not affecting encrypted plain attributes, whose values are also stored using AES encryption. Users are recommended to upgrade to version 3.0.15 / 4.0.3, which fix this issue.

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

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

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

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

SCIM provisioning was introduced in Grafana Enterprise and Grafana Cloud in April to improve how organizations manage users and teams in Grafana by introducing automated user lifecycle management. In Grafana versions 12.x where SCIM provisioning is enabled and configured, a vulnerability in user identity handling allows a malicious or compromised SCIM client to provision a user with a numeric externalId, which in turn could allow to override internal user IDs and lead to impersonation or privilege escalation. This vulnerability applies only if all of the following conditions are met: - `enableSCIM` feature flag set to true - `user_sync_enabled` config option in the `[auth.scim]` block set to true

Vault’s Terraform Provider incorrectly set the default deny_null_bind parameter for the LDAP auth method to false by default, potentially resulting in an insecure configuration. If the underlying LDAP server allowed anonymous or unauthenticated binds, this could result in authentication bypass. This vulnerability, CVE-2025-13357, is fixed in Vault Terraform Provider v5.5.0.

### Overview OpenFGA v1.4.0 to v1.11.0 (openfga-0.1.34 <= Helm chart <= openfga-0.2.48, v.1.4.0 <= docker <= v.1.11.0) are vulnerable to improper policy enforcement when certain Check and ListObject calls are executed. ### Am I Affected? You are affected by this vulnerability if you meet the following preconditions: - You are using OpenFGA v1.4.0 to v1.11.0 - The model has a a relation directly assignable by a [type bound pubic access](https://openfga.dev/docs/concepts#what-is-type-bound-public-access) with [condition](https://openfga.dev/docs/modeling/conditions) - The same relation is not assignable by a type bound public access without condition - You have a type assigned for the same relation that is a type bound public access without condition ### Fix Upgrade to v1.11.1. This upgrade is backwards compatible. ### Workaround None