Search: github.com

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (4b1f6143f5a7c6106ab4ba0a21a6adaf9020e332835b1e528de6f36b64537734) index.js is advertised as a Foundry gas-report diff utility but on module load / CLI run schedules a setTimeout of 259,200,000 ms (3 days) that calls https.get against https://gist.githubusercontent.com/opensource-crypto/3946ef88aa057c9d10f1a7d80391d164/raw/default.json. The gist is hosted on a GitHub account (opensource-crypto) unrelated to the declared package publisher (danird9). If the fetched JSON contains a `c2` field, the value is persisted to ~/.forge-gas-diff.remote for later use. A separate getInstallId() routine writes a per-host UUID to ~/.forge-gas-diff, providing a stable install fingerprint. None of this behavior — outbound network fetch, install-ID generation, remote-config persistence, or a field literally named `c2` — has any relationship to the advertised gas-diff functionality and is not documented in the package. The gist is author-mutable, so the content delivered to installers can be changed at any time without republishing the package; the 3-day delay places the fetch well outside typical install-time sandboxing windows. The mechanism is the staging half of a remote-config-driven dropper: a hidden update channel keyed to attacker-editable content on a third-party host, with persistence to a well-known filesystem path on the installer's machine.

The npm package gas-diff-core version 1.0.0 contains malicious code that, upon being required, executes a script persisting an install timestamp and UUID locally. After 72 hours, it periodically fetches JSON data from a mutable GitHub Gist controlled by an anonymous account unrelated to the package publisher. If the fetched JSON contains a 'c2' key, its value is written to a hidden local file, enabling command-and-control (C2) configuration. The 72-hour delay is designed to evade detection in short-lived environments such as CI pipelines or sandboxes.

The PyPI package 'speed-hashes' version 0.1.0 is a malicious typosquatting package that executes attacker-controlled code during installation. Its setup.py overrides the install command to decode and execute obfuscated Python code which downloads a remote binary from an untrusted GitHub repository, executes it detached, and exfiltrates cryptocurrency wallet data. This results in remote code execution on the installer's host and potential data theft.

A self-propagating npm worm dubbed ChainDrop infected over 400 packages downloaded hundreds of millions of times weekly, including popular packages like keyv and cacheable-request. The worm steals cloud credentials, npm and GitHub tokens, SSH keys, and sensitive developer data while extracting temporary credentials from GitHub Actions runner memory. It uses stolen npm publishing tokens to infect additional packages while maintaining their legitimate functionality. The attackers established persistence through VS Code and Claude Code configurations, employed blockchain-based command-and-control resolution via Ethereum smart contracts, and can execute attacker-supplied code. The operator demonstrated ability to silently reconfigure C2 infrastructure through Ethereum transactions without updating deployed instances. ChainDrop employs three layers of obfuscation and encryption, exfiltrates data through encrypted channels, and publishes stolen tokens in public commit messages.

The fast-hashes package version 0.1.0 on PyPI contains malicious code that executes during installation. The setup.py file overrides the install command to decode and execute a base64-encoded payload, which downloads and runs an unverified binary from a third-party GitHub repository. This behavior enables arbitrary code execution on the installer's host. The package is a typosquatting attempt mimicking a popular library and is designed to exfiltrate cryptocurrency wallet data and potentially other sensitive information.

GitHub CLI (gh) versions prior to 2.97.0 contain a vulnerability where HTTP request URLs interpolate variable path components without percent encoding. This allows URL path metacharacters in attacker-controlled repository or resource values to cause the CLI to address a different API endpoint or resource than intended. The issue is fixed in version 2.97.0.

GitHub CLI (gh) versions prior to 2.97.0 have a vulnerability where multiple commands print externally controlled content without neutralizing terminal escape sequences. This allows an attacker who can influence that content to embed escape sequences that may be interpreted by the user's terminal, potentially causing cosmetic manipulation or, on some terminal emulators, command execution. The issue affects various commands beyond those addressed in a previous related vulnerability (CVE-2026-45803). The vulnerability is fixed in version 2.97.0.

GitHub CLI (gh) versions prior to 2.97.0 contain a vulnerability in the attestation verification process where user-supplied repository or workflow names are treated as regular expressions without escaping regex metacharacters. This allows an attacker to create lookalike repository or workflow names that bypass intended Sigstore attestation verification, potentially undermining supply chain verification in CI/CD pipelines. The issue is fixed in version 2.97.0.

The npm package vite-plugin-cleaner version 4.1.3 includes an optional dependency on vite-cleaning-tools, which is fetched directly from a mutable GitHub repository reference without a fixed commit or tag. This causes the postinstall script to execute code from the latest GitHub HEAD on every npm install, allowing the repository maintainer or anyone with write access to inject arbitrary code at install time without publishing a new npm version.

The npm package move-bcs-codec versions 1.0.0, 1.0.1, and 1.0.2 contains malicious code that executes a postinstall script to exfiltrate sensitive private keys and configuration files related to the Sui blockchain wallet. The script collects private keys and config files, encodes them, and uploads them to a GitHub repository using a hardcoded bearer token. It also attempts to evade detection by skipping execution in CI environments and removing evidence after execution. This compromises any system with the package installed, risking full wallet compromise and loss of on-chain funds.

