ghsa

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

### Impact Minder users may fetch content in the context of the Minder server, which may include URLs which the user would not normally have access to (for example, if the Minder server is behind a firewall or other network partition). ### Patches https://github.com/mindersec/minder/commit/f770400923984649a287d7215410ef108e845af8 ### Workarounds Users should avoid deploying Minder with access to sensitive resources. Unfortunately, this could include access to systems like OpenFGA or Keycloak, depending on the deployment configuration. ### References Sample ruletype: ```yaml version: v1 type: rule-type name: test-http-send display_name: Test that we can call http.send short_failure_message: Failed http.send severity: value: medium context: provider: github description: | ... guidance: | .... def: in_entity: repository rule_schema: type: object properties: {} ingest: type: git git: {} eval: type: rego violation_format: text rego: ...

An issue was discovered in Clerk-js 5.88.0 allowing attackers to bypass the OAuth authentication flow by manipulating the request at the OTP verification stage.

In `authkit-nextjs` version 2.11.0 and below, authenticated responses do not defensively apply anti-caching headers. In environments where CDN caching is enabled, this can result in session tokens being included in cached responses and subsequently served to multiple users. Next.js applications deployed on Vercel are unaffected **unless** they manually enable CDN caching by setting cache headers on authenticated paths. ### Impact This vulnerability may lead to session caching, potentially allowing unauthorized users to obtain another user’s session token. The severity depends on deployment configuration, caching policy, and whether authenticated routes are inadvertently cached. ### Patches Patched in `authkit-nextjs` 2.11.1, which applies anti-caching headers to all responses behind authentication. ### Notes Authentication middleware should set anti-caching headers for authenticated routes as a defense in depth measure, but cannot guarantee these headers will not be overwritten els...