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

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

968 vulnerabilities reference this CWE, most recent first.

GHSA-85R2-J732-H557

Vulnerability from github – Published: 2026-06-30 21:31 – Updated: 2026-06-30 21:31
VLAI
Details

IBM DevOps Automation 1.0.1 and IBM DevOps Loop 1.0.2 does not invalidate session IDs after expiration which could allow an authenticated user to impersonate another user on the system.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-36359"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T21:16:30Z",
    "severity": "HIGH"
  },
  "details": "IBM DevOps Automation 1.0.1 and IBM DevOps Loop 1.0.2 does not invalidate session IDs after expiration which could allow an authenticated user to impersonate another user on the system.",
  "id": "GHSA-85r2-j732-h557",
  "modified": "2026-06-30T21:31:45Z",
  "published": "2026-06-30T21:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36359"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7277970"
    }
  ],
  "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-8863-4QMG-FR45

Vulnerability from github – Published: 2025-01-08 09:30 – Updated: 2025-01-08 16:14
VLAI
Summary
Apache Airflow Fab Provider Insufficient Session Expiration vulnerability
Details

Insufficient Session Expiration vulnerability in Apache Airflow Fab Provider.

This issue affects Apache Airflow Fab Provider: before 1.5.2.

When user password has been changed with admin CLI, the sessions for that user have not been cleared, leading to insufficient session expiration, thus logged users could continue to be logged in even after the password was changed. This only happened when the password was changed with CLI. The problem does not happen in case change was done with webserver thus this is different from CVE-2023-40273 which was addressed in Apache-Airflow 2.7.0

Users are recommended to upgrade to version 1.5.2, which fixes the issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-airflow-providers-fab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45033"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-08T16:14:43Z",
    "nvd_published_at": "2025-01-08T09:15:07Z",
    "severity": "LOW"
  },
  "details": "Insufficient Session Expiration vulnerability in Apache Airflow Fab Provider.\n\nThis issue affects Apache Airflow Fab Provider: before 1.5.2.\n\nWhen user password has been changed with admin CLI, the sessions for that user have not been cleared, leading to insufficient session expiration, thus logged users could continue to be logged in even after the password was changed. This only happened when the password was changed with CLI. The problem does not happen in case change was done with webserver thus this is different from\u00a0[CVE-2023-40273](https://github.com/advisories/GHSA-pm87-24wq-r8w9)\u00a0which was addressed in Apache-Airflow 2.7.0\n\n\nUsers are recommended to upgrade to version 1.5.2, which fixes the issue.",
  "id": "GHSA-8863-4qmg-fr45",
  "modified": "2025-01-08T16:14:43Z",
  "published": "2025-01-08T09:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45033"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/pull/45139"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/airflow"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/yw535346rk766ybzpqtvrl36sjj789st"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Airflow Fab Provider Insufficient Session Expiration vulnerability"
}

GHSA-88RM-6CPC-9J4W

Vulnerability from github – Published: 2026-07-22 21:32 – Updated: 2026-08-07 06:30
VLAI
Details