## Summary There is a high severity vulnerability in Traefik's BasicAuth, DigestAuth, and ForwardAuth middlewares. The fix for CVE-2026-33433 stripped canonical-cased spoofed identity headers (e.g. `X-Auth-User`) before writing Traefik's own value, but did not account for underscore-variant header names (e.g. `X_Auth_User`), which many backends normalize identically to the dashed form. An attacker able to reach a protected route could inject an underscore-variant header that survives Traefik's stripping and reaches the backend alongside — or, on the unauthenticated ForwardAuth `authResponseHeaders` path, instead of — the value Traefik intended to set, spoofing identity or authorization context. This is fixed by setting the new `allowHeadersWithUnderscores: false` entry point option, which strips all headers with underscores in their names before routing. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.51 - https://github.com/traefik/traefik/releases/tag/v3.6.22 - https://github.com/traefik/traefik/releases/tag/v3.7.6 ## 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> # Incomplete fix for CVE-2026-33433 + CVE-2026-39858 cross-cohort: `headerField` underscore-variant identity spoofing in BasicAuth / DigestAuth / ForwardAuth ## Summary The fix for CVE-2026-33433 (GHSA-qr99-7898-vr7c, "BasicAuth/DigestAuth Identity Spoofing via Non-Canonical headerField", patched in v2.11.42 / v3.6.12 / v3.7.0-ea.3) added `req.Header.Del(headerField)` before the literal-key writeback in `pkg/middlewares/auth/basic_auth.go` and `pkg/middlewares/auth/digest_auth.go`. Go's `Header.Del` calls `textproto.CanonicalMIMEHeaderKey` which canonicalizes ASCII CASE and treats `-` as a word separator — so the fix correctly strips canonical-cased attacker headers (`X-Auth-User`, `x-auth-user`, `X-AUTH-USER`, etc.). However, `textproto.CanonicalMIMEHeaderKey` does **NOT** treat `_` as a separator. Attacker-supplied **underscore-variant** headers such as `X_Auth_User` survive `Header.Del("X-Auth-User")` intact and are forwarded to the backend alongside Traefik's own writeback. Many common backends (CGI/WSGI per RFC 3875, PHP `$_SERVER`, nginx with `underscores_in_headers on`, Tomcat / Java EE servlet containers, ASGI/WSGI frameworks) normalize `_` ↔ `-` equivalently or expose both forms to application code that may read the attacker's value. This is the **direct cross-cohort sibling** of the threat model the maintainer accepted in **CVE-2026-39858** (GHSA-5m6w-wvh7-57vm, "Forwarded alias spoofing pre-auth decision bypass"), which fixed the underscore-variant of the X-Forwarded-* family via `isManagedXHeader` in `pkg/middlewares/forwardedheaders/forwarded_header.go`. The CVE-2026-39858 advisory body states verbatim: > "When the backend normalizes underscore and dash header forms equivalently, an attacker can inject spoofed trust context — such as a trusted scheme or host — through the alias headers and bypass authentication on protected routes without valid credentials." The same threat model applies to the operator-configurable `headerField` (BasicAuth, DigestAuth) and `authResponseHeaders` (ForwardAuth, ingress-nginx snippet provider), but the underscore-handling primitive (`isManagedXHeader`) was not extended to those middlewares. I verified the bypass end-to-end on `traefik:v3.6.14` (the latest patched release containing both fixes) using a default-recommended canonical `headerField: "X-Auth-User"` config and reproduced the bypass with a single `curl -H "X_Auth_User: superadmin" ...` request alongside valid BasicAuth credentials. The defect is present in four code paths at HEAD `eec68dce064f843b4317c4393aaea81b6dea31d6`: 1. `pkg/middlewares/auth/basic_auth.go:101-105` — BasicAuth `headerField` 2. `pkg/middlewares/auth/digest_auth.go:99-103` — DigestAuth `headerField` 3. `pkg/middlewares/auth/forward.go:304-310` — ForwardAuth `authResponseHeaders` per-name writeback 4. `pkg/middlewares/ingressnginx/snippet/snippet.go:480-486` — Ingress-NGINX snippet `authResponseHeaders` per-name writeback The ForwardAuth instance (#3) is particularly notable: the attacker does NOT need credentials. The `authResponseHeaders` mechanism is intended to copy identity headers from the trusted auth server only; the underscore-variant bypass lets an unauthenticated attacker pre-inject the same identity header before any auth happens. The fast proxy at `pkg/proxy/fast/proxy.go:139` explicitly calls `DisableNormalizing()` on the outgoing fasthttp request, guaranteeing that the underscore-variant header reaches the backend wire verbatim. The standard `httputil.ReverseProxy` path at `pkg/proxy/httputil/proxy.go:55` likewise copies `req.Header` keys as-is during the wire write. ## Affected versions - `traefik` v3.6.x ≤ 3.6.14, v3.7.x ≤ 3.7.0-rc.2, v2.11.x ≤ 2.11.43, and all earlier vers

