EUVD-2026-36243Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:N for on-path interception; AC:H because attacker needs network position and an HTTP request to the origin; UI:R since the victim must trigger an HTTP request; C:H from full session takeover, I:L from acting as user, A:N.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
3DescriptionCVE.org
Boruta is a standalone authorization server that aims to implement OAuth 2.0 and Openid Connect up to decentralized identity specifications. Prior to version 0.9.1, boruta session cookies and the identity “remember me” cookie were set without the Secure attribute. In deployments where users could reach the same Boruta origin over plaintext HTTP, browsers could send these cookies over an unencrypted connection. An attacker able to observe or intercept that network traffic could recover a valid session or remember-me cookie and reuse it to impersonate the affected user. Affected components include boruta_web, boruta_identity, and boruta_admin. The affected cookies include the shared session cookie, defaulting to _boruta_web_key, and the identity remember-me cookie, defaulting to _boruta_identity_web_user_remember_me. The issue is fixed in commit 18691c655164635066aa113003a3cd87f6ed11cd, released as part of version 0.9.1. The patch sets secure: true and same_site: "Lax" on configured session cookies for boruta_web, boruta_identity, and boruta_admin, and sets secure: true on the identity remember-me cookie. Until upgrading to a release containing the fix: terminate or reject plaintext HTTP before requests reach Boruta; enforce HTTPS-only access at the reverse proxy or load balancer; enable HSTS for Boruta domains; if cookie exposure is suspected, rotate SECRET_KEY_BASE and BORUTA_SESSION_COOKIE_SIGNING_SALT, then require users to authenticate again. Upgrade to a version containing commit 18691c655164635066aa113003a3cd87f6ed11cd, or apply the patch manually. After deploying the fix, verify that Boruta session and remember-me cookies include the Secure attribute in browser developer tools or with an HTTP response inspection tool.
AnalysisAI
Session cookie hijacking in Boruta authorization server prior to 0.9.1 allows network-positioned attackers to capture authentication and remember-me cookies because they lack the Secure attribute and may be transmitted over plaintext HTTP. The flaw affects boruta_web, boruta_identity, and boruta_admin components and enables full user impersonation, including potentially administrative sessions on an OAuth 2.0/OpenID Connect identity provider. No public exploit identified at time of analysis and the issue is not in CISA KEV.
Technical ContextAI
Boruta is an Elixir/Phoenix-based standalone authorization server implementing OAuth 2.0, OpenID Connect, and decentralized identity specifications. The root cause is CWE-614 (Sensitive Cookie in HTTPS Session Without Secure Attribute): the Plug.Session configuration in each endpoint module (BorutaWeb.Endpoint, BorutaIdentityWeb.Endpoint, BorutaAdminWeb.Endpoint) and the remember-me cookie options in BorutaIdentityWeb.Authenticable omitted the secure: true flag. Without this flag the browser will attach the signed session cookie (default name _boruta_web_key) and the identity remember-me cookie (default _boruta_identity_web_user_remember_me) to any request to the same origin, including ones initiated over http://, exposing the cookie value to anyone with a passive or active position on the wire.
RemediationAI
Upgrade to Boruta 0.9.1 or later, which includes commit 18691c655164635066aa113003a3cd87f6ed11cd setting secure: true and same_site: "Lax" on the session cookies for all three endpoints and secure: true on the identity remember-me cookie. If immediate upgrade is not possible, apply the same patch manually to the four files (boruta_web/endpoint.ex, boruta_identity/endpoint.ex, boruta_admin/endpoint.ex, boruta_identity_web/concerns/authenticable.ex), and in parallel enforce HTTPS upstream of Boruta by terminating or rejecting plaintext HTTP at the reverse proxy or load balancer and enabling HSTS for the Boruta domains - note that strict HSTS will break any internal tooling that still relies on HTTP. If cookie exposure is suspected, rotate SECRET_KEY_BASE and BORUTA_SESSION_COOKIE_SIGNING_SALT and force re-authentication, which will invalidate every active session and remember-me token. After deploying, verify the Set-Cookie response headers carry the Secure attribute using browser devtools or curl. Advisory URLs: https://github.com/malach-it/boruta-server/security/advisories/GHSA-jqgm-pfg6-cr8r and https://github.com/malach-it/boruta_auth/security/advisories/GHSA-7355-8c95-25pv.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today