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."

875 vulnerabilities reference this CWE, most recent first.

GHSA-F7GQ-H8JV-H3CQ

Vulnerability from github – Published: 2025-06-17 14:20 – Updated: 2026-04-06 23:14
VLAI
Summary
ash_authentication_phoenix has Insufficient Session Expiration
Details

Impact

Session tokens remain valid on the server after user logout, creating a security gap where:

  • Compromised tokens (via XSS, network interception, or device theft) continue to work even after the user logs out
  • The sessions stored in the database still expire, limiting the duration during which this could be exploited
  • Users cannot fully invalidate their sessions when logging out from shared or potentially compromised devices
  • by default, changing one's password does invalidate all other sessions, so changing your password as a security measure would have been effective
  • May cause compliance issues with security frameworks requiring complete session

Patches

Upgrade to version 2.10.0. After upgrading, users must update their AuthController implementation to use the new clear_session/2 function with their OTP app name. You will be prompted to do so with a compile-time error.

If you do not have the setting require_token_presence_for_authentication? set to true in the tokens section, you will see a separate error:

** (Spark.Error.DslError) authentication -> session_identifier:
Must set `authentication.session_identifier` to either `:jti` or `:unsafe`.

...

In order to revoke sessions on log out when not storing tokens directly in the session, we must have some unique identifier with which to do so. You should prefer to enable require_token_presence_for_authentication? if possible, instead of setting this to :jti. Note that whatever you do here, if you did not previously have require_token_presence_for_authentication? set to true, setting it to true or setting authentication.session_identifier to :jti will log out all of your currently authenticated users.

Workarounds

You can manually revoke tokens in your logout/2 handler in your auth controller.

Severity
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/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= 2.9.0"
      },
      "package": {
        "ecosystem": "Hex",
        "name": "ash_authentication_phoenix"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-4754"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-17T14:20:46Z",
    "nvd_published_at": "2025-06-17T15:15:53Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nSession tokens remain valid on the server after user logout, creating a security gap where:\n\n- Compromised tokens (via XSS, network interception, or device theft) continue to work even after the user logs out\n  - The sessions stored in the database still expire, limiting the duration during which this could be exploited\n- Users cannot fully invalidate their sessions when logging out from shared or potentially compromised devices \n  - by default, changing one\u0027s password *does* invalidate all other sessions, so changing your password as a security measure would have been effective\n- May cause compliance issues with security frameworks requiring complete session \n### Patches\nUpgrade to version 2.10.0. After upgrading, users must update their AuthController implementation to use the new `clear_session/2` function with their OTP app name. You will be prompted to do so with a compile-time error.\n\nIf you do not have the setting `require_token_presence_for_authentication?` set to `true` in the `tokens` section, you will see a separate error:\n\n```\n** (Spark.Error.DslError) authentication -\u003e session_identifier:\nMust set `authentication.session_identifier` to either `:jti` or `:unsafe`.\n\n...\n```\n\nIn order to revoke sessions on log out when not storing tokens directly in the session, we must have some unique identifier with which to do so. You should prefer to enable `require_token_presence_for_authentication?` if possible, instead of setting this to `:jti`. Note that whatever you do here, if you did not previously have `require_token_presence_for_authentication?` set to `true`, setting it to `true` *or* setting `authentication.session_identifier` to `:jti` will log out all of your currently authenticated users.\n\n### Workarounds\nYou can manually revoke tokens in your `logout/2` handler in your auth controller.",
  "id": "GHSA-f7gq-h8jv-h3cq",
  "modified": "2026-04-06T23:14:59Z",
  "published": "2025-06-17T14:20:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/team-alembic/ash_authentication_phoenix/security/advisories/GHSA-f7gq-h8jv-h3cq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4754"
    },
    {
      "type": "WEB",
      "url": "https://github.com/team-alembic/ash_authentication_phoenix/pull/634"
    },
    {
      "type": "WEB",
      "url": "https://github.com/team-alembic/ash_authentication_phoenix/commit/a3253fb4fc7145aeb403537af1c24d3a8d51ffb1"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2025-4754.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/team-alembic/ash_authentication_phoenix"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2025-4754"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ash_authentication_phoenix has Insufficient Session Expiration"
}

GHSA-F8CM-364F-Q9QH