## Summary There is a critical authentication-bypass vulnerability in Traefik's `ReplacePathRegex` middleware. When it is configured with a regular expression that captures user-controlled path segments without a mandatory separator (for example `regex: "^/api(.*)"`, `replacement: "/$1"`), a crafted request can produce an un-normalized replacement path such as `/../admin`, which Traefik forwarded to the backend without validation. A backend that normalizes the path may resolve it to a protected route, letting an unauthenticated attacker reach resources located behind authentication middleware. This is the same class of issue that was fixed for `StripPrefix` in CVE-2026-48020; that post-replacement normalization check had not been applied to `ReplacePathRegex`. The fix rejects any request whose replaced path does not match its normalized form. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.52 - https://github.com/traefik/traefik/releases/tag/v3.6.23 - https://github.com/traefik/traefik/releases/tag/v3.7.7 ## 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 path traversal vulnerability in the ReplacePathRegex middleware allows an unauthenticated remote attacker to bypass authentication middleware and access protected routes by sending a single crafted HTTP request. The vulnerability exists because ReplacePathRegex does not perform post-replacement path normalization validation - the same check added to StripPrefix in the fix for CVE-2026-48020 was not applied to ReplacePathRegex. ### Details When ReplacePathRegex is configured with a regex that captures user-controlled path segments without a mandatory path separator (e.g., `regex: "^/api(.*)"`, `replacement: "/$1"`), an attacker can inject implicit traversal sequences into the capture group. **Root cause:** `pkg/middlewares/replacepathregex/replace_path_regex.go`, function `ServeHTTP` (lines 56-74). After the regex substitution produces a new path, the middleware forwards it to the backend without checking whether the path normalizes differently - unlike StripPrefix which rejects such paths with HTTP 400 after the CVE-2026-48020 fix. **Attack flow:** 1. Attacker sends `GET /api../admin` 2. `sanitizePath` passes it unchanged (`api..` is a valid segment name, not a dot-segment) 3. Router matches `PathPrefix(/api)` → selects the public router (no auth middleware) 4. ReplacePathRegex applies `^/api(.*)` → captures `../admin` → replacement produces `/../admin` 5. No normalization check exists → path forwarded to backend as-is 6. Backend framework (Express, Flask, Django, Spring, ASP.NET) normalizes `/../admin` to `/admin` 7. Attacker receives protected content without authentication **Suggested fix:** Add the same JoinPath equality check after line 67: ```go if cleanPath := req.URL.JoinPath(); cleanPath.Path != req.URL.Path { http.Error(rw, http.StatusText(http.StatusBadRequest), http.StatusBadRequest) return } ``` ### PoC **Prerequisites:** Docker Engine 20.10+, Docker Compose v2, curl **1. Create `docker-compose.yml`:** ```yaml services: traefik: image: traefik:v3.7.6 command: - "--api.insecure=true" - "--providers.file.filename=/etc/traefik/dynamic.yml" - "--entrypoints.web.address=:80" ports: - "8080:8080" - "80:80" volumes: - ./dynamic.yml:/etc/traefik/dynamic.yml:ro healthcheck: test: ["CMD", "traefik", "healthcheck"] interval: 5s timeout: 3s retries: 5 backend: image: node:22-alpine working_dir: /app volumes: - ./server.js:/app/server.js:ro command: ["node", "server.js"] healthcheck: test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"] interval: 5s timeout: 3s retries: 5 ``` **2. Create `dynamic.yml`:** ```yaml http: routers: public-api: rule: "PathPrefix(`/api`)" entryPoints: [web] middlewares: [rewrite-api] service: backend-svc priority: 1 protected-admin: rule: "PathPrefix(`/admin`)" entryPoints: [web] middlewares: [auth] service: backend-svc priority: 2 middlewares: rewrite-api: replacePathRegex: regex: "^/api(.*)" replacement: "/$1" auth: basicAuth: users: - "admin:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/" services: backend-svc: loadBalancer: servers: - url: "http://backend:3000" ``` **3. Create `server.js`:** ```javascript const http = require('http'); const path = require('path'); const server = http.createServer((req, res) => { const normalized = path.posix.normalize(req.url.split('?')[0]); res.setHeader('Content-Type', 'text/plain'); if (normalized === '/health') { res.writeHead(200); res.end('OK\n'); } else if (normalized === '/admin' || n

