Vulnerabilities (CVE)

Filtered by CWE-613
Total 614 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2026-82310 2026-09-16 N/A N/A
Apache Airflow FAB provider: deactivating a user account does not stop tokens issued to that account before deactivation. Password authentication correctly rejects the disabled account, but the Core API continues to accept an existing, unexpired token naming it, and lets that token mint a replacement — so the account keeps its role-scoped access indefinitely after an administrator has disabled it. The user replays their own legitimate credential; no signature forgery or privilege escalation is involved, and the access stays within the roles the account already held. Affects deployments using Airflow 3 with the FAB auth manager and Core API token authentication, where an administrator deactivates an account whose row remains in the database and whose previously issued token has not expired. The trigger is administrative deactivation as a containment action, which silently fails to contain. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account.
CVE-2026-86462 2026-09-16 N/A N/A
Apache Airflow FAB provider: changing a user's password through the Admin user-edit PATCH endpoint does not invalidate that user's existing database-backed sessions. An attacker who already holds a copy of the victim's session cookie keeps full access as that user after the password change, so the password reset does not evict them. Affects deployments using the FAB auth manager with database-backed sessions; an administrator (or the user themselves) performing a routine password change is the trigger, and no attacker interaction with the endpoint is needed. This is a second, independent route to the outcome addressed by CVE-2026-82311, which corrected an identifier comparison in the session-invalidation helper. That fix does not repair this endpoint, because the PATCH path never calls the helper at all. Deployments that applied the CVE-2026-82311 fix must also upgrade for this one. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which fixes the issue.
CVE-2026-82311 2026-09-16 N/A N/A
Apache Airflow FAB provider: resetting a user's password does not delete that user's existing database-backed sessions, despite documented behaviour that it does. The cleanup compares the string identifier Flask-Login stores in the session against the user's integer database identifier, so the comparison never matches and no session is removed. An attacker who already holds a copy of the victim's session cookie keeps access as that user after the password change, so the reset does not evict them. Affects deployments using the FAB auth manager with `[fab] session_backend=database`. The trigger is an administrator (or the user) running the supported password-reset command as a containment action after a session cookie has been compromised; the secure-cookie backend is out of scope, as it documents that it cannot centrally delete sessions. apache-airflow-providers-fab 3.9.0 also fixes CVE-2026-86462, a second, independent route to the same outcome via the Admin user-edit endpoint; a single upgrade closes both. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which compares the identifiers consistently.
CVE-2026-92358 2026-09-16 N/A 6.4 MEDIUM
A flaw was found in the first broker login flow of Keycloak. When a user confirms an account-linking request from a different browser, a temporary proof is created to validate the link. However, this proof is not properly cleared after the link is established or when the user later manually removes the link. An attacker who controls the external identity can exploit this leftover proof to silently re-establish the link and gain unauthorized access to the victims account without any further confirmation.
CVE-2026-81268 1 Langflow 1 Langflow 2026-09-16 N/A 8.1 HIGH
IBM Langflow OSS 1.0.0 through 1.11.5 could allow a remote authenticated attacker to execute flows and obtain sensitive information due to insufficient session expiration of API keys after user deactivation.
CVE-2026-88262 2026-09-15 N/A N/A
Insufficient session expiration vulnerability in bizwell xClick allows Authentication Bypass. This issue affects xClick: R2, R3, and R3.1.
CVE-2026-55617 2026-09-15 N/A N/A
Hydro is a next-generation high-performance online judge platform. From 4.10.4 until 5.0.2, the session recreation logic in packages/hydrooj/src/service/layers/base.ts creates a replacement session token without deleting the previous token from the server-side session token store, so an old sid cookie can remain valid after logout or another renewal flow. An attacker who possesses a victim's previously valid stale cookie can replay it over HTTP or HTTPS without knowing the victim's username or password and without victim interaction at exploitation time. Successful replay can take over the victim's account, disclose private data, and permit unauthorized modification or deletion of data available to that account. This issue is fixed in version 5.0.2.
CVE-2026-87014 1 Openwebui 1 Open Webui 2026-09-15 N/A 6.5 MEDIUM
Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 until 0.11.1, role synchronization in backend/open_webui/routers/auths.py and backend/open_webui/utils/oauth.py updated an administrator's database role without invalidating the user record cached by backend/open_webui/socket/main.py. An administrator demoted through a trusted role header or OAuth role mapping could keep an already-open Socket.IO connection and continue reading or editing every user's collaborative notes until that connection closed. This issue is fixed in version 0.11.1.
CVE-2026-5545 1 Haxx 1 Curl 2026-09-15 N/A 6.5 MEDIUM
libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...
CVE-2026-80174 1 Dell 1 Secure Connect Gateway 2026-09-14 N/A 5.3 MEDIUM
Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Insufficient Session Expiration vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to session theft.
CVE-2025-25252 1 Fortinet 1 Fortios 2026-09-13 N/A 4.8 MEDIUM
An Insufficient Session Expiration vulnerability [CWE-613] in FortiOS SSL VPN 7.6.0 through 7.6.2, 7.4.0 through 7.4.6, 7.2.0 through 7.2.10, 7.0.0 through 7.0.16, 6.4 all versions may allow a remote attacker (e.g. a former admin whose account was removed and whose session was terminated) in possession of the SAML record of a user session to access or re-open that session via re-use of SAML record.
CVE-2026-82469 2026-09-11 N/A 5.4 MEDIUM
Rodauth before 2.47.0 contains an authentication bypass vulnerability in the jwt_refresh route that issues new JWT access tokens without requiring a refresh token. Attackers can present an access token to the refresh route via non-POST methods to obtain a new valid access token, enabling indefinite account access with temporary token possession.
CVE-2026-55250 2026-09-10 N/A N/A
Maravel, a PHP framework oriented towards dependency injection, prior to version 10.74.0 has a high-severity Token Replay Vulnerability arising from a structural lifecycle mismatch between stateless token validation engines and high-performance relational caching layers. Any application with low cache memory that causes premature eviction to free up memory and applications running macropay-solutions/maravel-framework that utilize tymon/jwt-auth for API token authentication and blacklist management or any other package that does the same may be affected. This architectural risk might also impact native Laravel applications utilizing cache tags under specific volatile or eviction-capped environments. tymon/jwt-auth automatically probes for cache tag support. If found, it forcefully wraps 14-day token blacklist entries (jti) inside a relational tymon.jwt tag. In environments where the O(1) Atomic Lazy Eviction model is active — either natively inside Maravel-Framework v20.x or manually backported into v10.x via the explicit DI container singletons provided in PR #104 (App\Cache\TaggedCache and App\Cache\TagSet) — a strict global tracking ceiling (Container::TAGGED_CACHE_TTL_CAP_SECONDS) of 7,200 seconds (2 hours) is enforced to secure the system against memory index bloat. This ceiling forcefully truncates the 14-day blacklist lifespan down to a maximum of 2 hours, after which individual tracking keys naturally expire and disappear from the active cache window. Furthermore, because the optimized engine implements a generational version matrix to achieve O(1) flush speeds, any programmatic or manual invocation of a tag flush or reset (e.g., Cache::tags([...])->flush()) instantly bumps the internal atomic master version pointer. This shifts the computed cryptographic composite hash (sha1($this->tags->getNamespace())) for all overlapping components, rendering the entire existing index immediately unreachable. Consequently, through either natural 2-hour expiration or an intervening tag flush execution (like the cache naturally cleaning old values to free up memory), the invalidation state records are entirely wiped out. Because the tokens' physical cryptographic signatures remain structurally valid for up to 14 days, stolen, hijacked, or legitimately logged-out tokens are instantly and silently resurrected across the entire API gateway, leaving the application critically vulnerable to widespread Token Replay Attacks. Because this issue is caused by an upstream architectural assumption within the tymon/jwt-auth package rather than a core defect inside the framework, there is no direct framework version upgrade that can safely bypass this lifecycle collision without breaking business cache recycling bounds. Maravel version 10.74.0 introduced a way to backport the new fixed tagged cache from 20.x into 10.x by resolving TagSet and TaggedCache from DI, which is how this latent architectural lifecycle vulnerability was discovered. Users must apply the decoupled configuration workaround outlined below. As a workaround, make sure that cache memory size does not generate early natural evictions from cache to free up space, deleting blacklisted jwt ids before they expire. Applications must decouple flat authentication vectors from the relational tagging subsystem. This forces token identifiers to write directly to the primary cache keyspace as flat, un-tagged key-value pairs where they securely retain their unclipped 14-day lifecycle.
CVE-2026-61608 2026-09-10 N/A 6.8 MEDIUM
SolidInvoice is an open-source invoicing platform. Prior to version 3.0.1, `UserInvitation` entities have no expiry timestamp. Invitation links mailed to users remain valid indefinitely, meaning a leaked, forwarded, or archived invitation email can be used at any time in the future to join a company or silently add a compromised email account to a company. Version 3.0.1 fixes the issue.
CVE-2026-65984 2026-09-09 N/A N/A
FUXA is a web-based Process Visualization (SCADA/HMI/Dashboard) software. In 1.3.2 and earlier, POST /api/refresh in server/api/auth/index.js falls back from current user data to decoded.groups, including when the user is deleted or groups is zero, and POST /api/heartbeat in server/api/index.js re-signs inbound JWT claims without validating the current database record. An attacker who possesses a previously issued privileged refresh cookie or access token can continue minting privileged JWTs after account deletion, disablement, role removal, or demotion. Continued refresh-cookie rotation can extend the stale session and preserve unauthorized access to user management, project manipulation, runtime configuration, scripts, and backdoor-account creation. This issue is fixed in version 1.3.3.
CVE-2026-39924 2026-09-09 N/A 6.8 MEDIUM
Flarum before 1.8.16 contains an improper session invalidation vulnerability that allows attackers who hold a valid session token to retain full account access after a victim changes their password, because the access_tokens table is never cleared on password change events. The TokensClearer::clearPasswordTokens() function only removes rows from the password_tokens table while leaving all active session cookies and API bearer tokens intact, including long-lived RememberAccessToken entries, and administrator-forced password resets via the user update endpoint are equally ineffective at revoking attacker-held sessions.
CVE-2026-86215 2026-09-09 4.0 MEDIUM 4.3 MEDIUM
A vulnerability was identified in Mstfakts College-Management-System. The affected element is an unknown function of the file Front-end/server.php of the component Logout Handler. Such manipulation of the argument log_out leads to session expiration. It is possible to launch the attack remotely. The exploit is publicly available and might be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. The project was informed of the problem early through an issue report but has not responded yet.
CVE-2026-55513 2026-09-08 N/A 5.4 MEDIUM
nebula-mesh is a self-hosted control plane for Slack Nebula mesh VPN. From version 0.3.0 to before version 0.5.0, the nebula-mgmt Web UI host-creation path ignores both the server-wide enrollment_token_ttl security setting and per-network network_config.enrollment_token_ttl overrides. API host creation and token-regeneration paths use the configured TTL resolver, but POST /ui/hosts hardcodes now.Add(24 * time.Hour) for newly minted agent enrollment tokens. In deployments that intentionally reduce enrollment-token lifetime, any authenticated operator who can create a host through the Web UI can still mint a bearer enrollment token valid for about 24 hours. This issue has been patched in version 0.5.0.
CVE-2026-45791 2026-09-08 N/A 5.9 MEDIUM
Dokploy is a free, self-hostable Platform as a Service (PaaS). Prior to 0.29.6, Dokploy's user.update procedure in apps/dokploy/server/api/routers/user.ts updates account.password without deleting other rows from session, allowing a compromised better-auth.session_token session to remain valid for up to three days after a password change. This issue is fixed in version 0.29.6.
CVE-2026-48079 2026-09-08 N/A 7.4 HIGH
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, when a user navigates to the `/logout` page, the page's server-side load handler deletes the `access_token` cookie before calling `/api/auth/logout` via an internal `event.fetch()`. The internal fetch consequently runs without the auth cookie, so `apiAuthHandle` rejects it, the logout handler never executes, and `SessionService.revokeSession()` is never called for the current session. The DB session row remains valid until its natural expiry (one week by default). The user sees a successful logout (cookie gone, UI returns to login), but any party still holding a copy of the now-deleted access token can continue making authenticated API calls until the session naturally expires. The root cause is a simple ordering mistake. The same auth subsystem implements the correct order in `/api/auth/logout`: revoke the current DB session first, then delete the cookie. The page-level wrapper does the opposite. Version 1.0.2 initiates server-side logout before removing authentication cookies and first appears in version 1.0.2. Version 2.0.0 later replaces this with a race-free client-side logout flow.