ghsa

### Summary An authentication bypass vulnerability exists due to a flaw in the libxml2 canonicalization process, which is used by [xmlseclibs](https://github.com/robrichards/xmlseclibs) during document transformation. This weakness allows an attacker to generate a valid signature once and reuse it indefinitely. In practice, a signature created during a previous interaction - or through a misconfigured authentication flow - can be replayed to bypass authentication checks. ### Details When libxml2’s canonicalization is invoked on an invalid XML input, it may return an empty string rather than a canonicalized node. [xmlseclibs](https://github.com/robrichards/xmlseclibs) then proceeds to compute the DigestValue over this empty string, treating it as if canonicalization succeeded. https://github.com/robrichards/xmlseclibs/blob/f4131320c6dcd460f1b0c67f16f8bf24ce4b5c3e/src/XMLSecurityDSig.php#L296 ### Impact Digest bypass: By crafting input that causes canonicalization to yield an empty st...

## Summary Critical security vulnerabilities exist in both the `UUIDv4()` and `UUID()` functions of the `github.com/gofiber/utils` package. When the system's cryptographic random number generator (`crypto/rand`) fails, both functions silently fall back to returning predictable UUID values, including the zero UUID `"00000000-0000-0000-0000-000000000000"`. This compromises the security of all Fiber applications using these functions for security-critical operations. **Both functions are vulnerable to the same root cause (`crypto/rand` failure):** - `UUIDv4()`: Indirect vulnerability through `uuid.NewRandom()` → `crypto/rand.Read()` → fallback to `UUID()` - `UUID()`: Direct vulnerability through `crypto/rand.Read(uuidSeed[:])` → silent zero UUID return ## Vulnerability Details ### Affected Functions - **Package**: `github.com/gofiber/utils` - **Functions**: `UUIDv4()` and `UUID()` - **Return Type**: `string` (both functions) - **Locations**: `common.go:93-99` (UUIDv4), `common.go:60-8...

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