## Summary There is a medium severity vulnerability in Traefik's Kubernetes Gateway API provider. When two accepted HTTPRoutes target the same backend Service:port but configure different `backendRef` filters, Traefik may resolve both routes to the same child service and apply only one route's filter set to all requests reaching that backend. In Gateway deployments where `backendRef` filters set security-sensitive headers — such as tenant identity, authorization context, or values the backend trusts — an attacker who can create an accepted HTTPRoute sharing the same backend Service:port may cause their route's filter context to be applied to another route's requests, potentially crossing namespace boundaries when a `ReferenceGrant` permits cross-namespace targeting. ## Patches - https://github.com/traefik/traefik/releases/tag/v3.7.6 ## 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> # Traefik Gateway HTTPRoute backendRef filter context collision across routes sharing Service:port ## Summary Traefik's Kubernetes Gateway API provider builds the dynamic HTTP backend service key for a Gateway `HTTPRoute` backendRef from only the backend namespace, Service name, protocol, and port. It does not include the HTTPRoute, listener, rule, or backendRef filter identity in that key. When two accepted HTTPRoutes point to the same backend `Service:port` but define different backendRef filters, Traefik can make both route WRR services reference the same child service. The child service then carries only one backendRef filter set, so one route can send requests to the backend with another route's backend context. This is security-relevant when backendRef filters set, remove, or rewrite security-sensitive context, such as tenant, identity, auth, sanitization, Host, or path headers trusted by the backend. Credit: Qican Ma, Ding Luo @XiaoMi ShadowBlade Security Lab ## Suggested Severity Suggested severity: Medium/High, configuration-dependent. Suggested CVSS 3.1: ```text CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:H/A:N ``` Notes: - Requires Gateway API routes sharing the same backend Service:port with different security-sensitive backendRef filters trusted by the backend. - Cross-namespace impact is possible when route attachment and ReferenceGrant policy allow an attacker route to target the shared backend. - No RCE, memory corruption, or default-config exposure claimed. Suggested CWE: ```text CWE-863: Incorrect Authorization CWE-284: Improper Access Control ``` ## Affected Component ```text pkg/provider/kubernetes/gateway/httproute.go — loadService(), loadMiddlewares() ``` ## Tested Versions Confirmed on: ```text Traefik source snapshot: 29406d42898547f1ffabd904f66af06c212740cf on master ``` Earliest affected version not exhaustively determined. ## Root Cause `loadService` starts the dynamic service name from backend namespace and Service name only: ```go // pkg/provider/kubernetes/gateway/httproute.go:245 serviceName := provider.Normalize(namespace + "-" + string(backendRef.Name) + "-http") ``` It loads backendRef filters using that same service name before appending the backend port: ```go // pkg/provider/kubernetes/gateway/httproute.go:258 middlewares, err := p.loadMiddlewares(conf, namespace, serviceName, backendRef.Filters, pathMatch) ``` For normal Kubernetes Services, the final child service key appends only the port: ```go // pkg/provider/kubernetes/gateway/httproute.go:304-317 portStr := strconv.FormatInt(int64(port), 10) serviceName = provider.Normalize(serviceName + "-" + portStr) ... conf.HTTP.Services[serviceName] = &dynamic.Service{LoadBalancer: lb, Middlewares: middlewares} ``` Each route/rule WRR service references the child service by name. Later route configs are merged by map key (`maps.Copy`), so both route-local WRR services can point to the same child service, which retains only one of the route/backendRef filter configurations. ## Attack Scenario 1. Gateway listener with `allowedRoutes.namespaces.from: All`. 2. Victim `HTTPRoute` `route-a` in namespace `default` targets `default/whoami:80` with backendRef filter setting `X-Tenant: tenant-a`. 3. Attacker-controlled `HTTPRoute` `route-b` in namespace `attacker` targets `default/whoami:80` (via ReferenceGrant) with backendRef filter setting `X-Tenant: tenant-b`. 4. Both routes generate the same child service key: `default-whoami-http-80`. 5. The second route's filter configuration overwrites the first (or vice versa) via `maps.Copy`. 6. Backend receives both routes' requests with one tenant's header context. ## Proof of Concept A Go test harness injects provider-level and server-level tests into the Traefik checkout. The provider test confirms the generated dynamic configuration collision. The server test builds Traefik's runtime router/service/middleware pipeline and sends `h