Vulnerability from github – Published: 2020-10-20 20:03 – Updated: 2021-11-19 13:51
VLAI
Summary
Ensure that doorkeeper_token is valid when authenticating requests in API v2 calls
Details

Impact

The perpetrator who previously obtained an old expired user token could use it to access Storefront API v2 endpoints.

Patches

Please upgrade to 3.7.11, 4.0.4, or 4.1.11 depending on your used Spree version.

Workarounds

In your project directory create a decorator file app/controllers/spree/api/v2/base_controller_decotatror.rb with contents:

module Spree
  module Api
    module V2
      module BaseControllerDecorator
        private

        def spree_current_user
          return nil unless doorkeeper_token
          return @spree_current_user if @spree_current_user

          doorkeeper_authorize!

          @spree_current_user ||= ::Spree.user_class.find_by(id: doorkeeper_token.resource_owner_id)
        end
     end
  end
end

Spree::Api::V2::BaseController.prepend(Spree::Api::V2::BaseControllerDecorator)

For more information

If you have any questions or comments about this advisory: * Email us at security@spreecommerce.org

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "spree"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.7.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "spree"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "spree"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15269"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-10-20T20:03:19Z",
    "nvd_published_at": "2020-10-20T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nThe perpetrator who previously obtained an old expired user token could use it to access Storefront API v2 endpoints. \n\n### Patches\nPlease upgrade to 3.7.11, 4.0.4, or 4.1.11 depending on your used Spree version. \n\n### Workarounds\nIn your project directory create a decorator file `app/controllers/spree/api/v2/base_controller_decotatror.rb` with contents:\n\n```ruby\nmodule Spree\n  module Api\n    module V2\n      module BaseControllerDecorator\n        private\n\n        def spree_current_user\n          return nil unless doorkeeper_token\n          return @spree_current_user if @spree_current_user\n\n          doorkeeper_authorize!\n\n          @spree_current_user ||= ::Spree.user_class.find_by(id: doorkeeper_token.resource_owner_id)\n        end\n     end\n  end\nend\n\nSpree::Api::V2::BaseController.prepend(Spree::Api::V2::BaseControllerDecorator)\n```\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [security@spreecommerce.org](mailto:security@spreecommerce.org)",
  "id": "GHSA-f8cm-364f-q9qh",
  "modified": "2021-11-19T13:51:14Z",
  "published": "2020-10-20T20:03:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/spree/spree/security/advisories/GHSA-f8cm-364f-q9qh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15269"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spree/spree/commit/e43643abfe51f54bd9208dd02298b366e9b9a847"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/spree/CVE-2020-15269.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/spree/spree"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Ensure that doorkeeper_token is valid when authenticating requests in API v2 calls"
}

GHSA-F928-H33X-JM46

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

