CVE-2025-64447
A reliance on cookies without validation and integrity checking vulnerability in Fortinet FortiWeb 8.0.0 through 8.0.1, FortiWeb 7.6.0 throu
CVSS
8.1
Alto
EPSS
8.4%
p95
KEV
—
Exploit Today
28
0-100
Publicado: 9 dic 2025 · Última mod.: 25 sept 2026 · CWE-565
8.4%EPSS · 30 días8.4%
2026-10-012026-10-29
A reliance on cookies without validation and integrity checking vulnerability in Fortinet FortiWeb 8.0.0 through 8.0.1, FortiWeb 7.6.0 through 7.6.5, FortiWeb 7.4.0 through 7.4.10, FortiWeb 7.2.0 through 7.2.11, FortiWeb 7.0.0 through 7.0.11 may allow an unauthenticated attacker to execute arbitrary operations on the system via crafted HTTP or HTTPS request via forged cookies, requiring prior knowledge of the FortiWeb serial number.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-1191287.4 ALT—
——0ZITADEL 4.0.0 before 4.19.5 contains an authentication bypass vulnerability in the Login V2 UI that allows unauthenticated attackers to set the first credential of users lacking any authentication method. Attackers can compute a valid verificationCheck cookie from the user ID and browser fingerprint to set a password, register a passkey, or link an identity provider, taking over the account.1dCVE-2026-1186616.5 MED19.6%
——6Happy DOM is a JavaScript implementation of a web browser without its graphical user interface. Prior to 20.14.6, Happy DOM's CookieContainer in src/cookie/CookieContainer.ts does not correctly validate or match Domain cookie attributes. It can accept a Domain unrelated to the origin setting the cookie, including a public suffix, and separately treats an unrelated suffix-sharing hostname as a match because cookieMatchesURL does not enforce a DNS-label boundary. In server-side rendering and prerendering applications that contact attacker-controlled origins and then make requests to a victim origin, these behaviors can plant and deliver a forged cookie, enabling cookie injection or session fixation. This issue is fixed in version 20.14.6.1dCVE-2026-1123529.1 CRÍ70.8%
——21Sunhillo SureLine before 9.1.5 contains an authentication bypass vulnerability that allows an unauthenticated remote attacker to impersonate any user with an active web session by forging a session cookie containing only a cleartext username with no random identifier or integrity protection. Attackers can guess default account names such as Admin or sftp_user and submit a forged username cookie to satisfy the login check in checkLogin (libwebcmn.so) and networkDiag.cgi, chaining into root command execution.2dCVE-2026-111749—32.4%
——10AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.4, Host-Only scope on an existing parent-domain cookie can be removed by a subdomain. A user who accesses an untrusted subdomain can consequently have host-only protections stripped from cookies, although impact is limited when applications do not reflect those cookies to a browser. This issue is fixed in version 3.14.4.8dCVE-2026-101287—33.9%
——10Authentication bypass vulnerability in Stela, versions prior to 1.60.1, due to the use of a cookie named “authProcess” without validating its integrity. The application stores the user identifier (userId) and the status of the authentication process (validSteps) in this cookie and relies on these values—which can be modified by the client—to complete the login process.
A remote attacker, without valid credentials or interaction from other users, could manipulate the cookie to bypass authentication checks and impersonate any account, including one with SUPER_ADMIN privileges. This would allow the attacker to obtain a valid JWT token with administrative privileges and compromise the confidentiality and integrity of the application.15dCVE-2026-761869.1 CRÍ56.8%
——17Apache 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.42d