ghsa

### Summary The server trusts all reverse-proxy headers by default, so any remote client can spoof `X-Forwarded-For` to bypass IP-based protections (AllowIPs, API IP whitelist, “localhost-only” checks). All IP-based access control becomes ineffective. ### Details - Gin is created with defaults (`gin.Default()`), which sets `TrustedProxies = 0.0.0.0/0` and uses `X-Forwarded-For`/`X-Real-IP` to compute `ClientIP()`. - IP-based controls rely on `ClientIP()`: - AllowIPs / BindDomain (core/middleware/ip_limit.go, core/utils/security/security.go). - API IP whitelist (core/middleware/api_auth.go). - "localhost-only" checks that depend on `ClientIP()`. - Because no trusted-proxy range is enforced, any client can send `X-Forwarded-For: 127.0.0.1` (or a whitelisted IP) and be treated as coming from that address. ### Impact All IP-based access control is rendered ineffective: remote clients can masquerade as localhost or any whitelisted IP, defeating AllowIPs, API IP whitelists, a...

### Summary A CAPTCHA bypass vulnerability in the 1Panel authentication API allows an unauthenticated attacker to disable CAPTCHA verification by abusing a client-controlled parameter. Because the server previously trusted this value without proper validation, CAPTCHA protections could be bypassed, enabling automated login attempts and significantly increasing the risk of account takeover (ATO). ### Details The /api/login endpoint accepts a boolean field named ignoreCaptcha directly from the client request body: `"ignoreCaptcha": true` The backend implementation uses this value to determine whether CAPTCHA validation should be performed: ``` if !req.IgnoreCaptcha { if errMsg := captcha.VerifyCode(req.CaptchaID, req.Captcha); errMsg != "" { helper.BadAuth(c, errMsg, nil) return } } ``` Because req.IgnoreCaptcha is taken directly from user input—with no server-side validation, no session binding, and no privilege checks—any unauthenticated attacker can fo...

## Impact There is a potential vulnerability in Traefik NGINX provider managing the `nginx.ingress.kubernetes.io/proxy-ssl-verify` annotation. The provider inverts the semantics of the `nginx.ingress.kubernetes.io/proxy-ssl-verify` annotation. Setting the annotation to `"on"` (intending to enable backend TLS certificate verification) actually disables verification, allowing man-in-the-middle attacks against HTTPS backends when operators believe they are protected. ## Patches - https://github.com/traefik/traefik/releases/tag/v3.6.3 ## For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues). <details> <summary>Original Description</summary> ### Summary A logic error in Traefik's experimental ingress-nginx provider inverts the semantics of the `nginx.ingress.kubernetes.io/proxy-ssl-verify` annotation. Setting the annotation to `"on"` (intending to enable backend TLS certificate verification)...

## 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...