ghsa

## Impact There is a potential vulnerability in Traefik managing the requests using a `PathPrefix`, `Path` or `PathRegex` matcher. When Traefik is configured to route the requests to a backend using a matcher based on the path; if the request path contains an encoded restricted character from the following set **('/', '\', 'Null', ';', '?', '#')**, it’s possible to target a backend, exposed using another router, by-passing the middlewares chain. ## Example ```yaml apiVersion: traefik.io/v1alpha1 kind: IngressRoute metadata: name: my-service spec: routes: - match: PathPrefix(‘/admin/’) kind: Rule services: - name: service-a port: 8080 middlewares: - name: my-security-middleware - match: PathPrefix(‘/’) kind: Rule services: - name: service-a port: 8080 ``` In such a case, the request `http://mydomain.example.com/admin%2F` will reach the backend `service-a` without operating the middleware `my-secur...

# Authentication Bypass via Double URL Encoding in Astro ## Bypass for CVE-2025-64765 / GHSA-ggxq-hp9w-j794 --- ### Summary A **double URL encoding bypass** allows any unauthenticated attacker to bypass path-based authentication checks in Astro middleware, granting unauthorized access to protected routes. While the original CVE-2025-64765 (single URL encoding) was fixed in v5.15.8, the fix is insufficient as it only decodes once. By using double-encoded URLs like `/%2561dmin` instead of `/%61dmin`, attackers can still bypass authentication and access protected resources such as `/admin`, `/api/internal`, or any route protected by middleware pathname checks. ## Fix A more secure fix is just decoding once, then if the request has a %xx format, return a 400 error by using something like : ``` if (containsEncodedCharacters(pathname)) { // Multi-level encoding detected - reject request return new Response( 'Bad Request: Multi-level URL encodin...

### Impact This vulnerability affects all Emby Server versions - beta and stable up to the specified versions. It allows an attacker to gain full administrative access to an Emby Server (for Emby Server administration, **not at the OS level**,). Other than network access, no specific preconditions need to be fulfilled for a server to be vulnerable. ### Patches #### Quick Fix A quick fix will be rolled out via an update to one of the default-included Emby Server plugins. This way is chosen because many users are updating their servers manually while plugin updates are typically configured to be applied automatically. This allows to get a patch deployed to a large amount of servers within a single day. #### Server Patches Patched versions for both, Emby Server stable and Emby Server beta are available now. **All Emby Server owners are strongly encouraged to apply those updates as soon as possible.** ### Workarounds > [!NOTE] > These workarounds are OBSOLETE now. Please update E...

### Impact In some situations, Strimzi creates an incorrect Kubernetes `Role` which grants the Apache Kafka Connect and Apache Kafka MirrorMaker 2 operands the `GET` access to all Kubernetes Secrets that exist in the given Kubernetes namespace. The exact scenario when this happens is when: * Apache Kafka Connect is deployed without at least one of the following options configured: * TLS encryption with configured trusted certificates (no `.spec.tls.trustedCertificates` section in the `KafkaConnect` CR) * mTLS authentication (no `type: tls` in `.spec.authentication` section of the `KafkaConnect` CR) * TLS encryption with configured trusted certificates for `type: oauth` authentication (no `.spec.authentication.tlsTrustedCertificates` section in the `KafkaConnect` CR) * Apache Kafka MirrorMaker2 is deployed without at least one of the following options configured for the target cluster: * TLS encryption with configured trusted certificates (no `.spec.target.tls.trustedCe...

## Summary Adding default PCR12 validation to ensure that account operators can not modify kernel command line parameters, potentially bypassing root filesystem integrity validation. Attestable AMIs are based on the systemd Unified Kernel Image (UKI) concept which uses systemd-boot to create a single measured UEFI binary from a Linux kernel, its initramfs, and kernel command line. The embedded kernel command line contains a dm-verity hash value that establishes trust in the root file system. When UEFI Secure Boot is disabled, systemd-boot appends any command line it receives to the kernel command line. Account operators with the ability to modify UefiData can install a boot variable with a command line that deactivates root file system integrity validation, while preserving the original PCR4 value. Systemd-boot provides separate measurement of command line modifications in PCR12. ## Impact In line with the TPM 2.0 specification and systemd-stub logic, KMS policies that do not inc...

### Summary Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are *not* affected. ### Details During the decompression process, the lz4 algorithm may have to repeat data that was previously decompressed in the same input frame. In the Java implementation, this is implemented by copy operations within the output buffer. With a crafted input, an attacker may induce the Java implementation to copy from a region in the output buffer that does not contain decompressed data yet. If that region contains sensitive information because the output buffer was not cleared prior to decompression, that data will then be copied to the decompressed output. - `LZ4Factory.nativeInstance().safeDecompresso...

### Impact **Excessive memory allocation** Function [api.ParseJSONRequest](https://github.com/sigstore/timestamp-authority/blob/26d7d426d3000abdbdf2df34de56bb92246c0365/pkg/api/timestamp.go#L63) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) an optionally-provided OID (which is untrusted data) on periods. Similarly, function [api.getContentType](https://github.com/sigstore/timestamp-authority/blob/26d7d426d3000abdbdf2df34de56bb92246c0365/pkg/api/timestamp.go#L114) splits the `Content-Type` header (which is also untrusted data) on an `application` string. As a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed `Content-Type` header, a call to `api.ParseJSONRequest` or `api.getContentType` incurs allocations of O(n) bytes (where n stands for the length of the function's argument). Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](h...

Function [identity.extractIssuerURL](https://github.com/sigstore/fulcio/blob/main/pkg/identity/issuerpool.go#L44-L45) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) its argument (which is untrusted data) on periods. As a result, in the face of a malicious request with an (invalid) OIDC identity token in the payload containing many period characters, a call to `extractIssuerURL` incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html) Details See [identity.extractIssuerURL](https://github.com/sigstore/fulcio/blob/main/pkg/identity/issuerpool.go#L44-L45) Impact Excessive memory allocation

### Impact urllib3's [streaming API](https://urllib3.readthedocs.io/en/2.5.0/advanced-usage.html#streaming-and-i-o) is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side, even if the application only requ...

## Impact urllib3 supports chained HTTP encoding algorithms for response content according to RFC 9110 (e.g., `Content-Encoding: gzip, zstd`). However, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. ## Affected usages Applications and libraries using urllib3 version 2.5.0 and earlier for HTTP requests to untrusted sources unless they disable content decoding explicitly. ## Remediation Upgrade to at least urllib3 v2.6.0 in which the library limits the number of links to 5. If upgrading is not immediately possible, use [`preload_content=False`](https://urllib3.readthedocs.io/en/2.5.0/advanced-usage.html#streaming-and-i-o) and ensure that `resp.headers["content-encoding"]` contains a safe number of encodings before reading the response content.