GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
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."

970 vulnerabilities reference this CWE, most recent first.

GHSA-G39J-8M48-QWGJ

Vulnerability from github – Published: 2022-05-24 17:49 – Updated: 2022-10-22 12:00
VLAI
Details

A vulnerability in the SIP inspection engine of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause a crash and reload of an affected device, resulting in a denial of service (DoS) condition.The vulnerability is due to a crash that occurs during a hash lookup for a SIP pinhole connection. An attacker could exploit this vulnerability by sending crafted SIP traffic through an affected device. A successful exploit could allow the attacker to cause a crash and reload of the affected device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-1501"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-29T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the SIP inspection engine of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause a crash and reload of an affected device, resulting in a denial of service (DoS) condition.The vulnerability is due to a crash that occurs during a hash lookup for a SIP pinhole connection. An attacker could exploit this vulnerability by sending crafted SIP traffic through an affected device. A successful exploit could allow the attacker to cause a crash and reload of the affected device.",
  "id": "GHSA-g39j-8m48-qwgj",
  "modified": "2022-10-22T12:00:30Z",
  "published": "2022-05-24T17:49:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1501"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asa-ftd-sipdos-GGwmMerC"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G4R8-MP7G-85FQ

Vulnerability from github – Published: 2025-05-06 16:51 – Updated: 2025-05-06 19:57
VLAI
Summary
ZITADEL Allows IdP Intent Token Reuse
Details

Impact

ZITADEL offers developers the ability to manage user sessions using the Session API. This API enables the use of IdPs for authentication, known as idp intents.

Following a successful idp intent, the client receives an id and token on a predefined URI. These id and token can then be used to authenticate the user or their session.

However, it was possible to exploit this feature by repeatedly using intents. This allowed an attacker with access to the application’s URI to retrieve the id and token, enabling them to authenticate on behalf of the user.

It’s important to note that the use of additional factors (MFA) prevents a complete authentication process and, consequently, access to the ZITADEL API.

Patches

3.x versions are fixed on >=3.0.0 2.71.x versions are fixed on >=2.71.9 2.x versions are fixed on >=2.70.10

Workarounds

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

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Józef Chraplewski from Nedap for reporting this vulnerability.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.0-rc.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-rc.1"
            },
            {
              "fixed": "3.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.70.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.71.8"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.71.0"
            },
            {
              "fixed": "2.71.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-46815"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-294",
      "CWE-384",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-06T16:51:16Z",
    "nvd_published_at": "2025-05-06T18:15:38Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nZITADEL offers developers the ability to manage user sessions using the [Session API](https://zitadel.com/docs/category/apis/resources/session_service_v2/session-service). This API enables the use of IdPs for authentication, known as idp intents.\n\nFollowing a successful idp intent, the client receives an id and token on a predefined URI. These id and token can then be used to authenticate the user or their session.\n\nHowever, it was possible to exploit this feature by repeatedly using intents. This allowed an attacker with access to the application\u2019s URI to retrieve the id and token, enabling them to authenticate on behalf of the user.\n\nIt\u2019s important to note that the use of additional factors (MFA) prevents a complete authentication process and, consequently, access to the ZITADEL API.\n\n### Patches\n\n3.x versions are fixed on \u003e=[3.0.0](https://github.com/zitadel/zitadel/releases/tag/v3.0.0)\n2.71.x versions are fixed on \u003e=[2.71.9](https://github.com/zitadel/zitadel/releases/tag/v2.71.9)\n2.x versions are fixed on \u003e=[2.70.10](https://github.com/zitadel/zitadel/releases/tag/v2.70.10)\n\n### Workarounds\n\nThe recommended solution is to update ZITADEL to a patched version.\n\n### Questions\n\nIf you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)\n\n### Credits\n\nThanks to J\u00f3zef Chraplewski from Nedap for reporting this vulnerability.",
  "id": "GHSA-g4r8-mp7g-85fq",
  "modified": "2025-05-06T19:57:17Z",
  "published": "2025-05-06T16:51:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/security/advisories/GHSA-g4r8-mp7g-85fq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46815"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/commit/b1e60e7398d677f08b06fd7715227f70b7ca1162"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zitadel/zitadel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.70.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v2.71.9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v3.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ZITADEL Allows IdP Intent Token Reuse"
}

