Common Weakness Enumeration

CWE-324

Allowed

Use of a Key Past its Expiration Date

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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.

45 vulnerabilities reference this CWE, most recent first.

GHSA-WQPG-FCG8-GQ9P

Vulnerability from github – Published: 2022-04-03 00:01 – Updated: 2022-04-10 00:01
VLAI
Details

Philips Vue PACS versions 12.2.x.x and prior 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.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-33020"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-311",
      "CWE-324",
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-01T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "Philips Vue PACS versions 12.2.x.x and prior 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.",
  "id": "GHSA-wqpg-fcg8-gq9p",
  "modified": "2022-04-10T00:01:05Z",
  "published": "2022-04-03T00:01:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33020"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsma-21-187-01"
    },
    {
      "type": "WEB",
      "url": "http://www.philips.com/productsecurity"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-WQQC-JJCQ-VFXM

Vulnerability from github – Published: 2026-07-31 21:58 – Updated: 2026-07-31 21:58
VLAI
Summary
sigstore-go fails to check signature timestamps against a signing key's validity period
Details

sigstore-go fails to check signature timestamps against a signing key's validity period for self-managed long-lived keys without certificates.

Impact

To verify a bundle with a self-managed long-lived key, the key needs to be wrapped in an ExpiringKey type that implies expiration semantics:

signatureVerifier, _ := signature.LoadDefaultVerifier(publicKey)
expiredKey := root.NewExpiringKey(signatureVerifier, time.Unix(0, 0), time.Unix(1, 0))

Despite the API contract, the validator does not check the bundle signing time against the validity window. Attackers that obtain expired key materials may be able to sign bundles with those materials that are accepted despite a configured expiry date. This issue only impacts the long-lived signing key workflow, and not standard deployments involving a certificate authority.

Reproduction steps

Start from a sigstore-go checkout:

git clone https://github.com/sigstore/sigstore-go.git
cd sigstore-go
git checkout 8ca80c47ef03d26ebf174db7c296700b075b2c16

Apply the patch containing the test case and associated materials:

git apply sigstore-go-public-key-validity-test.patch

Run the test:

go test ./pkg/verify -run TestPublicKeyValidityCheckedAgainstSignedTimestamp

On vulnerable code, the test fails because verification succeeds even though the trusted ExpiringKey is not valid at the signed timestamp:

--- FAIL: TestPublicKeyValidityCheckedAgainstSignedTimestamp
    signed_entity_test.go:602:
            Error:          An error is expected but got nil.
Severity
3.1 (Low)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.2.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/sigstore-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54787"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-31T21:58:39Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "sigstore-go fails to check signature timestamps against a signing key\u0027s validity period for self-managed long-lived keys without certificates.\n\n## Impact\n\nTo verify a bundle with a self-managed long-lived key, the key needs to be wrapped in an `ExpiringKey` type that implies expiration semantics:\n\n```go\nsignatureVerifier, _ := signature.LoadDefaultVerifier(publicKey)\nexpiredKey := root.NewExpiringKey(signatureVerifier, time.Unix(0, 0), time.Unix(1, 0))\n```\n\nDespite the API contract, the validator does not check the bundle signing time against the validity window. Attackers that obtain expired key materials may be able to sign bundles with those materials that are accepted despite a configured expiry date. This issue only impacts the long-lived signing key workflow, and not standard deployments involving a certificate authority.\n\n## Reproduction steps\n\nStart from a sigstore-go checkout:\n\n```bash\ngit clone https://github.com/sigstore/sigstore-go.git\ncd sigstore-go\ngit checkout 8ca80c47ef03d26ebf174db7c296700b075b2c16\n```\n\nApply the [patch] containing the test case and associated materials:\n\n```bash\ngit apply sigstore-go-public-key-validity-test.patch\n```\n\nRun the test:\n\n```bash\ngo test ./pkg/verify -run TestPublicKeyValidityCheckedAgainstSignedTimestamp\n```\n\nOn vulnerable code, the test fails because verification succeeds even though the trusted `ExpiringKey` is not valid at the signed timestamp:\n\n```text\n--- FAIL: TestPublicKeyValidityCheckedAgainstSignedTimestamp\n    signed_entity_test.go:602:\n        \tError:      \tAn error is expected but got nil.\n```\n\n[patch]: https://github.com/user-attachments/files/28614520/sigstore-go-public-key-validity-test.patch",
  "id": "GHSA-wqqc-jjcq-vfxm",
  "modified": "2026-07-31T21:58:39Z",
  "published": "2026-07-31T21:58:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/security/advisories/GHSA-wqqc-jjcq-vfxm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/pull/642"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/commit/4594ab4c779d08be1f4419803a8249188f35ed5f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/sigstore-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-go/releases/tag/v1.2.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "sigstore-go fails to check signature timestamps against a signing key\u0027s validity period"
}

GHSA-WWW9-GRM3-8MC4

Vulnerability from github – Published: 2024-05-22 21:30 – Updated: 2024-05-22 21:30
VLAI
Details

IBM App Connect Enterprise 12.0.1.0 through 12.0.12.1 could allow an authenticated user to obtain sensitive user information using an expired access token. IBM X-Force ID: 288176.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-31895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324",
      "CWE-672"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-22T20:15:09Z",
    "severity": "MODERATE"
  },
  "details": "IBM App Connect Enterprise 12.0.1.0 through 12.0.12.1 could allow an authenticated user to obtain sensitive user information using an expired access token.  IBM X-Force ID:  288176.",
  "id": "GHSA-www9-grm3-8mc4",
  "modified": "2024-05-22T21:30:35Z",
  "published": "2024-05-22T21:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31895"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/288176"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7154606"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XMMM-JW76-Q7VG