Question2Answer through 1.8.8 contains a session invalidation vulnerability that allows attackers with a previously obtained remember-me cookie to retain authenticated access by exploiting the forgot-password reset flow's failure to clear the sessioncode field in qa-include/app/users-edit.php. While the normal password-change flow in qa-include/pages/account.php explicitly clears the sessioncode to invalidate persistent qa_session cookies, the forgot-password handler qa_finish_reset_user() omits this step, allowing any valid persistent cookie issued before the reset to continue authenticating the account after the password reset completes.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T20:17:08Z",
    "severity": "CRITICAL"
  },
  "details": "Question2Answer through 1.8.8 contains a session invalidation vulnerability that allows attackers with a previously obtained remember-me cookie to retain authenticated access by exploiting the forgot-password reset flow\u0027s failure to clear the sessioncode field in qa-include/app/users-edit.php. While the normal password-change flow in qa-include/pages/account.php explicitly clears the sessioncode to invalidate persistent qa_session cookies, the forgot-password handler qa_finish_reset_user() omits this step, allowing any valid persistent cookie issued before the reset to continue authenticating the account after the password reset completes.",
  "id": "GHSA-88rm-6cpc-9j4w",
  "modified": "2026-08-07T06:30:22Z",
  "published": "2026-07-22T21:32:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64829"
    },
    {
      "type": "WEB",
      "url": "https://github.com/q2a/question2answer/pull/1017"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/question2answer-session-fixation-via-forgot-password-flow"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2026/Aug/32"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/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-895X-RFQP-JH5C

Vulnerability from github – Published: 2025-10-23 15:30 – Updated: 2026-02-17 17:21
VLAI
Summary
Keycloak does not invalidate offline sessions when the offline_access scope is removed
Details

A flaw was found in Keycloak. An offline session continues to be valid when the offline_access scope is removed from the client. The refresh token is accepted and you can continue to request new tokens for the session. As it can lead to a situation where an administrator removes the scope, and assumes that offline sessions are no longer available, but they are.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-12110"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-23T19:24:54Z",
    "nvd_published_at": "2025-10-23T15:15:32Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in Keycloak. An offline session continues to be valid when the offline_access scope is removed from the client. The refresh token is accepted and you can continue to request new tokens for the session. As it can lead to a situation where an administrator removes the scope, and assumes that offline sessions are no longer available, but they are.",
  "id": "GHSA-895x-rfqp-jh5c",
  "modified": "2026-02-17T17:21:35Z",
  "published": "2025-10-23T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12110"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/pull/43790"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/54e1c8af1e089ad33d32e0f2792610e4b8df421b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/c830a27928cac4294619af7d147bdff34d4a85e7"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21370"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21371"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:22088"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:22089"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-12110"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2406033"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "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": "Keycloak does not invalidate offline sessions when the offline_access scope is removed"
}

GHSA-89HR-6X2P-8XJV

Vulnerability from github – Published: 2026-03-31 15:31 – Updated: 2026-03-31 23:51
Withdrawn 2026-03-31 VLAI
Summary
Duplicate Advisory: OpenClaw's device removal and token revocation do not terminate active WebSocket sessions
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-2pr2-hcv6-7gwv. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.3.28 fails to disconnect active WebSocket sessions when devices are removed or tokens are revoked. Attackers with revoked credentials can maintain unauthorized access through existing live sessions until forced reconnection.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-31T23:51:46Z",
    "nvd_published_at": "2026-03-31T15:16:19Z",
    "severity": "HIGH"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-2pr2-hcv6-7gwv. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.28 fails to disconnect active WebSocket sessions when devices are removed or tokens are revoked. Attackers with revoked credentials can maintain unauthorized access through existing live sessions until forced reconnection.",
  "id": "GHSA-89hr-6x2p-8xjv",
  "modified": "2026-03-31T23:51:46Z",
  "published": "2026-03-31T15:31:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-2pr2-hcv6-7gwv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34503"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/7a801cc451e9e667b705eeccff651923a1b8c863"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-incomplete-websocket-session-termination-on-device-removal-and-token-revocation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/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"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw\u0027s device removal and token revocation do not terminate active WebSocket sessions",
  "withdrawn": "2026-03-31T23:51:46Z"
}

GHSA-8C39-XPPG-479C

Vulnerability from github – Published: 2026-01-06 17:18 – Updated: 2026-01-06 17:18
VLAI
Summary
Pterodactyl does not revoke SFTP access when server is deleted or permissions reduced
Details

Summary

Pterodactyl does not revoke active SFTP connections when a user is removed from a server instance or has their permissions changes with respect to file access over SFTP. This allows a user that was already connected to SFTP to remain connected and access files even after their permissions are revoked.

Details

When a user opens a connection to a server using the Wings SFTP server instance the permissions are checked and returned from the authentication API call made to the Panel. However, credentials are not checked again after the initial handshake. Thus, if a user is removed from a server in the panel or have their permissions modified, those permissions are not updated in the SFTP connection.

As a result, a user that has already gained access to a server's files via the SFTP subsystem will maintain those permissions until disconnected (via Wings restart, or a manual disconnection on their end).

[!NOTE]

This issue impacts the SFTP subsystem for server files specifically. There is no exposure of Wings private data, or any data outside of a server's local filesystem. Additionally, a user must have been connected to SFTP at the time of their permissions being revoked in order for this issue to be exploited. If a user was not connected, they would not be able to connect once their permissions were reduced.

Fix