GHSA-G4X6-JCVR-9M3G

Vulnerability from github – Published: 2026-07-14 20:26 – Updated: 2026-07-14 20:26
VLAI
Summary
nebula-mesh: Web UI host creation ignores configured enrollment token TTL and mints 24-hour bearer enrollment tokens
Details

Summary

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.

Details

Enrollment tokens are bearer credentials for the public POST /api/v1/enroll endpoint: possession of a valid token allows enrolling the pending host and receiving a signed Nebula certificate/config for that host. The server configuration documents a security knob for their default lifetime and per-network overrides:

  • internal/config/server.go:82 defines EnrollmentTokenTTL as the default lifetime for freshly minted enrollment tokens.
  • internal/config/server.go:83 documents per-network overrides in network_config under enrollment_token_ttl.

The API server implements and consistently uses this resolver:

  • internal/api/server.go:77 defines tokenTTLFor, with precedence of per-network enrollment_token_ttl, then server default, then 24h fallback.
  • internal/api/server.go:82 reads network_config.enrollment_token_ttl.
  • internal/api/server.go:89 falls back to the configured server default.
  • internal/api/hosts.go:190 through internal/api/hosts.go:196 use now.Add(s.tokenTTLFor(r.Context(), host.NetworkID)) for API host creation.

The Web UI sibling path does not call the resolver and instead always sets a 24-hour expiry:

  • internal/web/handlers.go:874 mints the raw token for POST /ui/hosts.
  • internal/web/handlers.go:879 sets ExpiresAt: now.Add(24 * time.Hour).

This creates inconsistent behavior between API and Web UI host creation and bypasses an operator-configured token lifetime policy. The issue is reachable by an authenticated Web UI operator who can create hosts. Admins can create hosts in any network; non-admin operators can create hosts in networks whose CA they own.

