CVE-2026-53871
Hermes WebUI before 0.51.368 contains an authorization bypass vulnerability in the get_profile_cookie() function that accepts unauthenticate
CVSS
8.1
Alto
EPSS
0.4%
p30
KEV
—
Exploit Today
9
0-100
Publicado: 17 jun 2026 · Última mod.: 17 sept 2026 · CWE-565
0.4%EPSS · 30 días0.4%
2026-08-202026-09-17
Hermes WebUI before 0.51.368 contains an authorization bypass vulnerability in the get_profile_cookie() function that accepts unauthenticated profile names from the hermes_profile cookie. An authenticated attacker can forge the hermes_profile cookie value to bypass profile-scoped authorization checks and access sessions, files, and resources across different profiles.
- github.comhttps://github.com/nesquena/hermes-webui/commit/9e96f5f6adf93b6d1e27ebddfb4d2833ca06ff3b
- github.comhttps://github.com/nesquena/hermes-webui/pull/4023
- github.comhttps://github.com/nesquena/hermes-webui/pull/4036
- github.comhttps://github.com/nesquena/hermes-webui/releases/tag/v0.51.368
- www.vulncheck.comhttps://www.vulncheck.com/advisories/hermes-webui-profile-scoped-authorization-bypass-via-forged-hermes-profile-cookie
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-76186—11.2%
——3Apache Airflow Keycloak provider: from Airflow 3.3 the Keycloak auth manager takes a user's identity from the signed Airflow session token but takes the Keycloak access and refresh tokens used for every authorization decision from separate, unauthenticated cookies, and never checks that the two describe the same subject. A user who holds any valid Airflow login of their own, together with another subject's Keycloak access or refresh token obtained out of band, can pair the two: Airflow then authorizes requests with the foreign token's privileges while the session identity, audit log and cache keys continue to name the attacker's own account. The refresh path re-issues an Airflow session token for the original identity carrying the foreign tokens, so the mismatched pairing survives across sessions.
Affects deployments running Airflow 3.3 or later with the Keycloak auth manager. Earlier versions carried the Keycloak tokens inside the signed session token, so the binding existed and was lost when they moved into separate cookies.
Users of apache-airflow-providers-keycloak are recommended to upgrade to version 0.10.0 or later, which binds the cookie-supplied tokens to the session identity.2dCVE-2026-692156.8 MED36.3%
——11Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, The CookieJar client middleware uses unanchored substring checks instead of RFC 6265 domain and path matching when deciding whether to attach a stored cookie. A cookie for example.com can consequently be sent to an attacker-controlled hostname such as evilexample.com when an application using the same jar makes an attacker-influenced outbound request. This exposes session or authentication cookies and can enable hijacking of the application’s outbound sessions. This issue is fixed in versions 0.23.35 and 1.0.0-M47.2dCVE-2026-692146.8 MED17.8%
——5Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, The CookieJar client middleware stores a response cookie’s Domain attribute without checking that it domain-matches the host that supplied the cookie or rejecting public suffixes. A malicious or compromised server contacted through the same CookieJar can plant a cookie for another domain, and the jar later sends that cookie to the victim domain, enabling session fixation or overwriting security-sensitive cookies. The patch validates the Set-Cookie domain against the response origin, although public-suffix rejection remains unimplemented. This issue is fixed in versions 0.23.35 and 1.0.0-M47.2dCVE-2026-851819.8 CRÍ31.9%
——10CAT uses Java String.hashCode as the sole integrity check for session cookies without server-side keying, allowing attackers to forge valid checksums offline. Attackers can set the x-forwarded-for header to bypass IP binding validation and create admin sessions with full configuration access.15dCVE-2026-75757—22.9%
——7Reliance on Cookies without Validation and Integrity Checking vulnerability in ash-project ash_admin lets an attacker who controls a sibling subdomain rebind an admin's session to a different actor, tenant, or authorization mode.
AshAdmin's client JavaScript read its state cookies (tenant, actor_resource, actor_primary_key, actor_action, actor_domain, actor_authorizing, actor_paused) by matching the cookie name with an unanchored regular expression (new RegExp(name + "=([^;]+)")) against the whole document.cookie. Any cookie whose name merely ends with the requested name therefore matches, and whichever is serialized first wins. Because cookies are shared across a registrable domain, a compromised sibling subdomain can set a shadowing cookie (for example xactor_authorizing) with Domain=.example.com that flows unvalidated into the admin's LiveSocket connect params. The fix matches cookie names by exact equality.
This issue affects ash_admin: from 0.9.1 before 1.3.1.17dCVE-2026-83375.3 MED9.4%
——3Concrete CMS 9.5.0 and below is vulnerable to IDOR in surveys. To be vulnerable, a site would have to be configured in such a way that both public and private surveys are present on the site. An unauthenticated attacker can vote in the restricted survey by submitting the restricted optionID through the public survey’s endpoint. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 6.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Zer0daySec https://github.com/Zee99y for reporting57d