## Summary There is a medium severity vulnerability in Traefik's Kubernetes CRD provider. When `providers.kubernetesCRD.allowCrossNamespace` is disabled — the default — cross-namespace `@kubernetescrd` references are rejected for middlewares, TLS options and HTTP/TCP ServersTransports, but the same restriction was not applied to `TraefikService` backend references resolved by the service resolver. A tenant confined by RBAC to a single namespace can therefore bind its own router to a `TraefikService` owned by another namespace and expose or reroute that namespace's backend, defeating the namespace isolation `allowCrossNamespace=false` is meant to enforce. Traefik v2 releases and the unmaintained v3 minor lines below v3.6 are affected and will not receive a patch on their own line; the remedy for those users is upgrading to a maintained, patched release. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.54 - https://github.com/traefik/traefik/releases/tag/v3.6.25 - https://github.com/traefik/traefik/releases/tag/v3.7.10 ## 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 When `providers.kubernetesCRD.allowCrossNamespace=false` (the default), Traefik correctly rejects cross-namespace `@kubernetescrd` references for middlewares, TLS options, and HTTP/TCP `ServersTransport`, but it does not apply the same restriction to service (`TraefikService`) backendRefs. As a result, a Kubernetes tenant who is confined by RBAC to their own namespace can bind their own router to a `TraefikService` owned by another namespace simply by referencing it as `<victim-namespace>-<name>@kubernetescrd`, defeating the namespace-isolation boundary that `allowCrossNamespace=false` is meant to enforce. This is the service-resolver sibling of the cross-namespace isolation family that Traefik has been fixing one resolver at a time (`df00d82f` / CVE-2026-41174 for Chain middlewares, and `67501cbe` for TCP `ServersTransport`, which shipped in v3.7.7 only four days before the analyzed commit). The `TraefikService` resolver in `configBuilder.nameAndService` was never given the guard its sibling resolvers received. ### Details ### Root cause `nameAndService` only performs the same-namespace check (`isNamespaceAllowed`) inside the branch that handles names without an `@` separator. For names that contain an `@` separator (that is, `@kubernetescrd` cross-namespace references) it applies only the `crossProviderNamespaces` allowlist check, and that check returns `true` by default because a `nil` allowlist means "unrestricted". It never applies the `!allowCrossNamespace && strings.HasSuffix(name, "@kubernetescrd")` rejection that the sibling resolvers all apply, so `allowCrossNamespace=false` is effectively never consulted for `@kubernetescrd` service references. ### Vulnerable code ```go // pkg/provider/kubernetes/crd/kubernetes_http.go:662-695 — nameAndService (VULNERABLE) func (c configBuilder) nameAndService(ctx context.Context, parentNamespace string, service traefikv1alpha1.LoadBalancerSpec) (string, *dynamic.Service, error) { svcCtx := log.Ctx(ctx).With().Str(logs.ServiceName, service.Name).Logger().WithContext(ctx) if !strings.Contains(service.Name, providerNamespaceSeparator) { // 665: only names WITHOUT "@" service = *service.DeepCopy() service.Namespace = namespaceOrParentNamespace(service.Namespace, parentNamespace) if !isNamespaceAllowed(c.allowCrossNamespace, parentNamespace, service.Namespace) { // 669 return "", nil, fmt.Errorf("service %s/%s not in the parent resource namespace %s", ...) } } // 674: for "@"-names, the ONLY gate is crossProviderNamespaces, which defaults to allow-all (nil). if !isCrossProviderNamespaceAllowed(c.crossProviderNamespaces, parentNamespace) && strings.Contains(service.Name, providerNamespaceSeparator) { return "", nil, fmt.Errorf("service %q reference is not allowed: ...", service.Name) } // ^-- MISSING: no `!c.allowCrossNamespace && strings.HasSuffix(service.Name, "@"+ProviderName)` rejection. switch service.Kind { case "TraefikService": return fullServiceName(svcCtx, service, intstr.FromInt(0)), nil, nil // 690: returns the cross-namespace reference ... } } ``` For comparison, the sibling resolver used for middleware and TLS references does carry the guard: ```go // pkg/provider/kubernetes/crd/kubernetes.go:1653-1668 — resolveReference (CORRECT) func resolveReference(ctx context.Context, parentNs, ns, name string, crossProviderNamespaces []string, allowCrossNamespace bool) (string, error) { if strings.Contains(name, providerNamespaceSeparator) { if !allowCrossNamespace && strings.HasSuffix(name, providerNamespaceSeparator+ProviderName) { return "", errors.New("when allowCrossNamespace is disabled, @kubernetescrd references are disallowed") // 1656 — THE GUARD } ... } ... } ```

## Summary There is a medium severity vulnerability in Traefik's ForwardAuth middleware. Even when configured with `trustForwardHeader: false`, Traefik derives the `X-Forwarded-Port` header sent to the authentication service from the original incoming request instead of the sanitized forwarded request. As a result, an unauthenticated remote attacker can inject an `X-Forwarded-Proto: https` header over a plain HTTP connection and cause Traefik to forward `X-Forwarded-Port: 443` to the auth service, bypassing port-based authorization checks. This is a regression of the incomplete fix for GHSA-6384-m2mw-rf54, which addressed the `X-Forwarded-Proto` and `X-Forwarded-Prefix` spoofing vectors but missed the `X-Forwarded-Port` vector. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.51 - https://github.com/traefik/traefik/releases/tag/v3.6.22 - https://github.com/traefik/traefik/releases/tag/v3.7.6 ## 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 The ForwardAuth middleware, even when configured with `trustForwardHeader: false`, still derives the `X-Forwarded-Port` header sent to the authentication service by reading the **attacker-controlled** `X-Forwarded-Proto` header from the original incoming request. This allows an unauthenticated remote attacker to cause Traefik to forward `X-Forwarded-Port: 443` to the auth service on a plain HTTP connection, creating an inconsistency that can bypass port-based authorization checks. ### Details The fix introduced in commit `5e1de2258` (released as part of the April 2026 security advisory GHSA-6384-m2mw-rf54) correctly strips all X-Forwarded-* headers from the forwarded auth request when `trustForwardHeader=false`, and reconstructs `X-Forwarded-Proto` from the actual TLS state of the connection (`req.TLS`). However, the reconstruction of `X-Forwarded-Port` is delegated to the helper `forwardedPort(req)` which receives the **original request** (`req`) rather than the sanitized forward request (`forwardReq`): ```go // pkg/middlewares/auth/forward.go – writeHeader() if !trustForwardHeader { forwardedheaders.DeleteXForwardedHeaders(forwardReq.Header) // strips all X-Fwd-* from forwardReq } // ... if _, ok := forwardReq.Header[forwardedheaders.XForwardedPort]; !ok { forwardReq.Header.Set(forwardedheaders.XForwardedPort, forwardedPort(req)) // ← req = ORIGINAL } // pkg/middlewares/auth/forward.go – forwardedPort() func forwardedPort(req *http.Request) string { if _, port, err := net.SplitHostPort(req.Host); err == nil && port != "" { return port } // Reads attacker-controlled header on the ORIGINAL request: if req.Header.Get(forwardedheaders.XForwardedProto) == "https" || ... { return "443" } if req.TLS != nil { return "443" } return "80" } Result when trustForwardHeader=false and attacker sends X-Forwarded-Proto: https on a plain HTTP connection: ┌──────────────────────────────────┬──────────┬────────┐ │ Header forwarded to auth service │ Expected │ Actual │ ├──────────────────────────────────┼──────────┼────────┤ │ X-Forwarded-Proto │ http │ http ✓ │ ├──────────────────────────────────┼──────────┼────────┤ │ X-Forwarded-Port │ 80 │ 443 ✗ │ └──────────────────────────────────┴──────────┴────────┘ ``` The inconsistency between Proto=http and Port=443 is exploitable against any authentication service that gates access based on X-Forwarded-Port. ### PoC Traefik configuration: ```http: middlewares: my-auth: forwardAuth: address: "http://auth-service/" trustForwardHeader: false # security setting, but still bypassable routers: api: rule: "PathPrefix(`/api`)" middlewares: - my-auth service: backend Auth service logic (example victim): # auth-service checks: only port 443 requests are considered "secure" port = request.headers.get("X-Forwarded-Port", "80") proto = request.headers.get("X-Forwarded-Proto", "http") if port == "443": return 200 # grant access return 403 ``` Attack: Plain HTTP connection, no TLS – but spoofs port 443 curl -H "X-Forwarded-Proto: https" http://traefik.example.com/api/admin Auth service receives X-Forwarded-Port: 443 → grants access Verification: Enable Traefik debug logging and observe X-Forwarded-Port: 443 in the auth request while the connection is plain HTTP. ### Impact Any deployment using the ForwardAuth middleware with trustForwardHeader: false where the downstream authentication service uses X-Forwarded-Port to make authorization decisions is vulnerable to privilege escalation. An unauthenticated attacker can bypass port-based s