A Weak Session Management vulnerability in Citadel WebCit through 926 allows unauthenticated remote attackers to hijack recently logged-in users' sessions. NOTE: this was reported to the vendor in a publicly archived "Multiple Security Vulnerabilities in WebCit 926" thread.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-27739"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-28T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A Weak Session Management vulnerability in Citadel WebCit through 926 allows unauthenticated remote attackers to hijack recently logged-in users\u0027 sessions. NOTE: this was reported to the vendor in a publicly archived \"Multiple Security Vulnerabilities in WebCit 926\" thread.",
  "id": "GHSA-f928-h33x-jm46",
  "modified": "2022-05-24T17:32:36Z",
  "published": "2022-05-24T17:32:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27739"
    },
    {
      "type": "WEB",
      "url": "https://www.citadel.org"
    },
    {
      "type": "WEB",
      "url": "http://uncensored.citadel.org/readfwd?go=Citadel%20Security?start_reading_at=4592834"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-F9FF-5X35-7GFW

Vulnerability from github – Published: 2026-07-02 19:35 – Updated: 2026-07-02 19:35
VLAI
Summary
Grackle: Fail-open authorization in the MCP tool layer lets scoped agents perform cross-task and cross-session mutations (IDOR)
Details

Summary

Authorization for scoped (agent) MCP callers is enforced inline, per tool, and is applied inconsistently — several mutating tools silently omit the ancestry/workspace check that their siblings perform. Because the MCP server authenticates all outbound gRPC with the full server API key and the backend gRPC handlers perform no caller-based authorization, the MCP tool layer is the sole authorization boundary. A malicious or prompt-injected scoped agent can therefore perform cross-task and cross-session operations it should not be allowed to (an IDOR / privilege-boundary bypass).

This advisory bundles the audit's Systemic Pattern A findings: F2, F6, F7, F12 (and the duplicate F19).

Affected versions

@grackle-ai/mcp (with @grackle-ai/plugin-core / @grackle-ai/auth) at 0.132.1 and earlier.

Root cause

  • mcp-server.ts:111-127 (createGrpcClients) sets Authorization: Bearer ${apiKey} (the full server key) on every outbound gRPC call.
  • Backend handlers (updateTask, deleteTask, resumeTask, killAgent, getTask in plugin-core) take only the request message — no AuthContext — and act on whatever ID is passed.
  • Therefore scope must be enforced in each MCP tool handler. Some call assertCallerIsAncestor (task_complete, task_start, session_attach, session_send_input); their destructive siblings do not. New tools that forget the check fail open.

F2 — task_update / task_delete / task_resume bypass ancestry (High)

Location: packages/mcp/src/tools/task.ts:226 (task_update), :393 (task_delete), :465 (task_resume).

These accept an arbitrary taskId with only a ROOT_TASK_ID special-case and no assertCallerIsAncestor. The central dispatcher hardcodes its workspace gate to name === "task_show", and these tools' Zod schemas have no workspaceId field (so the blanket injection is stripped). They are not in DEFAULT_SCOPED_MCP_TOOLS but are in the shipped ORCHESTRATOR_MCP_TOOLS / ADMIN_MCP_TOOLS presets.

Exploit: a scoped agent under the orchestrator persona learns a sibling/parent/cross-workspace task ID (via task_list/task_search), then task_delete {taskId: <victim>} (permanently destroys another agent's or the human parent's work) or task_update to flip a sibling to complete/failed or rewrite its dependency DAG and budgets.

F6 — session_kill / session_resume bypass ancestry (Medium)

Location: packages/mcp/src/tools/session.ts:95 (session_resume), :178 (session_kill).

Call client.killAgent / client.resumeAgent directly with no auth context, unlike session_attach/session_send_input. session_kill is in the orchestrator preset. Exploit: cross-session SIGKILL DoS against a sibling agent or the root orchestrator; foreign session resume.

F7 — Workspaceless scoped token fails open to all workspaces (Medium)

Location: packages/mcp/src/mcp-server.ts:565-600.

The per-task cross-workspace check (task_show block) is gated on authContext.workspaceId being truthy. A task created without a workspace (a supported config) mints a scoped token with pid: "" → workspaceId: undefined, so the check is skipped and the injected workspaceId becomes "", which the backend treats as "all workspaces." Exploit: a malicious agent in a workspaceless session calls task_list (no args) → reads every task in every workspace, then task_show {taskId} cross-workspace (title/description/branch/review-notes). schedule_show (in the default scoped allowlist) resolves by ID with no workspace check. Read-only cross-workspace disclosure.

F12 — Scoped-token revocation is dead code (Low)

Location: packages/auth/src/scoped-token.ts:23,142-149.

The consuming check is wired (auth-middleware.ts:90-92), but revokeTask() is never called outside tests — no task-abort/stop flow invokes it — and the backing revokedTasks Map is in-memory only (lost on restart). A compromised agent that exfiltrated its scoped token keeps authenticating for the full 24h TTL regardless of task lifecycle.

Remediation

  • Systemic fix: enforce scope centrally in the CallToolRequest dispatcher (mcp-server.ts) via a per-tool targetTaskIdArg / targetSessionIdArg descriptor so any tool that targets a task/session fails closed unless the caller is an ancestor (or self).
  • Immediately, add assertCallerIsAncestor (or self-or-ancestor) to task_update, task_delete, task_resume, session_kill, session_resume, mirroring task_complete/task_start.
  • F7: do not fail open on empty workspaceId — treat a scoped non-root caller with no workspace as having access to no workspace; apply the task_show membership check whenever the caller is scoped and not ROOT_TASK_ID; add a per-id membership check to schedule_show.
  • F12: wire revokeTask() into task-abort/stop flows with SQLite-backed persistence (like channel-grant revocation), or remove the dead API and document the 24h window.
  • Add regression tests mirroring the existing task_complete ancestor tests for each mutator.

CWEs

CWE-862 (Missing Authorization), CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR), CWE-613 (Insufficient Session Expiration).

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/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": "@grackle-ai/mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.132.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@grackle-ai/plugin-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.132.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@grackle-ai/auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.132.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-613",
      "CWE-639",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T19:35:03Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAuthorization for scoped (agent) MCP callers is enforced **inline, per tool**, and is applied inconsistently \u2014 several mutating tools silently omit the ancestry/workspace check that their siblings perform. Because the MCP server authenticates all outbound gRPC with the full server API key and the backend gRPC handlers perform **no caller-based authorization**, the MCP tool layer is the *sole* authorization boundary. A malicious or prompt-injected scoped agent can therefore perform cross-task and cross-session operations it should not be allowed to (an IDOR / privilege-boundary bypass).\n\nThis advisory bundles the audit\u0027s **Systemic Pattern A** findings: **F2, F6, F7, F12** (and the duplicate F19).\n\n## Affected versions\n\n`@grackle-ai/mcp` (with `@grackle-ai/plugin-core` / `@grackle-ai/auth`) at **0.132.1** and earlier.\n\n## Root cause\n\n- `mcp-server.ts:111-127` (`createGrpcClients`) sets `Authorization: Bearer ${apiKey}` (the full server key) on every outbound gRPC call.\n- Backend handlers (`updateTask`, `deleteTask`, `resumeTask`, `killAgent`, `getTask` in `plugin-core`) take only the request message \u2014 no `AuthContext` \u2014 and act on whatever ID is passed.\n- Therefore scope must be enforced in each MCP tool handler. Some call `assertCallerIsAncestor` (`task_complete`, `task_start`, `session_attach`, `session_send_input`); their destructive siblings do not. New tools that forget the check **fail open**.\n\n## F2 \u2014 task_update / task_delete / task_resume bypass ancestry (High)\n\n**Location:** `packages/mcp/src/tools/task.ts:226` (task_update), `:393` (task_delete), `:465` (task_resume).\n\nThese accept an arbitrary `taskId` with only a `ROOT_TASK_ID` special-case and no `assertCallerIsAncestor`. The central dispatcher hardcodes its workspace gate to `name === \"task_show\"`, and these tools\u0027 Zod schemas have no `workspaceId` field (so the blanket injection is stripped). They are not in `DEFAULT_SCOPED_MCP_TOOLS` but **are** in the shipped `ORCHESTRATOR_MCP_TOOLS` / `ADMIN_MCP_TOOLS` presets.\n\n**Exploit:** a scoped agent under the orchestrator persona learns a sibling/parent/cross-workspace task ID (via `task_list`/`task_search`), then `task_delete {taskId: \u003cvictim\u003e}` (permanently destroys another agent\u0027s or the human parent\u0027s work) or `task_update` to flip a sibling to `complete`/`failed` or rewrite its dependency DAG and budgets.\n\n## F6 \u2014 session_kill / session_resume bypass ancestry (Medium)\n\n**Location:** `packages/mcp/src/tools/session.ts:95` (session_resume), `:178` (session_kill).\n\nCall `client.killAgent` / `client.resumeAgent` directly with no auth context, unlike `session_attach`/`session_send_input`. `session_kill` is in the orchestrator preset. **Exploit:** cross-session SIGKILL DoS against a sibling agent or the root orchestrator; foreign session resume.\n\n## F7 \u2014 Workspaceless scoped token fails open to all workspaces (Medium)\n\n**Location:** `packages/mcp/src/mcp-server.ts:565-600`.\n\nThe per-task cross-workspace check (`task_show` block) is gated on `authContext.workspaceId` being truthy. A task created without a workspace (a supported config) mints a scoped token with `pid: \"\"` \u2192 `workspaceId: undefined`, so the check is skipped and the injected `workspaceId` becomes `\"\"`, which the backend treats as \"all workspaces.\" **Exploit:** a malicious agent in a workspaceless session calls `task_list` (no args) \u2192 reads every task in every workspace, then `task_show {taskId}` cross-workspace (title/description/branch/review-notes). `schedule_show` (in the default scoped allowlist) resolves by ID with no workspace check. Read-only cross-workspace disclosure.\n\n## F12 \u2014 Scoped-token revocation is dead code (Low)\n\n**Location:** `packages/auth/src/scoped-token.ts:23,142-149`.\n\nThe consuming check is wired (`auth-middleware.ts:90-92`), but `revokeTask()` is **never called outside tests** \u2014 no task-abort/stop flow invokes it \u2014 and the backing `revokedTasks` Map is in-memory only (lost on restart). A compromised agent that exfiltrated its scoped token keeps authenticating for the full 24h TTL regardless of task lifecycle.\n\n## Remediation\n\n- **Systemic fix:** enforce scope **centrally** in the `CallToolRequest` dispatcher (`mcp-server.ts`) via a per-tool `targetTaskIdArg` / `targetSessionIdArg` descriptor so any tool that targets a task/session **fails closed** unless the caller is an ancestor (or self).\n- Immediately, add `assertCallerIsAncestor` (or self-or-ancestor) to `task_update`, `task_delete`, `task_resume`, `session_kill`, `session_resume`, mirroring `task_complete`/`task_start`.\n- F7: do **not** fail open on empty `workspaceId` \u2014 treat a scoped non-root caller with no workspace as having access to *no* workspace; apply the `task_show` membership check whenever the caller is scoped and not `ROOT_TASK_ID`; add a per-id membership check to `schedule_show`.\n- F12: wire `revokeTask()` into task-abort/stop flows with SQLite-backed persistence (like channel-grant revocation), or remove the dead API and document the 24h window.\n- Add regression tests mirroring the existing `task_complete` ancestor tests for each mutator.\n\n## CWEs\n\nCWE-862 (Missing Authorization), CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR), CWE-613 (Insufficient Session Expiration).",
  "id": "GHSA-f9ff-5x35-7gfw",
  "modified": "2026-07-02T19:35:03Z",
  "published": "2026-07-02T19:35:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nick-pape/grackle/security/advisories/GHSA-f9ff-5x35-7gfw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nick-pape/grackle"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Grackle: Fail-open authorization in the MCP tool layer lets scoped agents perform cross-task and cross-session mutations (IDOR)"
}