Vulnerability from github – Published: 2024-10-14 20:56 – Updated: 2024-12-20 17:49
VLAI
Summary
Keycloaks's One Time Passcode (OTP) is valid longer than expiration timeSeverity
Details

A vulnerability was found in Keycloak. Expired OTP codes are still usable when using FreeOTP when the OTP token period is set to 30 seconds (default). Instead of expiring and deemed unusable around 30 seconds in, the tokens are valid for an additional 30 seconds totaling 1 minute. A one time passcode that is valid longer than its expiration time increases the attack window for malicious actors to abuse the system and compromise accounts. Additionally, it increases the attack surface because at any given time, two OTPs are valid.

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "24.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "25.0.0"
            },
            {
              "fixed": "25.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-7318"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-14T20:56:43Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Keycloak. Expired OTP codes are still usable when using FreeOTP when the OTP token period is set to 30 seconds (default). Instead of expiring and deemed unusable around 30 seconds in, the tokens are valid for an additional 30 seconds totaling 1 minute. A one time passcode that is valid longer than its expiration time increases the attack window for malicious actors to abuse the system and compromise accounts. Additionally, it increases the attack surface because at any given time, two OTPs are valid.",
  "id": "GHSA-xmmm-jw76-q7vg",
  "modified": "2024-12-20T17:49:56Z",
  "published": "2024-10-14T20:56:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-xmmm-jw76-q7vg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7318"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6502"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6503"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-7318"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2301876"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Keycloaks\u0027s One Time Passcode (OTP) is valid longer than expiration timeSeverity"
}

GHSA-XMXX-7P24-H892

Vulnerability from github – Published: 2026-04-17 22:32 – Updated: 2026-05-12 13:35
VLAI
Summary
OpenClaw: Gateway HTTP endpoints re-resolve bearer auth after SecretRef rotation
Details

Summary

Gateway HTTP and WebSocket handlers captured the resolved bearer-auth configuration when the server started. After a SecretRef rotation, the already-running gateway could continue accepting the old bearer token until restart.

Impact

A bearer token that should have been revoked by SecretRef rotation could remain valid on the gateway HTTP and upgrade surfaces for the lifetime of the process. Severity remains high because the old token could continue to authorize gateway requests after operators believed it was rotated out.

Affected versions

  • Affected: < 2026.4.15
  • Patched: 2026.4.15

Fix

OpenClaw 2026.4.15 resolves active gateway auth from the runtime secret snapshot per request and per upgrade instead of using a stale startup-time value.

Verified in v2026.4.15:

  • src/gateway/server.impl.ts exposes getResolvedAuth() backed by the current runtime secret snapshot.
  • src/gateway/server-http.ts calls getResolvedAuth() for each HTTP request and WebSocket upgrade before running auth checks.
  • src/gateway/server-http.probe.test.ts verifies /ready re-resolves bearer auth after rotation and rejects the old token.

Fix commit included in v2026.4.15 and absent from v2026.4.14:

  • acd4e0a32f12e1ad85f3130f63b42443ce90f094 via PR #66651

Thanks to @zsxsoft, Keen Security Lab, and @qclawer for reporting this issue.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
9.2 (Critical)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43585"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324",
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T22:32:02Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nGateway HTTP and WebSocket handlers captured the resolved bearer-auth configuration when the server started. After a SecretRef rotation, the already-running gateway could continue accepting the old bearer token until restart.\n\n## Impact\n\nA bearer token that should have been revoked by SecretRef rotation could remain valid on the gateway HTTP and upgrade surfaces for the lifetime of the process. Severity remains high because the old token could continue to authorize gateway requests after operators believed it was rotated out.\n\n## Affected versions\n\n- Affected: `\u003c 2026.4.15`\n- Patched: `2026.4.15`\n\n## Fix\n\nOpenClaw `2026.4.15` resolves active gateway auth from the runtime secret snapshot per request and per upgrade instead of using a stale startup-time value.\n\nVerified in `v2026.4.15`:\n\n- `src/gateway/server.impl.ts` exposes `getResolvedAuth()` backed by the current runtime secret snapshot.\n- `src/gateway/server-http.ts` calls `getResolvedAuth()` for each HTTP request and WebSocket upgrade before running auth checks.\n- `src/gateway/server-http.probe.test.ts` verifies `/ready` re-resolves bearer auth after rotation and rejects the old token.\n\nFix commit included in `v2026.4.15` and absent from `v2026.4.14`:\n\n- `acd4e0a32f12e1ad85f3130f63b42443ce90f094` via PR #66651\n\nThanks to @zsxsoft, Keen Security Lab, and @qclawer for reporting this issue.",
  "id": "GHSA-xmxx-7p24-h892",
  "modified": "2026-05-12T13:35:23Z",
  "published": "2026-04-17T22:32:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xmxx-7p24-h892"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43585"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/66651"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/acd4e0a32f12e1ad85f3130f63b42443ce90f094"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-bearer-token-validation-bypass-via-stale-secretref-resolution"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Gateway HTTP endpoints re-resolve bearer auth after SecretRef rotation"
}
Mitigation
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.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list