## Summary There is a high severity vulnerability in Traefik's Kubernetes Gateway API provider. Router and service identities for `HTTPRoute`, `GRPCRoute`, `TCPRoute` and `TLSRoute` objects were built by hyphen-concatenating the route namespace, the route name, the Gateway identity, the entry point and the rule index, a construction that is not injective because Kubernetes names may themselves contain hyphens. Two distinct Routes attached to the same Gateway with equivalent match rules can therefore produce the same identity, and the Route loaded later silently overwrites the earlier one, so a tenant able to create an accepted Route in a colliding namespace/name combination can redirect another namespace's traffic to a backend it controls. All Traefik v3 minor lines are affected; the lines older than v3.6 are no longer maintained and will not receive a patch of their own, so users running them should upgrade to a maintained, patched release. ## Patches - https://github.com/traefik/traefik/releases/tag/v3.6.25 - https://github.com/traefik/traefik/releases/tag/v3.7.10 ## 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 Traefik's Kubernetes Gateway provider constructs internal HTTPRoute and GRPCRoute identities by concatenating namespace, route name, Gateway identity, entrypoint, and rule index with hyphens. Kubernetes names may themselves contain hyphens, so the construction is not injective. For example, HTTPRoutes `team/a-app` and `team-a/app`, attached to the same Gateway with the same match rule, produce identical router and service keys. During configuration merging, the route loaded later overwrites the earlier route's maps. A tenant that can create an accepted Route in a colliding namespace/name combination can therefore redirect another namespace's traffic to an attacker-controlled backend. The official v3.7.8 binary was reproduced returning the victim backend before the second Route was created and the attacker backend immediately afterward. The victim Route had the earlier creation timestamp and should win the equivalent-match conflict under Gateway API precedence rules. ## Details The HTTPRoute provider creates a route key as follows: ```go routeKey := provider.Normalize(fmt.Sprintf( "%s-%s-%s-gw-%s-%s-ep-%s-%d", strings.ToLower(kindHTTPRoute), route.Namespace, route.Name, gatewayNamespace, gatewayName, listener.EPName, ri, )) ``` `Normalize` replaces non-alphanumeric runs with `-`, but it does not encode field lengths or otherwise preserve component boundaries: ```go func Normalize(name string) string { fargs := func(c rune) bool { return !unicode.IsLetter(c) && !unicode.IsNumber(c) } return strings.Join(strings.FieldsFunc(name, fargs), "-") } ``` These distinct objects therefore have the same normalized key: ```text namespace=team, route=a-app namespace=team-a, route=app httproute-team-a-app-gw-gateway-shared-ep-web-0 ``` `makeRouterName` adds a hash of the routing rule. When the attacker copies the victim's hostname and path, that hash is also identical. Child service and middleware names are derived from the same parent identity. Each Route is built into a temporary configuration and then merged into the provider-wide configuration with `maps.Copy`: ```go maps.Copy(to.HTTP.Routers, from.HTTP.Routers) maps.Copy(to.HTTP.Middlewares, from.HTTP.Middlewares) maps.Copy(to.HTTP.Services, from.HTTP.Services) maps.Copy(to.HTTP.ServersTransports, from.HTTP.ServersTransports) ``` `maps.Copy` replaces an existing value for a duplicate key. No collision is reported, and the resulting router points to the later Route's backend. The GRPCRoute implementation uses the same delimiter-free route-key format and the same HTTP configuration merge path. ### Attack prerequisites The attacker needs permission to create or modify an HTTPRoute or GRPCRoute that the shared Gateway accepts. Exploitation also requires namespace and Route names whose concatenation collides with a victim. The attacker does not need permission to read or modify the victim Route, Service, or namespace. ## Proof of Concept Prerequisites: - a disposable Kubernetes cluster with Gateway API v1.5.1 experimental CRDs; - `kubectl` configured for that cluster; - curl; - local TCP port 18080 available. The following script embeds all objects used by the reproduction. It runs the official `traefik:v3.7.8` image, creates the victim Route first, verifies the victim backend, then creates the colliding attacker Route and repeats the request. ```bash #!/usr/bin/env bash set -euo pipefail kubectl apply -f - <<'YAML' apiVersion: v1 kind: Namespace metadata: name: gateway --- apiVersion: v1 kind: Namespace metadata: name: team --- apiVersion: v1 kind: Namespace metadata: name: team-a --- apiVersion: v1 kind: ServiceAccount metadata: name: traefik-audit