GHSA-F9XM-74VQ-4X7M

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

Improper session invalidation in the component /crm/change-password.php of PHPGurukul Online Course Registration v3.1 allows attackers to execute a session hijacking attack.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-50485"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-28T20:17:47Z",
    "severity": "HIGH"
  },
  "details": "Improper session invalidation in the component /crm/change-password.php of PHPGurukul Online Course Registration v3.1 allows attackers to execute a session hijacking attack.",
  "id": "GHSA-f9xm-74vq-4x7m",
  "modified": "2025-07-28T21:31:35Z",
  "published": "2025-07-28T21:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50485"
    },
    {
      "type": "WEB",
      "url": "https://github.com/VasilVK/CVE/tree/main/CVE-2025-50485"
    },
    {
      "type": "WEB",
      "url": "http://online.com"
    },
    {
      "type": "WEB",
      "url": "http://phpgurukul.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FCC5-X3G2-XC22

Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2022-10-01 00:00
VLAI
Details

A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. The revocation feature was not revoking all session tokens and one could re-use it to obtain a valid session.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-13299"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-14T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was discovered in GitLab versions before 13.1.10, 13.2.8 and 13.3.4. The revocation feature was not revoking all session tokens and one could re-use it to obtain a valid session.",
  "id": "GHSA-fcc5-x3g2-xc22",
  "modified": "2022-10-01T00:00:20Z",
  "published": "2022-05-24T17:28:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13299"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/896225"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13299.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/222508"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FFV4-58CG-F6V5

Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2022-12-09 21:30
VLAI
Details

IBM Tivoli Storage Productivity Center (IBM Spectrum Control Standard Edition 5.2.1 through 5.2.17) allows users to remain idle within the application even when a user has logged out. Utilizing the application back button users can remain logged in as the current user for a short period of time, therefore users are presented with information for Spectrum Control Application. IBM X-Force ID: 157064.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-4072"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-09T15:29:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Tivoli Storage Productivity Center (IBM Spectrum Control Standard Edition 5.2.1 through 5.2.17) allows users to remain idle within the application even when a user has logged out. Utilizing the application back button users can remain logged in as the current user for a short period of time, therefore users are presented with information for Spectrum Control Application. IBM X-Force ID: 157064.",
  "id": "GHSA-ffv4-58cg-f6v5",
  "modified": "2022-12-09T21:30:53Z",
  "published": "2022-05-24T16:45:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-4072"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/157064"
    },
    {
      "type": "WEB",
      "url": "http://www.ibm.com/support/docview.wss?uid=ibm10873036"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FGQM-87V3-4QJ6

Vulnerability from github – Published: 2024-07-09 18:30 – Updated: 2024-07-09 18:30
VLAI
Details

Multiple insufficient session expiration vulnerabilities [CWE-613] in FortiAIOps version 2.0.0 may allow an attacker to re-use stolen old session tokens to perform unauthorized operations via crafted requests.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-27782"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-09T16:15:05Z",
    "severity": "HIGH"
  },
  "details": "Multiple insufficient session expiration vulnerabilities [CWE-613]  in FortiAIOps version 2.0.0 may allow an attacker to re-use stolen old session tokens to perform unauthorized operations via crafted requests.",
  "id": "GHSA-fgqm-87v3-4qj6",
  "modified": "2024-07-09T18:30:48Z",
  "published": "2024-07-09T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27782"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-069"
    }
  ],
  "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"
    }
  ]
}