Affected version evidence: the configurable enrollment-token TTL feature was introduced by commit 6c344a6 (feat(api): configurable enrollment-token TTL + regenerate endpoint (#75) (#79)), and git tag --contains 6c344a6 --sort=version:refname returns v0.3.0 through v0.3.8. Pattern checks across all release tags showed the TTL config/API resolver and the Web UI 24-hour hardcode are present in every v0.3.x release from v0.3.0 to v0.3.8, and are not meaningfully applicable to v0.1.x/v0.2.0 because the TTL policy knob was not present there. The current checkout at commit d92dd9a60de291e2bc1caf73b4e9a99567b31ec0 (git describe: v0.3.8-1-gd92dd9a) remains affected.

PoC

Safe local PoC run from a clean checkout at commit d92dd9a60de291e2bc1caf73b4e9a99567b31ec0 on 2026-06-12. The PoC is a temporary Go test that uses only in-memory SQLite and httptest; it does not start a real server and does not contact external services.

  1. Create a temporary test file internal/web/security_audit_poc_test.go in package web.
  2. In the test, create an in-memory Web UI with newTestWeb(t), create a network audit-poc-net with CIDR 10.77.0.0/24, and set network_config.enrollment_token_ttl to 30m.
  3. Log in as the seeded test admin through the normal Web UI helper and obtain a CSRF token from GET /ui/hosts/new.
  4. Submit POST /ui/hosts with network_id=audit-poc-net, name=audit-poc-host, nebula_ips=10.77.0.10, role=host, and kind=agent.
  5. Parse the one-shot enrollment token from the returned host-detail page and read the token row with GetEnrollmentToken.
  6. Compare the observed expiry to the configured 30-minute network override.

Command run:

go test ./internal/web -run 'TestSecurityAuditPOC' -count=1 -v

Observed vulnerable output from this environment:

=== RUN   TestSecurityAuditPOC_UIHostCreateIgnoresNetworkEnrollmentTokenTTL
POC_UI_TTL_BYPASS observed_token_ttl=24h0m0s configured_network_ttl=30m expires_at=2026-06-13T14:51:45Z
--- PASS: TestSecurityAuditPOC_UIHostCreateIgnoresNetworkEnrollmentTokenTTL (0.05s)

The meaningful control is the API sibling: internal/api/hosts.go:190 through internal/api/hosts.go:196 uses s.tokenTTLFor(...), and existing tests in internal/api/hosts_token_ttl_test.go verify API-created/regenerated enrollment tokens honor server-default and per-network TTLs. Variant review also found API regenerate-token, API re-enroll, and signed-poll rekey token minting use the resolver rather than a hardcoded 24h value. After recording the output, the temporary test file was removed and git status --short returned clean. The PoC was re-run after drafting this report and produced the output shown above.

Impact

An authenticated Web UI operator can bypass a configured enrollment-token lifetime policy and obtain a token valid for approximately 24 hours even when the deployment or network is configured for a much shorter lifetime such as 30 minutes. Because enrollment tokens are bearer credentials for the public enrollment endpoint, longer-than-intended validity increases the window in which a copied, logged, shared, or otherwise exposed token can be used to enroll the pending host and obtain its Nebula certificate/config. This weakens confidentiality and integrity for deployments relying on short token lifetimes to reduce enrollment-token exposure.

Suggested remediation: refactor the Web UI host-creation path to use the same TTL resolution as the API path, or move the resolver into a shared package/service used by both API and Web UI. Add a regression test under internal/web that sets network_config.enrollment_token_ttl = "30m", creates an agent host through POST /ui/hosts, and asserts the persisted enrollment token expires within the configured 30-minute window rather than 24 hours.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/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/forgekeep/nebula-mesh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0"
            },
            {
              "fixed": "0.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55513"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T20:26:21Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe `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.\n\n### Details\nEnrollment tokens are bearer credentials for the public `POST /api/v1/enroll` endpoint: possession of a valid token allows enrolling the pending host and receiving a signed Nebula certificate/config for that host. The server configuration documents a security knob for their default lifetime and per-network overrides:\n\n- `internal/config/server.go:82` defines `EnrollmentTokenTTL` as the default lifetime for freshly minted enrollment tokens.\n- `internal/config/server.go:83` documents per-network overrides in `network_config` under `enrollment_token_ttl`.\n\nThe API server implements and consistently uses this resolver:\n\n- `internal/api/server.go:77` defines `tokenTTLFor`, with precedence of per-network `enrollment_token_ttl`, then server default, then 24h fallback.\n- `internal/api/server.go:82` reads `network_config.enrollment_token_ttl`.\n- `internal/api/server.go:89` falls back to the configured server default.\n- `internal/api/hosts.go:190` through `internal/api/hosts.go:196` use `now.Add(s.tokenTTLFor(r.Context(), host.NetworkID))` for API host creation.\n\nThe Web UI sibling path does not call the resolver and instead always sets a 24-hour expiry:\n\n- `internal/web/handlers.go:874` mints the raw token for `POST /ui/hosts`.\n- `internal/web/handlers.go:879` sets `ExpiresAt: now.Add(24 * time.Hour)`.\n\nThis creates inconsistent behavior between API and Web UI host creation and bypasses an operator-configured token lifetime policy. The issue is reachable by an authenticated Web UI operator who can create hosts. Admins can create hosts in any network; non-admin operators can create hosts in networks whose CA they own.\n\nAffected version evidence: the configurable enrollment-token TTL feature was introduced by commit `6c344a6` (`feat(api): configurable enrollment-token TTL + regenerate endpoint (#75) (#79)`), and `git tag --contains 6c344a6 --sort=version:refname` returns `v0.3.0` through `v0.3.8`. Pattern checks across all release tags showed the TTL config/API resolver and the Web UI 24-hour hardcode are present in every `v0.3.x` release from `v0.3.0` to `v0.3.8`, and are not meaningfully applicable to `v0.1.x`/`v0.2.0` because the TTL policy knob was not present there. The current checkout at commit `d92dd9a60de291e2bc1caf73b4e9a99567b31ec0` (`git describe`: `v0.3.8-1-gd92dd9a`) remains affected.\n\n### PoC\nSafe local PoC run from a clean checkout at commit `d92dd9a60de291e2bc1caf73b4e9a99567b31ec0` on 2026-06-12. The PoC is a temporary Go test that uses only in-memory SQLite and `httptest`; it does not start a real server and does not contact external services.\n\n1. Create a temporary test file `internal/web/security_audit_poc_test.go` in package `web`.\n2. In the test, create an in-memory Web UI with `newTestWeb(t)`, create a network `audit-poc-net` with CIDR `10.77.0.0/24`, and set `network_config.enrollment_token_ttl` to `30m`.\n3. Log in as the seeded test admin through the normal Web UI helper and obtain a CSRF token from `GET /ui/hosts/new`.\n4. Submit `POST /ui/hosts` with `network_id=audit-poc-net`, `name=audit-poc-host`, `nebula_ips=10.77.0.10`, `role=host`, and `kind=agent`.\n5. Parse the one-shot enrollment token from the returned host-detail page and read the token row with `GetEnrollmentToken`.\n6. Compare the observed expiry to the configured 30-minute network override.\n\nCommand run:\n\n```bash\ngo test ./internal/web -run \u0027TestSecurityAuditPOC\u0027 -count=1 -v\n```\n\nObserved vulnerable output from this environment:\n\n```text\n=== RUN   TestSecurityAuditPOC_UIHostCreateIgnoresNetworkEnrollmentTokenTTL\nPOC_UI_TTL_BYPASS observed_token_ttl=24h0m0s configured_network_ttl=30m expires_at=2026-06-13T14:51:45Z\n--- PASS: TestSecurityAuditPOC_UIHostCreateIgnoresNetworkEnrollmentTokenTTL (0.05s)\n```\n\nThe meaningful control is the API sibling: `internal/api/hosts.go:190` through `internal/api/hosts.go:196` uses `s.tokenTTLFor(...)`, and existing tests in `internal/api/hosts_token_ttl_test.go` verify API-created/regenerated enrollment tokens honor server-default and per-network TTLs. Variant review also found API regenerate-token, API re-enroll, and signed-poll rekey token minting use the resolver rather than a hardcoded 24h value. After recording the output, the temporary test file was removed and `git status --short` returned clean. The PoC was re-run after drafting this report and produced the output shown above.\n\n### Impact\nAn authenticated Web UI operator can bypass a configured enrollment-token lifetime policy and obtain a token valid for approximately 24 hours even when the deployment or network is configured for a much shorter lifetime such as 30 minutes. Because enrollment tokens are bearer credentials for the public enrollment endpoint, longer-than-intended validity increases the window in which a copied, logged, shared, or otherwise exposed token can be used to enroll the pending host and obtain its Nebula certificate/config. This weakens confidentiality and integrity for deployments relying on short token lifetimes to reduce enrollment-token exposure.\n\nSuggested remediation: refactor the Web UI host-creation path to use the same TTL resolution as the API path, or move the resolver into a shared package/service used by both API and Web UI. Add a regression test under `internal/web` that sets `network_config.enrollment_token_ttl = \"30m\"`, creates an agent host through `POST /ui/hosts`, and asserts the persisted enrollment token expires within the configured 30-minute window rather than 24 hours.",
  "id": "GHSA-g4x6-jcvr-9m3g",
  "modified": "2026-07-14T20:26:21Z",
  "published": "2026-07-14T20:26:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/forgekeep/nebula-mesh/security/advisories/GHSA-g4x6-jcvr-9m3g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/forgekeep/nebula-mesh/commit/514006029e09f1991122b86a80e7b25970bcfa98"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/forgekeep/nebula-mesh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/forgekeep/nebula-mesh/releases/tag/v0.5.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "nebula-mesh: Web UI host creation ignores configured enrollment token TTL and mints 24-hour bearer enrollment tokens"
}

GHSA-G5RH-53CQ-PX9W

Vulnerability from github – Published: 2026-05-21 15:34 – Updated: 2026-05-21 15:34
VLAI
Details

Insufficient session expiration vulnerability in Turkiye Electricity Transmission Corporation (TEİAŞ) Mobile Application allows Session Hijacking.

This issue affects Mobile Application: from 1.6.2 before 1.13.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-1815"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-21T15:16:22Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient session expiration vulnerability in Turkiye Electricity Transmission Corporation (TE\u0130A\u015e) Mobile Application allows Session Hijacking.\n\nThis issue affects Mobile Application: from 1.6.2 before 1.13.",
  "id": "GHSA-g5rh-53cq-px9w",
  "modified": "2026-05-21T15:34:09Z",
  "published": "2026-05-21T15:34:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1815"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0286"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G65H-35F3-X2W3

Vulnerability from github – Published: 2024-05-13 19:59 – Updated: 2024-05-14 20:04
VLAI
Summary
Directus Lacks Session Tokens Invalidation
Details

Summary

Currently session tokens function like the other JWT tokens where they are not actually invalidated when logging out. The directus_session gets destroyed and the cookie gets deleted but if you captured the cookie value it will still work for the entire expiry time which is set to 1 day by default. Making it effectively a long lived unrevokable stateless token instead of the stateful session token it was meant to be. When authenticating a session token JWT, Directus should also check whether the associated directus_session both still exists and has not expired (although the token should expire at the same time or before the session) to ensure leaked tokens are not valid indefinitely.

Steps to reproduce

  • Copy the current session token from the cookie
  • Refresh and or log out
  • Use the saved session token to check if it is still valid

Impact

The lack of proper session expiration may improve the likely success of certain attacks. For example, a user might access a web site from a shared computer (such as at a library, Internet cafe, or open work environment). Incorrect token invalidation could allow an attacker to use the browser's history to access a Directus instance session previously accessed by the victim.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.10.0"
            },
            {
              "fixed": "10.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-34709"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-13T19:59:39Z",
    "nvd_published_at": "2024-05-14T15:39:31Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nCurrently session tokens function like the other JWT tokens where they are not actually invalidated when logging out. The `directus_session` gets destroyed and the cookie gets deleted but if you captured the cookie value it will still work for the entire expiry time which is set to 1 day by default. Making it effectively a long lived unrevokable stateless token instead of the stateful session token it was meant to be.\nWhen authenticating a session token JWT, Directus should also check whether the associated `directus_session` both still exists and has not expired (although the token should expire at the same time or before the session) to ensure leaked tokens are not valid indefinitely.\n\n## Steps to reproduce\n- Copy the current session token from the cookie\n- Refresh and or log out\n- Use the saved session token to check if it is still valid\n\n### Impact\nThe lack of proper session expiration may improve the likely success of certain attacks. For example, a user might access a web site from a shared computer (such as at a library, Internet cafe, or open work environment). Incorrect token invalidation could allow an attacker to use the browser\u0027s history to access a Directus instance session previously accessed by the victim.",
  "id": "GHSA-g65h-35f3-x2w3",
  "modified": "2024-05-14T20:04:30Z",
  "published": "2024-05-13T19:59:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-g65h-35f3-x2w3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34709"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/commit/a6172f8a6a0f31a6bf4305a090de172ebfb63bcf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Directus Lacks Session Tokens Invalidation"
}

GHSA-G692-X4M9-J29G

Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38
VLAI
Details

IBM OpenPages GRC Platform 7.1, 7.2, and 7.3 could allow a local user to obtain sensitive information when a previous user has logged out of the system but neglected to close their browser. IBM X-Force ID: 110303.

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

{
  "affected": [],
  "aliases": [
    "CVE-2016-0234"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-30T16:29:00Z",
    "severity": "LOW"
  },
  "details": "IBM OpenPages GRC Platform 7.1, 7.2, and 7.3 could allow a local user to obtain sensitive information when a previous user has logged out of the system but neglected to close their browser. IBM X-Force ID: 110303.",
  "id": "GHSA-g692-x4m9-j29g",
  "modified": "2022-05-13T01:38:51Z",
  "published": "2022-05-13T01:38:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-0234"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/110303"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21997687"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G72G-R7M4-9X4G

Vulnerability from github – Published: 2026-06-05 16:43 – Updated: 2026-07-20 21:19
VLAI
Summary
NocoDB: OAuth Tokens Persist Through Security Events
Details

Summary

OAuth access and refresh tokens were not revoked when the user changed, reset, or recovered their password, leaving an attacker-issued OAuth grant valid after the user believed they had locked the attacker out.

Details

revokeAllOAuthTokensByUser in the users service was an empty stub being called from passwordChange, passwordForgot, and passwordReset. It now delegates to OAuthToken.revokeAllByUser(userId), which deletes the rows and invalidates the related auth caches. All three reset/recovery flows now consistently revoke refresh tokens (GHSA-r989-7g3j-wjhw), OAuth tokens (this advisory), and rotate token_version.

Impact

Persistent unauthorized access through previously issued OAuth tokens after a documented security event (password change, forgot, or reset).

Credit

This issue was reported by @bugbunny-research.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.05.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "nocodb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.05.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53926"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-05T16:43:09Z",
    "nvd_published_at": "2026-06-23T21:17:01Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nOAuth access and refresh tokens were not revoked when the user changed, reset, or\nrecovered their password, leaving an attacker-issued OAuth grant valid after the user\nbelieved they had locked the attacker out.\n\n### Details\n`revokeAllOAuthTokensByUser` in the users service was an empty stub being called from\n`passwordChange`, `passwordForgot`, and `passwordReset`. It now delegates to\n`OAuthToken.revokeAllByUser(userId)`, which deletes the rows and invalidates the\nrelated auth caches. All three reset/recovery flows now consistently revoke refresh\ntokens (GHSA-r989-7g3j-wjhw), OAuth tokens (this advisory), and rotate\n`token_version`.\n\n### Impact\nPersistent unauthorized access through previously issued OAuth tokens after a\ndocumented security event (password change, forgot, or reset).\n\n### Credit\nThis issue was reported by [@bugbunny-research](https://github.com/bugbunny-research).",
  "id": "GHSA-g72g-r7m4-9x4g",
  "modified": "2026-07-20T21:19:51Z",
  "published": "2026-06-05T16:43:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nocodb/nocodb/security/advisories/GHSA-g72g-r7m4-9x4g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53926"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nocodb/nocodb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nocodb/nocodb/releases/tag/2026.05.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "NocoDB: OAuth Tokens Persist Through Security Events"
}

GHSA-G785-R4R2-28QV

Vulnerability from github – Published: 2023-01-05 09:30 – Updated: 2023-01-11 03:30
VLAI
Details

IBM Sterling B2B Integrator Standard Edition 6.0.0.0 through 6.1.2.1 does not invalidate session after a password change which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 221195.

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-22371"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-05T07:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Sterling B2B Integrator Standard Edition 6.0.0.0 through 6.1.2.1 does not invalidate session after a password change which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 221195.",
  "id": "GHSA-g785-r4r2-28qv",
  "modified": "2023-01-11T03:30:19Z",
  "published": "2023-01-05T09:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22371"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/221195"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6852461"
    }
  ],
  "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-G797-R4R7-WP94

