Boruta EUVD-2026-36243

Exploitation requires three concrete conditions: (1) the Boruta origin must be reachable over plaintext HTTP - i.e., the operator has not forced HTTPS-only at the reverse proxy/load balancer and has not configured HSTS; (2) the attacker must hold a network position capable of observing traffic between victim and server (same LAN, compromised hop, rogue Wi-Fi, on-path ISP, etc.); and (3) the victim's browser must issue at least one request to the Boruta origin over HTTP while holding a valid session or remember-me cookie, which can be induced by a typed hostname, bookmark, HTTP link, or downgrade. Limiting factors: a deployment that already enforces HTTPS-only at the proxy is effectively not exploitable, and same_site: "Lax" (also added by the patch) further constrains cross-site triggering once fixed. The vendor CVSS marks PR:N/UI:N, but in practice the user must actively navigate to the HTTP variant of the origin for the cookie to leak.

The vendor-supplied CVSS 4.0 base score of 8.8 (AV:N/AC:L/PR:N/UI:N/VC:H) treats this as critical, but that rating assumes a deployment that actually serves Boruta over plaintext HTTP at the same origin - a precondition the description explicitly calls out. Real-world risk is therefore highly deployment-dependent: a Boruta instance behind a TLS-terminating reverse proxy that already redirects or refuses HTTP is largely unaffected, while a development or misconfigured production deployment reachable on port 80 is genuinely exposed to passive sniffing on the LAN/WAN path. There is no EPSS score, no KEV entry, and no public POC referenced, so this should be triaged as a configuration-hygiene fix that becomes urgent only where HTTP exposure is plausible. Confidentiality impact is high (full session token disclosure leading to account/admin takeover on an identity provider), integrity is low (limited to actions as the victim), availability is unaffected.

An attacker on the same coffee-shop Wi-Fi as a Boruta administrator waits for the admin's browser to issue any request to the Boruta origin over plaintext HTTP - for example a bookmark, a typed hostname without scheme, or an HTTP redirect - and passively captures the _boruta_web_key and _boruta_identity_web_user_remember_me cookies from the wire. The attacker then replays those cookies against the HTTPS endpoint to impersonate the administrator and issue OAuth tokens or modify identity records. No public POC is referenced, but the attack is standard cookie-sidejacking and trivially reproducible with Wireshark plus a browser.