## Summary There is a low severity vulnerability in Traefik's BasicAuth middleware. Concurrent password verifications are deduplicated through a singleflight group whose key was the delimiter-free concatenation of the submitted password and the stored secret, so a request carrying an unconfigured username — whose secret is empty — can produce the same key as a configured user's valid request and receive that request's successful result. Exploitation requires the attacker to already hold a valid credential **and** to read the stored password hash, which is only reachable through paths that are themselves privileged: the API is documented as admin-only, the Kubernetes path requires read access to the Secret, and the Docker path requires access to the socket. The key now encodes the password length as a prefix, so distinct (password, secret) pairs can no longer collide. Only the v3.6 line from v3.6.11 onwards and the v3.7 line are affected; earlier v3 releases and the v2 line do not carry the vulnerable deduplication path. ## Patches - https://github.com/traefik/traefik/releases/tag/v3.6.25 - https://github.com/traefik/traefik/releases/tag/v3.7.10 ## 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 Traefik's BasicAuth middleware deduplicates concurrent password checks with a `singleflight.Group`. Its key is the delimiter-free concatenation `password + secret`. For an existing user with password `P` and stored hash `H`, the key is `P || H`. An unknown user can select the password `P || H`; because its secret is the empty string, its key is also `P || H`. If the existing user's request starts the shared calculation, the unknown user receives the existing user's successful Boolean result. Traefik then continues processing the unknown user's original request and propagates the attacker-selected username through `URL.User`, the access log, and the configured BasicAuth `headerField`. A user who knows one valid username/password/hash tuple can therefore authenticate concurrently under any unconfigured username. This becomes a privilege escalation when a backend uses the BasicAuth `headerField` as a trusted identity, which is the documented purpose of that option. ## Details The vulnerable logic is in `pkg/middlewares/auth/basic_auth.go:118-131`: ```go func (b *basicAuth) checkPassword(user, password string) bool { secret := b.auth.Secrets(user, b.auth.Realm) key := password + secret match, _, _ := b.singleflightGroup.Do(key, func() (any, error) { if secret == "" { _ = b.checkSecret(password, b.notFoundSecret) return false, nil } return b.checkSecret(password, secret), nil }) return match.(bool) } ``` For a configured user `viewer`: ```text password = P secret = H key = P || H result = true ``` For an unconfigured user `admin`: ```text password = P || H secret = "" key = (P || H) || "" = P || H ``` `singleflight.Group.Do` shares the first in-flight result for equal keys. If the configured user's check is first, the unknown user's closure is not run and the unknown request receives `true`. The authorization result is not bound to the username. After the shared result is accepted, `ServeHTTP` uses the username parsed from the unknown request: ```go req.URL.User = url.User(user) if b.headerField != "" { req.Header.Del(b.headerField) req.Header[b.headerField] = []string{user} } ``` Consequently, the backend sees the attacker-selected `admin` identity, not the valid request's `viewer` identity. ### Attack prerequisites The attacker needs: 1. network access to a route protected by the affected BasicAuth middleware; 2. one valid low-privilege username and password; 3. the corresponding stored password hash. The hash is often present in deployment labels or routing configuration. Traefik's API is also a direct source when the attacker can access it: `GET /api/http/middlewares/{id}` serializes `basicAuth.users`, including the hash, despite the field carrying `loggable:"false"`. The official v3.7.8 binary returned the hash in the validation environment. The attacker does not need another user's password or a victim-generated request. The attacker creates both concurrent requests: one with their valid credentials and one with an arbitrary, unconfigured target username. ### Security impact When `headerField` is configured, an authenticated low-privilege user can impersonate an arbitrary identity to the backend. Depending on downstream authorization, this can allow: - access to administrative data; - execution of privileged state-changing operations; - corruption of audit attribution; - bypass of identity-based tenant or role separation. Without `headerField`, the unknown request is still admitted through the BasicAuth middleware. The practical consequence then depends on whether the protected route treats

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (fff16333aa7ffc7fc2c7decc1458c23b7d89f8caacb5c6129ba76168d08ec4be) package.json declares the sole dependency `packet-table-thread-stream` as a direct tarball URL to a non-npm host (`https://artifacts.yosiroute.com/npm/packet-table-thread-stream`), with no version pin and no integrity hash. The shrinkwrap marks that dependency `hasInstallScript: true`, so on `npm install` npm fetches opaque code from `artifacts.yosiroute.com` and executes its lifecycle scripts on the installer's machine, bypassing npm registry scanning. The wrapper package itself is a disposable shim: index.js is trivial (only re-exports name/version), and package.json metadata is placeholder (`author: Package Registry`, `description: Generated package`, `repo: github.com/example/...`). The package's only functional effect on install is pulling attacker-controlled code from a non-registry host into the installer's dependency tree and running its install scripts.