Please upgrade to wings@1.12.0 and panel@1.12.0 to resolve this issue. Patches are available via the implementation PRs, but it is recommended to apply by upgrading the entire instance.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pterodactyl/panel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pterodactyl/wings"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-06T17:18:56Z",
    "nvd_published_at": "2026-01-06T01:16:01Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nPterodactyl does not revoke _active_ SFTP connections when a user is removed from a server instance or has their permissions changes with respect to file access over SFTP. This allows a user that was already connected to SFTP to remain connected and access files even after their permissions are revoked.\n\n### Details\nWhen a user opens a connection to a server using the Wings SFTP server instance the permissions are checked and returned from the authentication API call made to the Panel. However, credentials are not checked again after the initial handshake. Thus, if a user is removed from a server in the panel or have their permissions modified, those permissions are not updated in the SFTP connection.\n\nAs a result, a user that has already gained access to a server\u0027s files via the SFTP subsystem will maintain those permissions until disconnected (via Wings restart, or a manual disconnection on their end).\n\n\u003e [!NOTE]\n\u003e\n\u003e This issue impacts the SFTP subsystem for server files specifically. There is no exposure of Wings private data, or any data outside of a server\u0027s local filesystem. Additionally, a user must have been _connected to SFTP at the time of their permissions being revoked_ in order for this issue to be exploited. If a user was not connected, they would not be able to connect once their permissions were reduced.\n\n### Fix\nPlease upgrade to `wings@1.12.0` and `panel@1.12.0` to resolve this issue. Patches are available via the implementation PRs, but it is recommended to apply by upgrading the entire instance.",
  "id": "GHSA-8c39-xppg-479c",
  "modified": "2026-01-06T17:18:56Z",
  "published": "2026-01-06T17:18:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/panel/security/advisories/GHSA-8c39-xppg-479c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68954"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/panel/commit/2bd9d8baddb0e0606e4a9d5be402f48678ac88d5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pterodactyl/panel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pterodactyl/panel/releases/tag/v1.12.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Pterodactyl does not revoke SFTP access when server is deleted or permissions reduced"
}

GHSA-8CV6-H2PR-548G

Vulnerability from github – Published: 2024-03-06 18:30 – Updated: 2024-03-06 18:30
VLAI
Details

A vulnerability in Cisco Duo Authentication for Windows Logon and RDP could allow an authenticated, physical attacker to bypass secondary authentication and access an affected Windows device.

This vulnerability is due to a failure to invalidate locally created trusted sessions after a reboot of the affected device. An attacker with primary user credentials could exploit this vulnerability by attempting to authenticate to an affected device. A successful exploit could allow the attacker to access the affected device without valid permissions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-20301"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-06T17:15:08Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in Cisco Duo Authentication for Windows Logon and RDP could allow an authenticated, physical attacker to bypass secondary authentication and access an affected Windows device. \n\n This vulnerability is due to a failure to invalidate locally created trusted sessions after a reboot of the affected device. An attacker with primary user credentials could exploit this vulnerability by attempting to authenticate to an affected device. A successful exploit could allow the attacker to access the affected device without valid permissions.",
  "id": "GHSA-8cv6-h2pr-548g",
  "modified": "2024-03-06T18:30:37Z",
  "published": "2024-03-06T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20301"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-duo-win-bypass-pn42KKBm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8FF6-GRVW-RMVX

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

DomainMOD domainmod-v4.15.0 is affected by an insufficient session expiration vulnerability. On changing a password, both sessions using the changed password and old sessions in any other browser or device do not expire and remain active. Such flaws frequently give attackers unauthorized access to some system data or functionality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-35358"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-15T12:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "DomainMOD domainmod-v4.15.0 is affected by an insufficient session expiration vulnerability. On changing a password, both sessions using the changed password and old sessions in any other browser or device do not expire and remain active. Such flaws frequently give attackers unauthorized access to some system data or functionality.",
  "id": "GHSA-8ff6-grvw-rmvx",
  "modified": "2022-05-24T17:44:33Z",
  "published": "2022-05-24T17:44:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35358"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/anku-agar/0fec2ffd98308e550ce9b5d4b395d0d7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8FQ3-C5W3-PJ3Q

Vulnerability from github – Published: 2026-04-01 22:09 – Updated: 2026-04-27 16:27
VLAI
Summary
CI4MS: Account Deactivation Module Grants Full Persistent Unauthorized Access for All‑Roles via Improper Session Invalidation (Logic Flaw)
Details

Summary

Vulnerability: Improper Session Invalidation on Account Deactivation (Broken Access Control / Logic Flaw)

  • This vulnerability is caused by a backend logic flaw that maintains a false trust assumption that already-authenticated users remain trustworthy, even after their accounts are explicitly deactivated. As a result, administrative security actions do not behave as intended, allowing persistent unauthorized access.

Description

