ghsa

### Impact When a Node.js application using the Sentry SDK has `sendDefaultPii: true` it is possible to inadvertently send certain sensitive HTTP headers, including the `Cookie` header, to Sentry. Those headers would be stored within the Sentry organization as part of the associated trace. A person with access to the Sentry organization could then view and use these sensitive values to impersonate or escalate their privileges within a user's application. Users may be impacted if: 1. The Sentry SDK configuration has `sendDefaultPii` set to `true` 2. The application uses one of the Node.js Sentry SDKs with version from `10.11.0` to `10.26.0` inclusively: - @sentry/astro - @sentry/aws-serverless - @sentry/bun - @sentry/google-cloud-serverless - @sentry/nestjs - @sentry/nextjs - @sentry/node - @sentry/node-core - @sentry/nuxt - @sentry/remix - @sentry/solidstart - @sentry/sveltekit Users can check if their project was affected, by visiting Explore → Traces and searching for “http.requ...

### Impact Similar to HCSEC-2025-13 / CVE-2025-5999, a privileged operator could use the identity group subsystem to add a root policy to a group identity group, escalating their or another user's permissions in the system. Specifically this is an issue when: 1. An operator in the root namespace has access to `identity/groups` endpoints. 2. An operator does not have policy access. Otherwise, an operator with policy access could create or modify an existing policy to grant root-equivalent permissions through the `sudo` capability. ### Patches Patched in version 2.4.4. ### Workarounds Users should audit the use of identity subsystem and deny operators access if it is not in use.

### Summary A recently patched SSRF vulnerability contains a bypass method that can bypass the existing security fix and still allow SSRF to occur. Because the existing fix only applies security restrictions to the first URL request, a 302 redirect can bypass existing security measures and successfully access the intranet. ### Details Use the following script to deploy on the attacker's server. Since ports 80, 443, and 8080 are default ports within the security range set by the administrator and will not be blocked, the service is deployed on port 8080. ``` from flask import Flask, redirect app = Flask(__name__) @app.route('/redirect') def ssrf_redirect(): return redirect('http://127.0.0.1:8003/uid.txt', code=302) if __name__ == '__main__': app.run(host='0.0.0.0', port=8080) ``` Then, a request is made to the malicious service opened by the attacker, and it can be found that the resources on the intranet are successfully accessed. <img width="663" height="...

A vulnerability has been identified in keylime where an attacker can exploit this flaw by registering a new agent using a different Trusted Platform Module (TPM) device but claiming an existing agent's unique identifier (UUID). This action overwrites the legitimate agent's identity, enabling the attacker to impersonate the compromised agent and potentially bypass security controls.

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 crafted POST request to the Nnssf_NSSAIAvailability 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 } ...