Weakness (CWE)
CWE-613: DEPRECATED: Insufficient Session Expiration
This entry has been deprecated because it was insufficiently clear. Consider CWE-1462 and its descendants.
Source: MITRE CWE-613
49 results · Clear filters · Feed
-
Critical 9.1
In affected versions of Octopus Server it is possible for a session token to be valid indefinitely due to improper vali…
-
Critical 9.1
Insufficient Session Expiration in nocodb/nocodb
Insufficient Session Expiration in GitHub repository nocodb/nocodb prior to 0.91.7+.
-
Critical 9.8
ifme - Insufficient Session Expiration
In Ifme, versions 1.0.0 to v.7.33.2 don’t properly invalidate a user’s session even after the user initiated logout. It makes it possible for an attacker to reuse the admin cookies either via local/network access or by other hypothetical attacks.
-
Critical 9.8
Talkyard - Insufficient Session Expiration
In Talkyard, regular versions v0.2021.20 through v0.2021.33 and dev versions v0.2021.20 through v0.2021.34, are vulnerable to Insufficient Session Expiration. This may allow an attacker to reuse the admin’s still-valid session token even when logged-out, to g…
-
Critical 9.8
Apostrophe - Insufficient Session Expiration
Apostrophe CMS versions prior to 3.3.1 did not invalidate existing login sessions when disabling a user account or changing the password, creating a situation in which a device compromised by a third party could not be locked out by those means. As a mitigati…
-
Critical 9.1
SaltStack Salt eauth tokens can be used once after expiration
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
-
Critical 9.8
October CMS Session ID not invalidated after logout
An issue was discovered in October through build 471. It reactivates an old session ID (which had been invalid after a logout) once a new login occurs. NOTE: this violates the intended Auth/Manager.php authentication behavior but, admittedly, is only relevant…
-
Critical 9.8
Token leases could outlive their TTL in HashiCorp Vault
HashiCorp Vault and Vault Enterprise versions 1.0 and newer allowed leases created with a batch token to outlive their TTL because expiration time was not scheduled correctly. Fixed in 1.4.7 and 1.5.4.
-
Critical 9.8
Cloud Foundry Runtime Insufficient Session Expiration vulnerability
The password change functionality in Cloud Foundry Runtime cf-release before 216, UAA before 2.5.2, and Pivotal Cloud Foundry (PCF) Elastic Runtime before 1.7.0 allow attackers to have unspecified impact by leveraging failure to expire existing sessions.