Common Weakness Enumeration

CWE-384

Allowed

Session 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:30
VLAI
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's login session.

Show details on source website

{
  "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:25
VLAI
Summary
Keycloak vulnerable to session hijacking via re-authentication
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.

Show details on source website

{
  "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:11
VLAI
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.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:35
VLAI
Summary
Session is cached for OpenID and OAuth2 if `redirect` is not used
Details

Summary

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_ENABLED to true
  • 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)
  • Configure REDIS with redis string or redis host, port, user, etc.
  • Set AUTH_PROVIDERS to openid
  • Set PUBLIC_URL to 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_URL with 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_token property
  • Be sure all anonymous mode windows are closed
  • 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'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.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:12
VLAI
Summary
Moodle Session Fixation allows unauthenticated users to hijack sessions via sesskey parameter
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'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.

Show details on source website

{
  "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:32
VLAI
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.

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)

Show details on source website

{
  "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:30
VLAI
Details

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

Show details on source website

{
  "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:43
VLAI
Details

Micro Focus Solutions Business Manager Application Repository versions prior to 11.7.1 are vulnerable to session fixation.

Show details on source website

{
  "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
Architecture and Design

Invalidate any existing session identifiers prior to authorizing a new user session.

Mitigation
Architecture and Design

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
Operation

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.