GHSA-FH84-5Q42-44P3

Vulnerability from github – Published: 2026-02-05 00:31 – Updated: 2026-02-05 00:31
VLAI
Details

IBM Concert 1.0.0 through 2.1.0 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-43181"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-04T22:15:56Z",
    "severity": "MODERATE"
  },
  "details": "IBM Concert 1.0.0 through 2.1.0 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system.",
  "id": "GHSA-fh84-5q42-44p3",
  "modified": "2026-02-05T00:31:00Z",
  "published": "2026-02-05T00:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43181"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7257006"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FJ52-5G4H-GMQ8

Vulnerability from github – Published: 2026-04-14 23:39 – Updated: 2026-04-14 23:39
VLAI
Summary
pyLoad's Session Not Invalidated After Permission Changes
Details

Summary

The pyload application does not properly invalidate or modify sessions upon changes made to a user's permissions.

Details

Whenever an administrator changes the permissions a specific account has, they do not expect that account still being able to access data that their new permissions do not allow. This is not the case for the pyload application, as a user with a valid session can still perform the actions.

PoC

Take a user with all the permissions, as shown below. image

We now log in as this user. image

Let us now take away all the permissions. image

The logged in session can still be used to access everything in the application. image

Impact

Should permissions be taken away, then the user is expected not to be able to execute the actions belonging to those actions anymore.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pyload-ng"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.5.0b3.dev97"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T23:39:25Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\nThe `pyload` application does not properly invalidate or modify sessions upon changes made to a user\u0027s permissions.\n\n### Details\nWhenever an administrator changes the permissions a specific account has, they do not expect that account still being able to access data that their new permissions do not allow. This is not the case for the `pyload` application, as a user with a valid session can still perform the actions.\n\n### PoC\nTake a user with all the permissions, as shown below.\n![image](https://user-images.githubusercontent.com/44903767/294956335-0e4da84f-bf9a-42c8-87f1-f5ff35967c63.png)\n\nWe now log in as this user.\n![image](https://user-images.githubusercontent.com/44903767/294956539-ac6805fe-957d-4289-8ca9-2f3b6b2878a3.png)\n\nLet us now take away all the permissions.\n![image](https://user-images.githubusercontent.com/44903767/294956689-757e6e08-03fd-42eb-b4a5-1ceefa6c24ed.png)\n\nThe logged in session can still be used to access everything in the application.\n![image](https://user-images.githubusercontent.com/44903767/294956943-fa0f23c0-a28c-4eed-89d6-1cc074feda6d.png)\n\n### Impact\nShould permissions be taken away, then the user is expected not to be able to execute the actions belonging to those actions anymore.",
  "id": "GHSA-fj52-5g4h-gmq8",
  "modified": "2026-04-14T23:39:25Z",
  "published": "2026-04-14T23:39:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pyload/pyload/security/advisories/GHSA-fj52-5g4h-gmq8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pyload/pyload/commit/e95804fb0d06cbb07d2ba380fc494d9ff89b68c1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pyload/pyload"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pyLoad\u0027s Session Not Invalidated After Permission Changes"
}
Mitigation
Implementation

Set sessions/credentials expiration date.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list