ghsa

An issue in trenoncourt AutoQueryable v.1.7.0 allows a remote attacker to obtain sensitive information via the Unselectable function.

A vulnerability, that could result in Remote Code Execution (RCE), has been found in DocsGPT. Due to improper parsing of JSON data using eval() an unauthorized attacker could send arbitrary Python code to be executed via /api/remote endpoint. This issue affects DocsGPT: from 0.8.1 through 0.12.0.

An issue was discovered in Kwik before 0.10.1. A hash collision vulnerability (in the hash table used to manage connections) allows remote attackers to cause a considerable CPU load on the server (a Hash DoS attack) by initiating connections with colliding Source Connection IDs (SCIDs).

Hermes versions up to 0.4.0 improperly validated the JWT provided when using the AWS ALB authentication mode, potentially allowing for authentication bypass. This vulnerability, CVE-2025-1293, was fixed in Hermes 0.5.0.

## Summary Nokogiri v1.18.3 upgrades its dependency libxml2 to [v2.13.6](https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.13.6). libxml2 v2.13.6 addresses: - CVE-2025-24928 - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/847 - CVE-2024-56171 - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/828 ## Impact ### CVE-2025-24928 Stack-buffer overflow is possible when reporting DTD validation errors if the input contains a long (~3kb) QName prefix. ### CVE-2024-56171 Use-after-free is possible during validation against untrusted XML Schemas (.xsd) and, potentially, validation of untrusted documents against trusted Schemas if they make use of `xsd:keyref` in combination with recursively defined types that have additional identity constraints.

### Summary The reverse port forwarding in sliver teamserver allows the implant to open a reverse tunnel on the sliver teamserver without verifying if the operator instructed the implant to do so ### Reproduction steps Run server ``` wget https://github.com/BishopFox/sliver/releases/download/v1.5.42/sliver-server_linux chmod +x sliver-server_linux ./sliver-server_linux ``` Generate binary ``` generate --mtls 127.0.0.1:8443 ``` Run it on windows, then `Task manager -> find process -> Create memory dump file` Install RogueSliver and get the certs ``` git clone https://github.com/ACE-Responder/RogueSliver.git pip3 install -r requirements.txt --break-system-packages python3 ExtractCerts.py implant.dmp ``` Start callback listener. Teamserver will connect when POC is run and send "ssrf poc" to nc ``` nc -nvlp 1111 ``` Run the poc (pasted at bottom of this file) ``` python3 poc.py <SLIVER IP> <MTLS PORT> <CALLBACK IP> <CALLBACK PORT> python3 poc.py 192.168.1.33 8443 44.221.186.72 1111...

Overview OpenFGA v1.8.4 or previous (Helm chart < openfga-0.2.22, docker < v.1.8.5) are vulnerable to authorization bypass when certain Check and ListObject calls are executed. Am I Affected? If you are using OpenFGA v1.8.4 or previous, specifically under the following conditions, you are affected by this authorization bypass vulnerability: - Calling Check API or ListObjects with a model that has a relation [directly assignable](https://openfga.dev/docs/concepts#what-is-a-directly-related-user-type) to both [public access](https://openfga.dev/docs/concepts#what-is-type-bound-public-access) AND [userset](https://openfga.dev/docs/concepts#what-is-a-user) with the [same type](https://openfga.dev/docs/concepts#what-is-a-type), and - A type bound public access tuple is assigned to an object, and - userset tuple is not assigned to the same object, and - Check request's user field is a userset that has the same type as the type bound public access tuple's user type Fix Upgrade to v1.8.5. ...

### Summary If users are allowed to sign in via both username and email the regulation system treats these as separate login events. This leads to the regulation limitations being effectively doubled assuming an attacker using brute-force to find a user password. It's important to note that due to the effective operation of regulation where no user-facing sign of their regulation ban being visible either via timing or via API responses, it's effectively impossible to determine if a failure occurs due to a bad username password combination, or a effective ban blocking the attempt which heavily mitigates any form of brute-force. ### Details This occurs because the records and counting process for this system uses the method utilized for sign in rather than the effective username attribute. ### Impact This has a minimal impact on account security, this impact is increased naturally in scenarios when there is no two-factor authentication required and weak passwords are used. This make...

### Summary Duende.AccessTokenManagement contains a race condition when requesting access tokens using the client credentials flow. Concurrent requests to obtain an access token using differing protocol parameters can return access tokens obtained with the wrong scope, resource indicator, or other protocol parameters. Such usage is somewhat atypical, and only a small percentage of users are likely to be affected. ### Details Duende.AccessTokenManagement can request access tokens using the client credentials flow in several ways. In basic usage, the client credentials flow is configured once and the parameters do not vary. In more advanced situations, requests with varying protocol parameters may be made by calling specific overloads of these methods: - `HttpContext.GetClientAccessTokenAsync()` - `IClientCredentialsTokenManagementService.GetAccessTokenAsync()` There are overloads of both of these methods that accept a `TokenRequestParameters` object that customizes token request para...

### Summary If there are two overlapping policies for the `update` action that allow access to different fields, instead of correctly checking access permissions against the item they apply for the user is allowed to update the superset of fields allowed by any of the policies. E.g. have one policy allowing update access to `field_a` if the `id == 1` and one policy allowing update access to `field_b` if the `id == 2`. The user with both these policies is allowed to update both `field_a` and `field_b` for the items with ids `1` and `2`. ### Details Before v11, if a user was allowed to update an item they were allowed to update the fields that the single permission, that applied to that item, listed. With overlapping permissions this isn't as clear cut anymore and the union of fields might not be the fields the user is allowed to update for that specific item. The solution that this PR introduces is to evaluate the permissions for each field that the user tries to update in the vali...