CWE-384
AllowedSession Fixation
Abstraction: Compound · Status: Incomplete
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
547 vulnerabilities reference this CWE, most recent first.
GHSA-C9GC-5QRP-654Q
Vulnerability from github – Published: 2025-01-11 09:30 – Updated: 2025-01-11 09:30HCL MyXalytics is affected by a session fixation vulnerability. Cyber-criminals can exploit this by sending crafted URLs with a session token to access the victim's login session.
{
"affected": [],
"aliases": [
"CVE-2024-42171"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T07:15:08Z",
"severity": "MODERATE"
},
"details": "HCL MyXalytics is affected by a session fixation vulnerability. Cyber-criminals can exploit this by sending crafted URLs with a session token to access the victim\u0027s login session.",
"id": "GHSA-c9gc-5qrp-654q",
"modified": "2025-01-11T09:30:30Z",
"published": "2025-01-11T09:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42171"
},
{
"type": "WEB",
"url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0118149"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C9H6-V78W-52WJ
Vulnerability from github – Published: 2024-04-17 18:25 – Updated: 2025-03-14 20:25A flaw was found in Keycloak. An active keycloak session can be hijacked by initiating a new authentication (having the query parameter prompt=login) and forcing the user to enter his credentials once again. If the user cancels this re-authentication by clicking Restart login, the account takeover could take place as the new session, with a different SUB, will have the same SID as the previous session.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "22.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "23.0.0"
},
{
"fixed": "24.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-6787"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-384",
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-17T18:25:29Z",
"nvd_published_at": "2024-04-25T16:15:10Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Keycloak. An active keycloak session can be hijacked by initiating a new authentication (having the query parameter prompt=login) and forcing the user to enter his credentials once again. If the user cancels this re-authentication by clicking Restart login, the account takeover could take place as the new session, with a different SUB, will have the same SID as the previous session.",
"id": "GHSA-c9h6-v78w-52wj",
"modified": "2025-03-14T20:25:54Z",
"published": "2024-04-17T18:25:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-c9h6-v78w-52wj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6787"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:1867"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2024:1868"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-6787"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2254375"
},
{
"type": "PACKAGE",
"url": "https://github.com/keycloak/keycloak"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Keycloak vulnerable to session hijacking via re-authentication"
}
GHSA-CC78-5W3J-X6Q8
Vulnerability from github – Published: 2022-05-14 03:11 – Updated: 2022-05-14 03:11An issue was discovered on TP-Link TL-WR840N v5 00000005 0.9.1 3.16 v0001.0 Build 170608 Rel.58696n and TL-WR841N v13 00000013 0.9.1 4.16 v0001.0 Build 170622 Rel.64334n devices. This issue is caused by improper session handling on the /cgi/ folder or a /cgi file. If an attacker sends a header of "Referer: http://192.168.0.1/mainFrame.htm" then no authentication is required for any action.
{
"affected": [],
"aliases": [
"CVE-2018-11714"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-04T14:29:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered on TP-Link TL-WR840N v5 00000005 0.9.1 3.16 v0001.0 Build 170608 Rel.58696n and TL-WR841N v13 00000013 0.9.1 4.16 v0001.0 Build 170622 Rel.64334n devices. This issue is caused by improper session handling on the /cgi/ folder or a /cgi file. If an attacker sends a header of \"Referer: http://192.168.0.1/mainFrame.htm\" then no authentication is required for any action.",
"id": "GHSA-cc78-5w3j-x6q8",
"modified": "2022-05-14T03:11:43Z",
"published": "2022-05-14T03:11:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11714"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/44781"
},
{
"type": "WEB",
"url": "http://blog.securelayer7.net/time-to-disable-tp-link-home-wifi-router"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CC99-R8RX-5VCX
Vulnerability from github – Published: 2025-12-10 21:31 – Updated: 2025-12-17 21:30Screen SFT DAB 1.9.3 contains a weak session management vulnerability that allows attackers to bypass authentication controls by reusing IP address-bound session identifiers. Attackers can exploit the vulnerable API by intercepting and reusing established sessions to remove user accounts without proper authorization.
{
"affected": [],
"aliases": [
"CVE-2023-53741"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-10T21:16:03Z",
"severity": "HIGH"
},
"details": "Screen SFT DAB 1.9.3 contains a weak session management vulnerability that allows attackers to bypass authentication controls by reusing IP address-bound session identifiers. Attackers can exploit the vulnerable API by intercepting and reusing established sessions to remove user accounts without proper authorization.",
"id": "GHSA-cc99-r8rx-5vcx",
"modified": "2025-12-17T21:30:42Z",
"published": "2025-12-10T21:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53741"
},
{
"type": "WEB",
"url": "https://www.dbbroadcast.com"
},
{
"type": "WEB",
"url": "https://www.dbbroadcast.com/products/radio/sft-dab-series-compact-air"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/51457"
},
{
"type": "WEB",
"url": "https://www.screen.it"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/screen-sft-dab-authentication-bypass-via-ip-session-management"
},
{
"type": "WEB",
"url": "https://www.zeroscience.mk/en/vulnerabilities/ZSL-2023-5773.php"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/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-CFF8-X7JV-4FM8
Vulnerability from github – Published: 2024-09-10 19:43 – Updated: 2025-11-17 21:35Summary
Unauthenticated user can access credentials of last authenticated user via OpenID or OAuth2 where the authentication URL did not include redirect query string.
For example:
- Project is configured with OpenID or OAuth2
- Project is configured with cache enabled
- User tries to login via SSO link, but without redirect query string
- After successful login, credentials are cached
- If an unauthenticated user tries to login via SSO link, it will return the credentials of the other last user
The SSO link is something like https://directus.example.com/auth/login/openid/callback, where openid is the name of the OpenID provider configured in Directus
Details
This happens because on that endpoint for both OpenId and Oauth2 Directus is using the respond middleware, which by default will try to cache GET requests that met some conditions. Although, those conditions do not include this scenario, when an unauthenticated request returns user credentials.
For OpenID, this can be seen here:
https://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L453-L459
And for OAuth2 can be seen here
https://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L422-L428
PoC
- Create a new Directus project
- Set
CACHE_ENABLEDto true - Set
CACHE_STOREtoredisfor reliable results (if using memory with multiple nodes, it may only happen sometimes, due to cache being different for different nodes) - Configure
REDISwith redis string or redis host, port, user, etc. - Set
AUTH_PROVIDERStoopenid - Set
PUBLIC_URLto the the main URL of your project . For example,PUBLIC_URL: http://localhost:8055 - Configure
AUTH_OPENID_CLIENT_ID,AUTH_OPENID_CLIENT_SECRET,AUTH_OPENID_ISSUER_URLwith proper OpenID configurations - Be sure that on OpenID external app you have configured Redirect URI to
http://localhost:8055/auth/login/openid/callback - Run Directus
- Open the SSO link like
http://localhost:8055/auth/login/openid/callback - Do the authentication on the OpenID external webpage
- Verify that it you got redirected to a page with a JSON including
access_tokenproperty - Be sure all anonymous mode windows are closed
- Open an anonymous window and go to the SSO Link
http://localhost:8055/auth/login/openid/callbackand see you have the same credentials, even though you don't have any session because you are in anonymous mode
Impact
All projects using OpenID or OAuth 2, that does not include redirect query string on loggin in users.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "directus"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.13.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "directus"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-rc.1"
},
{
"fixed": "11.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@directus/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "21.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@directus/api"
},
"ranges": [
{
"events": [
{
"introduced": "22.0.0"
},
{
"fixed": "22.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-45596"
],
"database_specific": {
"cwe_ids": [
"CWE-384",
"CWE-524"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-10T19:43:00Z",
"nvd_published_at": "2024-09-10T19:15:22Z",
"severity": "HIGH"
},
"details": "### Summary\nUnauthenticated user can access credentials of last authenticated user via OpenID or OAuth2 where the authentication URL did not include `redirect` query string.\n\nFor example:\n- Project is configured with OpenID or OAuth2\n- Project is configured with cache enabled\n- User tries to login via SSO link, but without `redirect` query string\n- After successful login, credentials are cached\n- If an unauthenticated user tries to login via SSO link, it will return the credentials of the other last user\n\nThe SSO link is something like `https://directus.example.com/auth/login/openid/callback`, where `openid` is the name of the OpenID provider configured in Directus\n\n### Details\nThis happens because on that endpoint for both OpenId and Oauth2 Directus is using the `respond` middleware, which by default will try to cache GET requests that met some conditions. Although, those conditions do not include this scenario, when an unauthenticated request returns user credentials.\nFor OpenID, this can be seen here:\nhttps://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L453-L459\nAnd for OAuth2 can be seen here\nhttps://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L422-L428\n\n### PoC\n- Create a new Directus project\n- Set `CACHE_ENABLED` to true\n- Set `CACHE_STORE` to `redis` for reliable results (if using memory with multiple nodes, it may only happen sometimes, due to cache being different for different nodes)\n- Configure `REDIS` with redis string or redis host, port, user, etc.\n- Set `AUTH_PROVIDERS` to `openid`\n- Set `PUBLIC_URL` to the the main URL of your project . \tFor example, `PUBLIC_URL: http://localhost:8055`\n- Configure `AUTH_OPENID_CLIENT_ID`, `AUTH_OPENID_CLIENT_SECRET`, `AUTH_OPENID_ISSUER_URL` with proper OpenID configurations\n- Be sure that on OpenID external app you have configured Redirect URI to `http://localhost:8055/auth/login/openid/callback`\n- Run Directus\n- Open the SSO link like `http://localhost:8055/auth/login/openid/callback`\n- Do the authentication on the OpenID external webpage\n- Verify that it you got redirected to a page with a JSON including `access_token` property\n- Be sure all anonymous mode windows are closed\n- Open an anonymous window and go to the SSO Link `http://localhost:8055/auth/login/openid/callback` and see you have the same credentials, even though you don\u0027t have any session because you are in anonymous mode\n\n### Impact\nAll projects using OpenID or OAuth 2, that does not include `redirect` query string on loggin in users.",
"id": "GHSA-cff8-x7jv-4fm8",
"modified": "2025-11-17T21:35:30Z",
"published": "2024-09-10T19:43:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/directus/directus/security/advisories/GHSA-cff8-x7jv-4fm8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45596"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/commit/4aace0bbe57232e38cd6a287ee475293e46dc91b"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/commit/769fa22797bff5a9231599883b391e013f122e52"
},
{
"type": "PACKAGE",
"url": "https://github.com/directus/directus"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/blob/main/api/src/auth/drivers/oauth2.ts#L422-L428"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L453-L459"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Session is cached for OpenID and OAuth2 if `redirect` is not used"
}
GHSA-CFHV-H3JW-VX5R
Vulnerability from github – Published: 2024-11-12 21:30 – Updated: 2024-11-12 21:30A session fixation in Fortinet FortiOS version 7.4.0 through 7.4.3 and 7.2.0 through 7.2.7 and 7.0.0 through 7.0.13 allows attacker to execute unauthorized code or commands via phishing SAML authentication link.
{
"affected": [],
"aliases": [
"CVE-2023-50176"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-12T19:15:07Z",
"severity": "HIGH"
},
"details": "A session fixation in Fortinet FortiOS version 7.4.0 through 7.4.3 and 7.2.0 through 7.2.7 and 7.0.0 through 7.0.13 allows attacker to execute unauthorized code or commands via phishing SAML authentication link.",
"id": "GHSA-cfhv-h3jw-vx5r",
"modified": "2024-11-12T21:30:51Z",
"published": "2024-11-12T21:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50176"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-23-475"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CGVV-3455-824J
Vulnerability from github – Published: 2025-06-24 21:30 – Updated: 2025-06-26 14:12A session fixation vulnerability in Moodle 3.x through 3.11.18 allows unauthenticated attackers to hijack user sessions via the sesskey parameter. The sesskey can be obtained without authentication and reused within the OAuth2 login flow, resulting in the victim's session being linked to the attacker's. Successful exploitation results in full account takeover. According to the Moodle Releases page, "Bug fixes for security issues in 3.11.x ended 11 December 2023." NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.11.18"
},
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "4.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-53021"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-26T14:12:34Z",
"nvd_published_at": "2025-06-24T20:15:26Z",
"severity": "MODERATE"
},
"details": "A session fixation vulnerability in Moodle 3.x through 3.11.18 allows unauthenticated attackers to hijack user sessions via the sesskey parameter. The sesskey can be obtained without authentication and reused within the OAuth2 login flow, resulting in the victim\u0027s session being linked to the attacker\u0027s. Successful exploitation results in full account takeover. According to the Moodle Releases page, \"Bug fixes for security issues in 3.11.x ended 11 December 2023.\" NOTE: This vulnerability only affects products that are no longer supported by the maintainer.",
"id": "GHSA-cgvv-3455-824j",
"modified": "2025-06-26T14:12:34Z",
"published": "2025-06-24T21:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53021"
},
{
"type": "PACKAGE",
"url": "https://github.com/moodle/moodle"
},
{
"type": "WEB",
"url": "https://github.com/moodle/moodle/releases/tag/v3.11.18"
},
{
"type": "WEB",
"url": "https://moodledev.io/general/releases#moodle-311"
},
{
"type": "WEB",
"url": "https://rentry.co/moodle-oauth2-cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Moodle Session Fixation allows unauthenticated users to hijack sessions via sesskey parameter"
}
GHSA-CH28-MJGC-M4WR
Vulnerability from github – Published: 2026-06-22 15:30 – Updated: 2026-06-26 21:32The Azure Active Directory (AAD) authentication implementation contained multiple weaknesses in its OAuth 2.0 authorization flow that could allow attackers to bypass important security guarantees provided by the protocol.
The application used the PHP session identifier (session_id()) as the OAuth state parameter. Because session identifiers are long-lived authentication credentials, exposing them in OAuth redirect URLs could leak valid session tokens through browser history, HTTP Referer headers, reverse proxies, access logs, or third-party infrastructure involved in the authentication flow. If obtained by an attacker, the leaked session identifier could potentially be used for session hijacking.
Additionally, the implementation did not regenerate the session identifier after successful authentication, leaving authenticated sessions susceptible to session fixation attacks where an attacker forces a victim to use a known session identifier before login and later reuses that identifier after authentication.
The OAuth state value was also not implemented as a dedicated, single-use nonce. This weakened CSRF protections and increased the risk of replay attacks against the OAuth callback process.
The authentication flow further failed to enforce HTTPS for the configured OAuth redirect URI. If a non-HTTPS redirect URI was used, OAuth authorization codes and access tokens could traverse the network in plaintext, exposing sensitive credentials to network attackers.
Finally, OAuth error responses containing attacker-controlled GET parameters were logged verbatim. An attacker could inject control characters or crafted log content, leading to log forging, log injection, or corruption of audit records.
The fix introduces:
-
A dedicated cryptographically random OAuth state value.
-
Single-use state validation and invalidation.
-
Constant-time state comparison using hash_equals().
-
Session identifier rotation after successful authentication.
-
Enforcement of HTTPS-only redirect URIs.
-
Sanitized and length-limited logging of OAuth error parameters.
AAD Authentication Plugin (OAuth 2.0 / Azure Active Directory integration)
{
"affected": [],
"aliases": [
"CVE-2026-56425"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-22T14:17:50Z",
"severity": "CRITICAL"
},
"details": "The Azure Active Directory (AAD) authentication implementation contained multiple weaknesses in its OAuth 2.0 authorization flow that could allow attackers to bypass important security guarantees provided by the protocol.\n\n\nThe application used the PHP session identifier (session_id()) as the OAuth state parameter. Because session identifiers are long-lived authentication credentials, exposing them in OAuth redirect URLs could leak valid session tokens through browser history, HTTP Referer headers, reverse proxies, access logs, or third-party infrastructure involved in the authentication flow. If obtained by an attacker, the leaked session identifier could potentially be used for session hijacking.\n\n\nAdditionally, the implementation did not regenerate the session identifier after successful authentication, leaving authenticated sessions susceptible to session fixation attacks where an attacker forces a victim to use a known session identifier before login and later reuses that identifier after authentication.\n\n\nThe OAuth state value was also not implemented as a dedicated, single-use nonce. This weakened CSRF protections and increased the risk of replay attacks against the OAuth callback process.\n\n\nThe authentication flow further failed to enforce HTTPS for the configured OAuth redirect URI. If a non-HTTPS redirect URI was used, OAuth authorization codes and access tokens could traverse the network in plaintext, exposing sensitive credentials to network attackers.\n\n\nFinally, OAuth error responses containing attacker-controlled GET parameters were logged verbatim. An attacker could inject control characters or crafted log content, leading to log forging, log injection, or corruption of audit records.\n\n\nThe fix introduces:\n\n\n\n * \nA dedicated cryptographically random OAuth state value.\n\n\n * \nSingle-use state validation and invalidation.\n\n\n * \nConstant-time state comparison using hash_equals().\n\n\n * \nSession identifier rotation after successful authentication.\n\n\n * \nEnforcement of HTTPS-only redirect URIs.\n\n\n * \nSanitized and length-limited logging of OAuth error parameters.\n\n\nAAD Authentication Plugin (OAuth 2.0 / Azure Active Directory integration)",
"id": "GHSA-ch28-mjgc-m4wr",
"modified": "2026-06-26T21:32:05Z",
"published": "2026-06-22T15:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56425"
},
{
"type": "WEB",
"url": "https://github.com/MISP/MISP/commit/146bc40ad6e10a44f01e8ed62d5f7bc9c06cc4fa"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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-CHG2-RQMJ-8F6X
Vulnerability from github – Published: 2022-10-11 12:00 – Updated: 2025-12-09 18:30A vulnerability has been identified in SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P850 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10), SICAM P855 (All versions < V3.10). Affected devices accept user defined session cookies and do not renew the session cookie after login/logout. This could allow an attacker to take over another user's session after login.
{
"affected": [],
"aliases": [
"CVE-2022-40226"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-11T11:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P850 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10), SICAM P855 (All versions \u003c V3.10). Affected devices accept user defined session cookies and do not renew the session cookie after login/logout. This could allow an attacker to take over another user\u0027s session after login.",
"id": "GHSA-chg2-rqmj-8f6x",
"modified": "2025-12-09T18:30:27Z",
"published": "2022-10-11T12:00:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40226"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-471761.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-572005.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-572005.pdf"
}
],
"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-CHMW-MGXC-GVFX
Vulnerability from github – Published: 2022-05-24 17:43 – Updated: 2022-05-24 17:43Micro Focus Solutions Business Manager Application Repository versions prior to 11.7.1 are vulnerable to session fixation.
{
"affected": [],
"aliases": [
"CVE-2019-18946"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-26T04:15:00Z",
"severity": "MODERATE"
},
"details": "Micro Focus Solutions Business Manager Application Repository versions prior to 11.7.1 are vulnerable to session fixation.",
"id": "GHSA-chmw-mgxc-gvfx",
"modified": "2022-05-24T17:43:08Z",
"published": "2022-05-24T17:43:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-18946"
},
{
"type": "WEB",
"url": "http://knowledgebase.serena.com/resources/sites/KNOWLEDGEBASE/content/live/SOLUTIONS/142000/S142001/en_US/sbm_11.7.1_security_bulletin.htm"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Invalidate any existing session identifiers prior to authorizing a new user session.
Mitigation
For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again.
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
CAPEC-196: Session Credential Falsification through Forging
An attacker creates a false but functional session credential in order to gain or usurp access to a service. Session credentials allow users to identify themselves to a service after an initial authentication without needing to resend the authentication information (usually a username and password) with every message. If an attacker is able to forge valid session credentials they may be able to bypass authentication or piggy-back off some other authenticated user's session. This attack differs from Reuse of Session IDs and Session Sidejacking attacks in that in the latter attacks an attacker uses a previous or existing credential without modification while, in a forging attack, the attacker must create their own credential, although it may be based on previously observed credentials.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies
This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the adversary to impersonate the remote user/session. The third form is when the cookie's content is modified by the adversary before it is sent back to the server. Here the adversary seeks to convince the target server to operate on this falsified information.
CAPEC-39: Manipulating Opaque Client-based Data Tokens
In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-61: Session Fixation
The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation.