ghsa

### Overview The authentication tag of encrypted JWEs can be brute forced, which may result in loss of confidentiality for those JWEs and provide ways to craft arbitrary JWEs. ### Impact - JWEs can be modified to decrypt to an arbitrary value - JWEs can be decrypted by observing parsing differences - The GCM internal [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=\)%20is%20the-,hash%20key,-%2C%20a%20string%20of) can be recovered ### Am I Affected? You are affected by this vulnerability even if you do not use an `AES-GCM` encryption algorithm for your JWEs. ### Patches The version 1.1.1 fixes the issue by adding the tag length check for the `AES-GCM` algorithm. **Important:** As the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=\)%20is%20the-,hash%20key,-%2C%20a%20string%20of) could have leaked, you must rotate the encryption keys after upgrading to version 1.1.1. ### References [Félix Charette talk at NorthSec 2025 about the issue](h...

## Impact Cloudflare quiche was discovered to be vulnerable to an infinite loop when sending packets containing RETIRE_CONNECTION_ID frames. QUIC connections possess a set of connection identifiers (IDs); see [Section 5.1 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-5.1). Once the QUIC handshake completes, a local endpoint is responsible for issuing and retiring Connection IDs that are used by the remote peer to populate the Destination Connection ID field in packets sent from remote to local. Each Connection ID has a sequence number to ensure synchronization between peers An unauthenticated remote attacker can exploit this vulnerability by first completing a handshake and then sending a specially-crafted set of frames that trigger a connection ID retirement in the victim. When the victim attempts to send a packet containing RETIRE_CONNECTION_ID frames, [Section 19.16 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-19.16) requires that the se...

## Impact In versions 0.8.5 and earlier of uv, remote ZIP archives were handled in a streamwise fashion, and file entries were not reconciled against the archive's central directory. This enabled two parser differentials against other Python package installers: 1. An attacker could contrive a ZIP archive that would extract with legitimate contents on some package installers, and malicious contents on others due to multiple local file entries. The attacker could choose which installer to target. 2. An attacker could contrive a "stacked" ZIP input with multiple internal ZIPs, which would be handled differently by different package installers. The attacker could choose which installer to target. In both cases, the outcome is that an attacker can produce a ZIP with a consistent digest that expands differently with different installers. The [ZIP standard](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) is ambiguous with respect to these behavior differentials. Consequently,...

An issue in Ollama v0.1.33 allows attackers to delete arbitrary files via sending a crafted packet to the endpoint /api/pull.

## Summary When using `Card.get_model`, `skops` allows for arbitrary code execution. This is due to the fact that `Card.get_model` allows both `joblib` and `skops` to be used for loading models, and as is well known, `joblib` allows for arbitrary code execution when loading objects. I do not know if this is intended or not, but I found this really concerning for a library that is founded on security. Even if intended, I kindly ask you to consider the security implications of this, disclose the potential implications through an advisory, and change the behavior of the function in future library versions (see below for possible fixes). ## What is the issue? The `Card.get_model` function allows loading models using the `get_model` method. When a `.skops` model is provided, it uses the `load` function from `skops`, which is secure to our knowledge. The `Card` class also allows consistent management of the `trusted` list, allowing it to be passed during instance creation. As expected, if...

## Summary There is an Open Redirection vulnerability in the trailing slash redirection logic when handling paths with double slashes. This allows an attacker to redirect users to arbitrary external domains by crafting URLs such as `https://mydomain.com//malicious-site.com/`. This increases the risk of phishing and other social engineering attacks. This affects Astro >=5.2.0 sites that use on-demand rendering (SSR) with the Node or Cloudflare adapter. It does not affect static sites, or sites deployed to Netlify or Vercel. ## Background Astro performs automatic redirection to the canonical URL, either adding or removing trailing slashes according to the value of the [`trailingSlash`](https://docs.astro.build/en/reference/configuration-reference/#trailingslash) configuration option. It follows the following rules: - If `trailingSlash` is set to `"never"`, `https://example.com/page/` will redirect to `https://example.com/page` - If `trailingSlash` is set to `"always"`, `https://exa...

### Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-mh55-gqvf-xfwm. This link is maintained to preserve external references. ### Original Description Middleware causes a prohibitive amount of heap allocations when processing malicious preflight requests that include a Access-Control-Request-Headers (ACRH) header whose value contains many commas. This behavior can be abused by attackers to produce undue load on the middleware/server as an attempt to cause a denial of service.

A vulnerability was found in Keycloak-services. Special characters used during e-mail registration may perform SMTP Injection and unexpectedly send short unwanted e-mails. The email is limited to 64 characters (limited local part of the email), so the attack is limited to very shorts emails (subject and little data, the example is 60 chars). This flaw's only direct consequence is an unsolicited email being sent from the Keycloak server. However, this action could be a precursor for more sophisticated attacks.

### Impact A protocol compliance bug in thinbus-srp-npm versions prior to 2.0.1 causes the client to generate a fixed 252 bits of entropy instead of the intended bit length of the safe prime (defaulted to 2048 bits). RFC 5054 states in section [2.5.4 Client Key Exchange ](https://datatracker.ietf.org/doc/html/rfc5054#section-2.5.4) > The client key exchange message carries the client's public value (A). The client calculates this value as A = g^a % N, where a is a random number that SHOULD be at least 256 bits in length. The client public value is being generated from a private value that is 4 bits below the specification. This reduces the protocol's designed security margin it is now practically exploitable. The servers full sized 2048 bit random number is used to create the shared session key and password proof. ### Patches The issue is fixed in versions >= 2.0.1 ### Workarounds It is possible to patch a legacy version: ```javascript // WRONG var hexLength = this.toHe...

## Summary It was discovered that the github.com/go-acme/lego/v4/acme/api package (thus the lego library and the lego cli as well) don't enforce HTTPS when talking to CAs as an ACME client. ## Details Unlike the http-01 challenge which solves an ACME challenge over unencrypted HTTP, the ACME protocol requires HTTPS when a client communicates with the CA to performs ACME functions. This is stated in 6.1 of RFC 8555: [https://datatracker.ietf.org/doc/html/rfc8555#section-6.1](https://datatracker.ietf.org/doc/html/rfc8555#section-6.1) > Each ACME function is accomplished by the client sending a sequence > of HTTPS requests to the server [[RFC2818](https://datatracker.ietf.org/doc/html/rfc2818)], carrying JSON messages > [[RFC8259](https://datatracker.ietf.org/doc/html/rfc8259)]. Use of HTTPS is REQUIRED. Each subsection of [Section 7](https://datatracker.ietf.org/doc/html/rfc8555#section-7) > below describes the message formats used by the function and the > order in which messages ...