The application fails to immediately revoke active user sessions when an account is deactivated. Due to a logic flaw in the backend design, account state changes are enforced only during authentication (login), not for already-established sessions.

The system implicitly assumes that authenticated users remain trusted for the lifetime of their session. There is no session expiration or account expiration mechanism in place, causing deactivated accounts to retain indefinite access until the user manually logs out. This behavior breaks the intended access control policy and results in persistent unauthorized access, representing a critical security flaw.

Affected Functionality

  • User session management and authentication logic
  • Account deactivation mechanism
  • All authenticated endpoints, including administrative and content interfaces

Attack Scenario

  • A user logs into the application.
  • An administrator deactivates the user account.
  • The user remains fully logged in and can continue performing all actions allowed by their role indefinitely, as there is no session expiration.
  • The user can continue invoking backend methods, triggering application actions, accessing sensitive interfaces (including user management if permitted), and interacting with the system as if the account were still active.
  • Access is only lost if the user manually logs out, which may never occur.

Impact

  • Unauthorized Continued Access: Deactivated users retain full access indefinitely, violating intended access control and expected security behavior.
  • Bypass of Administrative Controls: Administrative actions (deactivation) fail to immediately restrict active sessions.
  • Logic Flaw Resulting in Broken Behavior: Backend authorization logic relies on a flawed trust assumption that authenticated users remain valid, enforcing account state only at login.
  • Full Functional Access Retained: Deactivated users can continue invoking application methods, executing actions, interacting with protected endpoints, and using the system exactly as before being deactivated.
  • Privilege Abuse: Users with elevated roles (moderator, editor, administrator) can continue performing privileged actions after account deactivation, including accessing user management interfaces and modifying application state.
  • Service Disruption Potential: Persistent access allows attackers to disrupt services, manipulate content, or interfere with normal application operations.
  • Attack Persistence: Attackers can maintain access indefinitely, increasing the risk of data exfiltration, unauthorized modifications, or further privilege escalation.
  • False Sense of Remediation: Administrators may believe a threat has been mitigated while the deactivated user remains active within the system.

Endpoint Example: Any endpoint accessible to authenticated users, including dashboards, administrative interfaces, user management pages, and API endpoints.

Steps To Reproduce (PoC)

  1. Create or use an existing user account.
  2. Log into the application using this account.
  3. From an administrative account, deactivate the logged-in user account.
  4. Observe that the target user remains authenticated.
  5. Verify that the user can still access protected functionality, invoke actions, and interact with the application as before.
  6. Confirm that the user only loses access after manually logging out (if they choose to do so).

Remediation

  • Immediately invalidate all active sessions when an account is deactivated.
  • Enforce account status checks on every authenticated request, not only during login.
  • Introduce proper session expiration or account expiration mechanisms to prevent indefinite access.
  • Correct the backend logic flaw to ensure access control behavior aligns with intended security design and does not rely on unsafe trust assumptions.

Ready Video POC:

