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.
560 vulnerabilities reference this CWE, most recent first.
GHSA-CX9H-WV2X-V9RG
Vulnerability from github – Published: 2023-10-16 18:30 – Updated: 2024-04-04 08:41A session fixation vulnerability in South River Technologies' Titan MFT and Titan SFTP servers on Linux and Windows allows an attacker to bypass the server's authentication if they can trick an administrator into authorizating a session id of their choosing
{
"affected": [],
"aliases": [
"CVE-2023-45687"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-16T17:15:10Z",
"severity": "HIGH"
},
"details": "A session fixation vulnerability in South River Technologies\u0027 Titan MFT and Titan SFTP servers on Linux and Windows allows an attacker to bypass the server\u0027s authentication if they can trick an administrator into authorizating a session id of their choosing",
"id": "GHSA-cx9h-wv2x-v9rg",
"modified": "2024-04-04T08:41:03Z",
"published": "2023-10-16T18:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45687"
},
{
"type": "WEB",
"url": "https://helpdesk.southrivertech.com/portal/en/kb/articles/security-patch-for-issues-cve-2023-45685-through-cve-2023-45690"
},
{
"type": "WEB",
"url": "https://www.rapid7.com/blog/post/2023/10/16/multiple-vulnerabilities-in-south-river-technologies-titan-mft-and-titan-sftp-fixed"
}
],
"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"
}
]
}
GHSA-F24X-5G9Q-753F
Vulnerability from github – Published: 2026-04-14 22:31 – Updated: 2026-04-15 21:06Impact
A regression introduced in v7.11.0 is preventing OAuth2 Proxy from clearing the session cookie when rendering the sign-in page.
This only impacts deployments that rely on the sign-in page as part of their logout flow. In those setups, a user may be shown the sign-in page while the existing session cookie remains valid, so the browser session is not actually logged out. On shared workstations be it browsers or devices, a subsequent user could continue to use the previous user's authenticated session.
Deployments that use a dedicated logout/sign-out endpoint to terminate sessions are not affected.
Patches
This issue is fixed in v7.15.2.
Workarounds
Do not rely on the sign-in page to clear an existing session. Instead:
- Use the dedicated logout/sign-out endpoint of OAuth2 Proxy
- Ensure your application logout flow explicitly clears the OAuth2 Proxy session cookie before redirecting users to the sign-in page
- If needed, clear the session cookie at the reverse proxy or application layer as a temporary mitigation
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/oauth2-proxy/oauth2-proxy/v7"
},
"ranges": [
{
"events": [
{
"introduced": "7.11.0"
},
{
"fixed": "7.15.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34454"
],
"database_specific": {
"cwe_ids": [
"CWE-384",
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T22:31:03Z",
"nvd_published_at": "2026-04-14T23:16:28Z",
"severity": "LOW"
},
"details": "### Impact\nA regression introduced in [v7.11.0](https://github.com/oauth2-proxy/oauth2-proxy/pull/2605) is preventing OAuth2 Proxy from clearing the session cookie when rendering the sign-in page.\n\nThis only impacts deployments that rely on the sign-in page as part of their logout flow. In those setups, a user may be shown the sign-in page while the existing session cookie remains valid, so the browser session is not actually logged out. On shared workstations be it browsers or devices, a subsequent user could continue to use the previous user\u0027s authenticated session.\n\nDeployments that use a dedicated logout/sign-out endpoint to terminate sessions are not affected.\n\n### Patches\nThis issue is fixed in v7.15.2.\n\n### Workarounds\nDo not rely on the sign-in page to clear an existing session. Instead:\n\n- Use the dedicated logout/sign-out endpoint of OAuth2 Proxy\n- Ensure your application logout flow explicitly clears the OAuth2 Proxy session cookie before redirecting users to the sign-in page\n- If needed, clear the session cookie at the reverse proxy or application layer as a temporary mitigation",
"id": "GHSA-f24x-5g9q-753f",
"modified": "2026-04-15T21:06:34Z",
"published": "2026-04-14T22:31:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-f24x-5g9q-753f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34454"
},
{
"type": "WEB",
"url": "https://github.com/oauth2-proxy/oauth2-proxy/pull/2605"
},
{
"type": "PACKAGE",
"url": "https://github.com/oauth2-proxy/oauth2-proxy"
},
{
"type": "WEB",
"url": "https://github.com/oauth2-proxy/oauth2-proxy/releases/tag/v7.15.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "OAuth2 Proxy\u0027s session cookies are not cleared when rendering sign-in page"
}
GHSA-F38M-5F6J-RH34
Vulnerability from github – Published: 2022-07-07 00:00 – Updated: 2022-07-15 00:00Session fixation vulnerability in access control management in Synology Photo Station before 6.8.16-3506 allows remote attackers to bypass security constraint via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2022-22681"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-06T08:15:00Z",
"severity": "HIGH"
},
"details": "Session fixation vulnerability in access control management in Synology Photo Station before 6.8.16-3506 allows remote attackers to bypass security constraint via unspecified vectors.",
"id": "GHSA-f38m-5f6j-rh34",
"modified": "2022-07-15T00:00:15Z",
"published": "2022-07-07T00:00:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22681"
},
{
"type": "WEB",
"url": "https://www.synology.com/security/advisory/Synology_SA_21_26"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F4CW-P89C-V458
Vulnerability from github – Published: 2025-04-28 21:30 – Updated: 2025-04-29 15:31A critical vulnerability was found in PHPGurukul User Registration & Login and User Management System V3.3 in the /loginsystem/change-password.php file of the user panel - Change Password component. Improper handling of session data allows a Session Hijacking attack, exploitable remotely and leading to account takeover.
{
"affected": [],
"aliases": [
"CVE-2025-45949"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-28T20:15:21Z",
"severity": "CRITICAL"
},
"details": "A critical vulnerability was found in PHPGurukul User Registration \u0026 Login and User Management System V3.3 in the /loginsystem/change-password.php file of the user panel - Change Password component. Improper handling of session data allows a Session Hijacking attack, exploitable remotely and leading to account takeover.",
"id": "GHSA-f4cw-p89c-v458",
"modified": "2025-04-29T15:31:49Z",
"published": "2025-04-28T21:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-45949"
},
{
"type": "WEB",
"url": "https://github.com/VasilVK/CVE/blob/main/CVE-2025-45949/README.MD"
},
{
"type": "WEB",
"url": "http://phpgurukul.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F593-4HHX-9HC7
Vulnerability from github – Published: 2022-05-17 02:14 – Updated: 2022-05-17 02:14IBM AppScan Enterprise Edition 9.0 contains an unspecified vulnerability that could allow an attacker to hijack a valid user's session. IBM X-Force ID: 120257
{
"affected": [],
"aliases": [
"CVE-2016-9981"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-02T17:29:00Z",
"severity": "HIGH"
},
"details": "IBM AppScan Enterprise Edition 9.0 contains an unspecified vulnerability that could allow an attacker to hijack a valid user\u0027s session. IBM X-Force ID: 120257",
"id": "GHSA-f593-4hhx-9hc7",
"modified": "2022-05-17T02:14:02Z",
"published": "2022-05-17T02:14:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9981"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/120257"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=swg22006430"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1039073"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F5MR-3XX6-6379
Vulnerability from github – Published: 2022-11-17 03:30 – Updated: 2022-11-21 18:30An issue was discovered in BACKCLICK Professional 5.9.63. Due to an unsafe implementation of session tracking, it is possible for an attacker to trick users into opening an authenticated user session for a session identifier known to the attacker, aka Session Fixation.
{
"affected": [],
"aliases": [
"CVE-2022-44007"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-16T22:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in BACKCLICK Professional 5.9.63. Due to an unsafe implementation of session tracking, it is possible for an attacker to trick users into opening an authenticated user session for a session identifier known to the attacker, aka Session Fixation.",
"id": "GHSA-f5mr-3xx6-6379",
"modified": "2022-11-21T18:30:36Z",
"published": "2022-11-17T03:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44007"
},
{
"type": "WEB",
"url": "https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2022-036.txt"
},
{
"type": "WEB",
"url": "https://www.syss.de/pentest-blog/vielfaeltige-schwachstellen-in-backclick-professional-syss-2022-026-bis-037"
}
],
"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"
}
]
}
GHSA-F5RX-9G37-6P6R
Vulnerability from github – Published: 2022-05-14 01:42 – Updated: 2022-05-14 01:42For some Iomega, Lenovo, LenovoEMC NAS devices versions 4.1.402.34662 and earlier, the password changing functionality available to authenticated users does not require the user's current password to set a new one. As a result, attackers with access to the user's session tokens can change their password and retain access to the user's account
{
"affected": [],
"aliases": [
"CVE-2018-9082"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-28T20:29:00Z",
"severity": "HIGH"
},
"details": "For some Iomega, Lenovo, LenovoEMC NAS devices versions 4.1.402.34662 and earlier, the password changing functionality available to authenticated users does not require the user\u0027s current password to set a new one. As a result, attackers with access to the user\u0027s session tokens can change their password and retain access to the user\u0027s account",
"id": "GHSA-f5rx-9g37-6p6r",
"modified": "2022-05-14T01:42:48Z",
"published": "2022-05-14T01:42:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9082"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/us/en/solutions/LEN-24224"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F6R9-68XJ-457V
Vulnerability from github – Published: 2025-02-20 12:31 – Updated: 2025-02-20 12:31IBM OpenPages with Watson 8.3 and 9.0 IBM OpenPages
with Watson Assistant chat feature enabled the application establishes a session when a user logs in and uses chat, but the chat session is still left active after logout.
{
"affected": [],
"aliases": [
"CVE-2024-49344"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-20T12:15:10Z",
"severity": "MODERATE"
},
"details": "IBM OpenPages with Watson 8.3 and 9.0 IBM OpenPages \n\n\n\nwith Watson Assistant chat feature enabled the application establishes a session when a user logs in and uses chat, but the chat session is still left active after logout.",
"id": "GHSA-f6r9-68xj-457v",
"modified": "2025-02-20T12:31:15Z",
"published": "2025-02-20T12:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49344"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7183541"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F7VP-7XGX-4W4R
Vulnerability from github – Published: 2026-08-03 21:05 – Updated: 2026-08-03 21:05Impact
SetCookie::matchesDomain() gives every subdomain of a cookie Domain that cookie unless it recognizes the Domain as an IP literal or a numeric host, and it decides that from the domain's own text, so two spellings a transport reads as an address keep subdomain scope. On 7.15, hexadecimal and mixed-base forms such as 0x7f000001 and 0177.0.0.0x1 go unrecognized while libcurl 8.21.0 reads both as 127.0.0.1, so closing them completes the rule GHSA-g446-98w2-8p5w (CVE-2026-59883) set out to establish, which cited the WHATWG IPv4 parser and so already admitted a 0x part. A percent-escaped Domain keeps that scope on both branches for a different reason: percent-decoding sits above numeric parsing, so 192.168.0.%31 and 127.0.0.1%2e are registered names in the URI grammar rather than address literals, and no numeric rule in any base classifies them, while libcurl decodes the host before it resolves and reads them as 192.168.0.1 and 127.0.0.1. The escape must fall in the rightmost label on 8.0.0, which already catches a decimal, octal or 0x part there, but not on 7.15, where %31%32%37.0.0.0x1 also reads as 127.0.0.1; 8.0.0 is affected in the percent spelling alone.
Both directions of the defect are reproduced over a real socket. A cookie stored for Domain=0x7f000001 is placed in the Cookie header of a request to evil.0x7f000001, disclosing a session identifier or token to a host that is not that address, and a response from evil.0x7f000001 setting Domain=0x7f000001 is accepted into the jar and replayed to the address, so a server answering for the look-alike name can fix a session or set application state.
Exploitation requires the application to enable cookie support, address an origin by one of these spellings, and contact a host whose name ends in it. No public DNS delegation provides such a name, so the exposure is to private, split-horizon and container zones. Applications that do not use Guzzle's cookies, that keep a separate jar for each host or trust boundary, or that address origins only by ordinary names are not affected.
Patches
This is a summary; the patches are the authority. The issue is fixed in 7.15.2 and 8.0.1, which hold a cookie Domain containing a % byte to an exact match against the request host. 7.15.2 additionally holds to an exact match a Domain whose every dot-separated part is decimal, octal or hexadecimal, a rule wide enough that 0x100000000, a name to libcurl, loses subdomain matching too; 8.0.0 already recognizes a 0x-prefixed rightmost label. One class stays open: an IDN-capable transport reads a fullwidth-digit Domain such as 127.0.0.1 as 127.0.0.1 while Guzzle matches it by suffix, and these patches do not close that. Versions before 7.15.2 and version 8.0.0 are affected, 8.0.0 in the percent spelling alone.
Workarounds
If you cannot upgrade, do not share one CookieJar between an origin addressed by a numeric or percent-escaped spelling and any other host ending in that spelling. Use a separate jar for each host or trust boundary, or address such an origin by its canonical dotted-decimal form, writing 127.0.0.1, which released versions already hold to an exact match, rather than 0x7f000001 or 127.0.0.%31. Rejecting a request URI host that contains a percent escape, before you hand the URI to Guzzle and on every redirect hop, closes that spelling, and rejecting a non-ASCII byte closes the fullwidth one, but nothing outside the jar closes the hexadecimal one.
Do not use filter_var() with FILTER_VALIDATE_IP to decide whether a domain is an address: it rejects 0x7f000001 and 127.0.0.%31, which a transport reads as 127.0.0.1.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "guzzlehttp/guzzle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.15.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "guzzlehttp/guzzle"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-69245"
],
"database_specific": {
"cwe_ids": [
"CWE-180",
"CWE-346",
"CWE-384"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-03T21:05:26Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\n`SetCookie::matchesDomain()` gives every subdomain of a cookie `Domain` that cookie unless it recognizes the `Domain` as an IP literal or a numeric host, and it decides that from the domain\u0027s own text, so two spellings a transport reads as an address keep subdomain scope. On `7.15`, hexadecimal and mixed-base forms such as `0x7f000001` and `0177.0.0.0x1` go unrecognized while libcurl 8.21.0 reads both as `127.0.0.1`, so closing them completes the rule `GHSA-g446-98w2-8p5w` (`CVE-2026-59883`) set out to establish, which cited the WHATWG IPv4 parser and so already admitted a `0x` part. A percent-escaped `Domain` keeps that scope on both branches for a different reason: percent-decoding sits above numeric parsing, so `192.168.0.%31` and `127.0.0.1%2e` are registered names in the URI grammar rather than address literals, and no numeric rule in any base classifies them, while libcurl decodes the host before it resolves and reads them as `192.168.0.1` and `127.0.0.1`. The escape must fall in the rightmost label on `8.0.0`, which already catches a decimal, octal or `0x` part there, but not on `7.15`, where `%31%32%37.0.0.0x1` also reads as `127.0.0.1`; `8.0.0` is affected in the percent spelling alone.\n\nBoth directions of the defect are reproduced over a real socket. A cookie stored for `Domain=0x7f000001` is placed in the `Cookie` header of a request to `evil.0x7f000001`, disclosing a session identifier or token to a host that is not that address, and a response from `evil.0x7f000001` setting `Domain=0x7f000001` is accepted into the jar and replayed to the address, so a server answering for the look-alike name can fix a session or set application state.\n\nExploitation requires the application to enable cookie support, address an origin by one of these spellings, and contact a host whose name ends in it. No public DNS delegation provides such a name, so the exposure is to private, split-horizon and container zones. Applications that do not use Guzzle\u0027s cookies, that keep a separate jar for each host or trust boundary, or that address origins only by ordinary names are not affected.\n\n### Patches\n\nThis is a summary; the patches are the authority. The issue is fixed in `7.15.2` and `8.0.1`, which hold a cookie `Domain` containing a `%` byte to an exact match against the request host. `7.15.2` additionally holds to an exact match a `Domain` whose every dot-separated part is decimal, octal or hexadecimal, a rule wide enough that `0x100000000`, a name to libcurl, loses subdomain matching too; `8.0.0` already recognizes a `0x`-prefixed rightmost label. One class stays open: an IDN-capable transport reads a fullwidth-digit `Domain` such as `127.0.0.\uff11` as `127.0.0.1` while Guzzle matches it by suffix, and these patches do not close that. Versions before `7.15.2` and version `8.0.0` are affected, `8.0.0` in the percent spelling alone.\n\n### Workarounds\n\nIf you cannot upgrade, do not share one `CookieJar` between an origin addressed by a numeric or percent-escaped spelling and any other host ending in that spelling. Use a separate jar for each host or trust boundary, or address such an origin by its canonical dotted-decimal form, writing `127.0.0.1`, which released versions already hold to an exact match, rather than `0x7f000001` or `127.0.0.%31`. Rejecting a request URI host that contains a percent escape, before you hand the URI to Guzzle and on every redirect hop, closes that spelling, and rejecting a non-ASCII byte closes the fullwidth one, but nothing outside the jar closes the hexadecimal one.\n\nDo not use `filter_var()` with `FILTER_VALIDATE_IP` to decide whether a domain is an address: it rejects `0x7f000001` and `127.0.0.%31`, which a transport reads as `127.0.0.1`.",
"id": "GHSA-f7vp-7xgx-4w4r",
"modified": "2026-08-03T21:05:26Z",
"published": "2026-08-03T21:05:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/security/advisories/GHSA-f7vp-7xgx-4w4r"
},
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/pull/3907"
},
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/pull/3908"
},
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/commit/3aeea0406aab88cbbd86531313d7cebf8ae149a4"
},
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/commit/744101956d78b7c1384d0cbf379db13e859167bf"
},
{
"type": "PACKAGE",
"url": "https://github.com/guzzle/guzzle"
},
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/releases/tag/7.15.2"
},
{
"type": "WEB",
"url": "https://github.com/guzzle/guzzle/releases/tag/8.0.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Guzzle: Noncanonical cookie domain keeps subdomain scope"
}
GHSA-F976-24HC-MJVR
Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-01-27 01:02Jenkins OpenID Plugin 2.4 and earlier does not invalidate the previous session on login.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:openid"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-24444"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-27T01:02:10Z",
"nvd_published_at": "2023-01-26T21:18:00Z",
"severity": "HIGH"
},
"details": "Jenkins OpenID Plugin 2.4 and earlier does not invalidate the previous session on login.",
"id": "GHSA-f976-24hc-mjvr",
"modified": "2023-01-27T01:02:10Z",
"published": "2023-01-26T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24444"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-01-24/#SECURITY-2996"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Session fixation vulnerability in Jenkins OpenID Plugin "
}
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.