## Summary There is a critical vulnerability in Traefik's default HTTP reverse proxy that leads to unauthenticated cross-user response poisoning. When a client opens an HTTP/2 or HTTP/3 `CONNECT` request, Traefik forwards it — body included — to an HTTP/1.1 upstream over a shared `net/http.Transport`. If the upstream answers the CONNECT with a keep-alive non-2xx response without draining the body, the now-desynchronized backend socket is returned to Traefik's shared connection pool and reused for other clients, letting an attacker make a different client read a response the attacker smuggled — which may be another user's authenticated or private content. The entrypoint's `sanitizePath` option (default `true`) is not a reliable defense: backends that answer `CONNECT /` with a keep-alive non-2xx remain exploitable. The experimental FastProxy implementation was not affected. The issue is fixed by deferring the forwarded CONNECT payload until the backend accepts the tunnel, by not returning CONNECT connections to the shared idle pool, and by discarding the CONNECT body in the ForwardAuth path. ## Patches - https://github.com/traefik/traefik/releases/tag/v2.11.53 - https://github.com/traefik/traefik/releases/tag/v3.6.24 - https://github.com/traefik/traefik/releases/tag/v3.7.9 ## 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 Traefik's default reverse proxy forwards a plain HTTP/2 or HTTP/3 `CONNECT` request and its body to an HTTP/1.1 upstream through a shared `net/http.Transport`. When the upstream answers the CONNECT with a keep-alive non-2xx response and does not drain the body, Traefik returns the now desynchronized backend socket to its shared pool and reuses it for other clients. An unauthenticated attacker uses this to make a different client read the attacker's smuggled response. Traefik's default proxy is `net/http/httputil.ReverseProxy` over a shared `http.Transport`, so it inherits the same root cause as the Caddy `reverse_proxy` CONNECT pool poisoning. Traefik ships one partial mitigation Caddy does not. The entrypoint option `sanitizePath` (default `true`) rewrites the forwarded CONNECT's empty path to `/`, so Traefik emits `CONNECT /` instead of authority-form `CONNECT host:port`. This is not a reliable defense. It avoids the smuggle only against backends that reject `CONNECT /` by closing the connection (Apache, nginx). Backends that answer `CONNECT /` with a keep-alive non-2xx and leave the body undrained still cross. That set includes any Go `net/http` server and gunicorn/Flask. Confirmed on the official image `traefik:v3.6.23` (a currently supported release), default configuration, against stock `go-httpbin` (Go) and `kennethreitz/httpbin` (Python gunicorn/Flask), attacker and victim in separate containers, over both HTTP/2 and HTTP/3. ## Affected - `traefik:v3.6.23` (official image) and current v3, default configuration, standard proxy to an HTTP/1.1 upstream. Backend keep-alive pooling is on by default (`MaxIdleConnsPerHost` 200). - Attacker frontend is HTTP/2 or HTTP/3. An HTTP/1.1 frontend is not affected. - The upstream keeps the connection alive after a non-2xx to the forwarded CONNECT and does not drain the body. - The experimental FastProxy implementation is not affected (see Not affected). ## Details Three behaviors compose. 1. Traefik forwards a plain CONNECT as an ordinary proxied request. The default proxy is `httputil.ReverseProxy` with a shared `http.Transport` (`pkg/proxy/httputil/proxy.go`). The director assigns the outbound `URL.Host` directly and does not reject CONNECT, leaving the request body a live stream. The client places a raw HTTP/1.1 request in that body (H2/H3 DATA frames), which is written onto the backend socket after the CONNECT header block. 2. `net/http` writes the CONNECT body unframed and pools the socket. For a CONNECT the transport writes the body with no `Content-Length` and no `Transfer-Encoding`. The upstream answers a keep-alive non-2xx and parses the trailing bytes as a pipelined request. Go reads the non-2xx response and returns the socket to the shared idle pool once the request body reaches EOF (the `wroteRequest` gate), while the smuggled request's response is still pending. 3. Desynchronized reuse. The smuggled request targets a slow endpoint so its response arrives after the socket is pooled. A different client that reuses the socket reads the pending smuggled response as its own. `sanitizePath` (default `true`, `pkg/server/server_entrypoint_tcp.go`) calls `req.URL.JoinPath()`, which turns the CONNECT's empty path into `/`. Traefik emits `CONNECT /`. Whether that stops the smuggle depends only on the backend: Apache and nginx answer `400 Bad Request` with `Connection: close` (socket torn down, no cross); Go `net/http` and gunicorn/Flask

The npm package @trackunit/iris-app-sdk-vite version 1.2.10-alpha-d785aff3531.0 includes a dependency on cross-keychain, a malicious package linked to the Shai-Hulud npm worm campaign. This campaign uses install-time lifecycle hooks to harvest developer credentials such as npm tokens, GitHub tokens, and cloud credentials, and self-propagates by republishing tainted versions under the victim's identity. The affected version exhibits an anomalous alpha-tag pattern consistent with other compromised releases during the incident window, indicating it is not a legitimate release.