Vulnerability from github – Published: 2024-11-26 21:32 – Updated: 2024-11-26 21:32
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions from 16.11 before 17.4.5, 17.5 before 17.5.3, and 17.6 before 17.6.1. Long-lived connections could potentially bypass authentication controls, allowing unauthorized access to streaming results.

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": [],
  "aliases": [
    "CVE-2024-11668"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-26T19:15:22Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions from 16.11 before 17.4.5, 17.5 before 17.5.3, and 17.6 before 17.6.1. Long-lived connections could potentially bypass authentication controls, allowing unauthorized access to streaming results.",
  "id": "GHSA-g797-r4r7-wp94",
  "modified": "2024-11-26T21:32:24Z",
  "published": "2024-11-26T21:32:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11668"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/456922"
    }
  ],
  "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"
    }
  ]
}

GHSA-G7R3-JWHW-2WFV

Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2023-08-23 17:58
VLAI
Summary
Microweber Insufficient Session Expiry
Details

Microweber v1.1.18 is affected by no session expiry after log-out.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "microweber/microweber"
      },
      "versions": [
        "1.1.18"
      ]
    }
  ],
  "aliases": [
    "CVE-2020-23136"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-13T21:47:43Z",
    "nvd_published_at": "2020-11-09T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Microweber v1.1.18 is affected by no session expiry after log-out.",
  "id": "GHSA-g7r3-jwhw-2wfv",
  "modified": "2023-08-23T17:58:02Z",
  "published": "2022-05-24T17:33:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-23136"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/virendratiwari03/0b0d161e1141fdd74122abbb02fefe17"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/microweber/microweber"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Microweber Insufficient Session Expiry"
}
Mitigation
Implementation

Set sessions/credentials expiration date.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list