https://mega.nz/file/zJkhwCII#G1-TecKmNBJmEeBS0ExsAY_RXEmAl3QqMqu4t5oy844

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.28.6.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "ci4-cms-erp/ci4ms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34572"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1254",
      "CWE-284",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T22:09:39Z",
    "nvd_published_at": "2026-04-01T22:16:21Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n### Vulnerability: Improper Session Invalidation on Account Deactivation (Broken Access Control / Logic Flaw)\n- This vulnerability is caused by a backend logic flaw that maintains a false trust assumption that already-authenticated users remain trustworthy, even after their accounts are explicitly deactivated. As a result, administrative security actions do not behave as intended, allowing persistent unauthorized access.\n\n### Description\nThe application fails to immediately revoke active user sessions when an account is deactivated. Due to a logic flaw in the backend design, account state changes are enforced only during authentication (login), not for already-established sessions.\n\nThe system implicitly assumes that authenticated users remain trusted for the lifetime of their session. There is no session expiration or account expiration mechanism in place, causing deactivated accounts to retain indefinite access until the user manually logs out. This behavior breaks the intended access control policy and results in persistent unauthorized access, representing a critical security flaw.\n\n### Affected Functionality\n- User session management and authentication logic\n- Account deactivation mechanism\n- All authenticated endpoints, including administrative and content interfaces\n\n### Attack Scenario\n- A user logs into the application.\n- An administrator deactivates the user account.\n- The user remains fully logged in and can continue performing all actions allowed by their role indefinitely, as there is no session expiration.\n- The user can continue invoking backend methods, triggering application actions, accessing sensitive interfaces (including user management if permitted), and interacting with the system as if the account were still active.\n- Access is only lost if the user manually logs out, which may never occur.\n\n### Impact\n- Unauthorized Continued Access: Deactivated users retain full access indefinitely, violating intended access control and expected security behavior.\n- Bypass of Administrative Controls: Administrative actions (deactivation) fail to immediately restrict active sessions.\n- Logic Flaw Resulting in Broken Behavior: Backend authorization logic relies on a flawed trust assumption that authenticated users remain valid, enforcing account state only at login.\n- Full Functional Access Retained: Deactivated users can continue invoking application methods, executing actions, interacting with protected endpoints, and using the system exactly as before being deactivated.\n- Privilege Abuse: Users with elevated roles (moderator, editor, administrator) can continue performing privileged actions after account deactivation, including accessing user management interfaces and modifying application state.\n- Service Disruption Potential: Persistent access allows attackers to disrupt services, manipulate content, or interfere with normal application operations.\n- Attack Persistence: Attackers can maintain access indefinitely, increasing the risk of data exfiltration, unauthorized modifications, or further privilege escalation.\n- False Sense of Remediation: Administrators may believe a threat has been mitigated while the deactivated user remains active within the system.\n\nEndpoint Example: Any endpoint accessible to authenticated users, including dashboards, administrative interfaces, user management pages, and API endpoints.\n\n## Steps To Reproduce (PoC)\n1. Create or use an existing user account.\n2. Log into the application using this account.\n3. From an administrative account, deactivate the logged-in user account.\n4. Observe that the target user remains authenticated.\n5. Verify that the user can still access protected functionality, invoke actions, and interact with the application as before.\n6. Confirm that the user only loses access after manually logging out (if they choose to do so).\n\n## Remediation\n- Immediately invalidate all active sessions when an account is deactivated.\n- Enforce account status checks on every authenticated request, not only during login.\n- Introduce proper session expiration or account expiration mechanisms to prevent indefinite access.\n- Correct the backend logic flaw to ensure access control behavior aligns with intended security design and does not rely on unsafe trust assumptions.\n\n# Ready Video POC:\nhttps://mega.nz/file/zJkhwCII#G1-TecKmNBJmEeBS0ExsAY_RXEmAl3QqMqu4t5oy844",
  "id": "GHSA-8fq3-c5w3-pj3q",
  "modified": "2026-04-27T16:27:49Z",
  "published": "2026-04-01T22:09:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/security/advisories/GHSA-8fq3-c5w3-pj3q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34572"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ci4-cms-erp/ci4ms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/releases/tag/0.31.0.0"
    }
  ],
  "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"
    }
  ],
  "summary": "CI4MS: Account Deactivation Module Grants Full Persistent Unauthorized Access for All\u2011Roles via Improper Session Invalidation (Logic Flaw)"
}

GHSA-8J24-697M-8W28

Vulnerability from github – Published: 2026-08-06 09:30 – Updated: 2026-08-06 09:30
VLAI
Details

The user impersonation flow in WSO2 Identity Server fails to properly manage refresh tokens associated with impersonated sessions. This allows an attacker who has obtained an access token for an impersonated user to leverage the refresh token grant to obtain new access tokens, extending their ability to act as the legitimate user.

An attacker who gains access to an impersonated user's access token can exploit this weakness to renew their authorization. This results in the continued ability to perform actions on behalf of the actual user, compromising log integrity and traceability by masking the true actor.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-12627"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-06T08:16:28Z",
    "severity": "LOW"
  },
  "details": "The user impersonation flow in WSO2 Identity Server fails to properly manage refresh tokens associated with impersonated sessions. This allows an attacker who has obtained an access token for an impersonated user to leverage the refresh token grant to obtain new access tokens, extending their ability to act as the legitimate user.\n\nAn attacker who gains access to an impersonated user\u0027s access token can exploit this weakness to renew their authorization. This results in the continued ability to perform actions on behalf of the actual user, compromising log integrity and traceability by masking the true actor.",
  "id": "GHSA-8j24-697m-8w28",
  "modified": "2026-08-06T09:30:30Z",
  "published": "2026-08-06T09:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12627"
    },
    {
      "type": "WEB",
      "url": "https://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2026/WSO2-2025-4619"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Implementation

Set sessions/credentials expiration date.

No CAPEC attack patterns related to this CWE.