CWE-324: Use of a Key Past its Expiration Date
BaseLikelihood of exploit: Low
The product uses a cryptographic key or password past its expiration date, which diminishes its safety significantly by increasing the timing window for cracking attacks against that key.
While the expiration of keys does not necessarily ensure that they are compromised, it is a significant concern that keys which remain in use for prolonged periods of time have a decreasing probability of integrity. For this reason, it is important to replace keys within a period of time proportional to their strength.
Consequences
- Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity
How to prevent it
- Architecture and Design: Adequate consideration should be put in to the user interface in order to notify users previous to the key's expiration, to explain the importance of new key generation and to walk users through the process as painlessly as possible.
Recent advisories
- GHSA-5c3f-6486-3g7g — Gogs's password-reset tokens use account-activation lifetime, ignoring RESET_PASSWORD_CODE_LIVES
- GHSA-xmxx-7p24-h892 — OpenClaw: Gateway HTTP endpoints re-resolve bearer auth after SecretRef rotation
- GHSA-3rw9-wmc8-8948 — Coder accepts an APIKey beyond the linked OIDC expiry if there is no refresh token
- GHSA-xmmm-jw76-q7vg — Keycloaks's One Time Passcode (OTP) is valid longer than expiration timeSeverity
- GHSA-r82w-3phg-qvr4 — Moodle uses the same key for QR login and auto-login
- GHSA-j99g-qjvx-995g — Contao Does Not Expire Tokens Correctly
- GHSA-w66p-78g4-mr7g — OpenStack Keystone Insufficient token expiration
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor