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-7RG2-QXMF-HHX9
Vulnerability from github – Published: 2021-12-09 19:08 – Updated: 2021-12-15 15:28Overview
Versions 2.3.0 up to and including 2.5.1 do not regenerate the session id and session cookie when user logs in. This behavior opens up the application to various session fixation vulnerabilities.
Am I affected?
You are affected by this vulnerability if you are using express-openid-connect version 2.3.0 up to and including 2.5.1 and use a custom session store.
How to fix that?
Upgrade to version >= 2.5.2.
Will this update impact my users?
The fix provided in patch will not affect your users.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "express-openid-connect"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-41246"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": true,
"github_reviewed_at": "2021-12-09T18:09:56Z",
"nvd_published_at": "2021-12-09T16:15:00Z",
"severity": "MODERATE"
},
"details": "### Overview\n\nVersions `2.3.0` up to and including `2.5.1` do not regenerate the session id and session cookie when user logs in. This behavior opens up the application to various session fixation vulnerabilities.\n\n### Am I affected?\nYou are affected by this vulnerability if you are using `express-openid-connect` version `2.3.0` up to and including `2.5.1` and use a custom session store.\n\n\n### How to fix that?\nUpgrade to version `\u003e= 2.5.2`.\n\n### Will this update impact my users?\nThe fix provided in patch will not affect your users.",
"id": "GHSA-7rg2-qxmf-hhx9",
"modified": "2021-12-15T15:28:49Z",
"published": "2021-12-09T19:08:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/auth0/express-openid-connect/security/advisories/GHSA-7rg2-qxmf-hhx9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41246"
},
{
"type": "WEB",
"url": "https://github.com/auth0/express-openid-connect/commit/5ab67ff2bd84f76674066b5e129b43ab5f2f430f"
},
{
"type": "PACKAGE",
"url": "https://github.com/auth0/express-openid-connect"
},
{
"type": "WEB",
"url": "https://github.com/auth0/express-openid-connect/releases/tag/v2.5.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Session fixation in express-openid-connect"
}
GHSA-7VJJ-GWC4-WGQ7
Vulnerability from github – Published: 2026-06-30 15:30 – Updated: 2026-06-30 15:30KTM System e-BOK allows the session identifier to be set by the client prior to authentication. If a cookie with a valid name is set, its value remains unchanged after successful login. This behaviour enables an attacker to fix a session ID for a victim and later hijack the authenticated session.
This issue was fixed in the patch published in June 2026.
{
"affected": [],
"aliases": [
"CVE-2026-35095"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T14:16:26Z",
"severity": "MODERATE"
},
"details": "KTM System e-BOK allows the session identifier to be set by the client prior to authentication. If a cookie with a valid name is set, its value remains unchanged after successful login. This behaviour enables an attacker to fix a session ID for a victim and later hijack the authenticated session.\n\nThis issue was fixed in the patch published in June 2026.",
"id": "GHSA-7vjj-gwc4-wgq7",
"modified": "2026-06-30T15:30:46Z",
"published": "2026-06-30T15:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35095"
},
{
"type": "WEB",
"url": "https://cert.pl/posts/2026/06/CVE-2026-35095"
},
{
"type": "WEB",
"url": "https://ktmsystem.pl/internetowe-biuro-obslugi-klienta"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-7VRP-GJ62-X2FF
Vulnerability from github – Published: 2022-05-14 03:15 – Updated: 2022-05-14 03:15Monstra CMS 3.0.4 has a Session Management Issue in the Users tab. A password change at users/1/edit does not invalidate a session that is open in a different browser.
{
"affected": [],
"aliases": [
"CVE-2018-11475"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-05-25T19:29:00Z",
"severity": "HIGH"
},
"details": "Monstra CMS 3.0.4 has a Session Management Issue in the Users tab. A password change at users/1/edit does not invalidate a session that is open in a different browser.",
"id": "GHSA-7vrp-gj62-x2ff",
"modified": "2022-05-14T03:15:56Z",
"published": "2022-05-14T03:15:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11475"
},
{
"type": "WEB",
"url": "https://github.com/monstra-cms/monstra/issues/443"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7XMM-C892-6JF8
Vulnerability from github – Published: 2026-01-28 21:31 – Updated: 2026-01-29 21:30A session fixation vulnerability exists in 66biolinks v62.0.0 by AltumCode, where the application does not regenerate the session identifier after successful authentication. As a result, the same session cookie value is reused for users logging in from the same browser, allowing an attacker who can set or predict a session ID to potentially hijack an authenticated session.
{
"affected": [],
"aliases": [
"CVE-2025-69602"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-28T19:16:24Z",
"severity": "CRITICAL"
},
"details": "A session fixation vulnerability exists in 66biolinks v62.0.0 by AltumCode, where the application does not regenerate the session identifier after successful authentication. As a result, the same session cookie value is reused for users logging in from the same browser, allowing an attacker who can set or predict a session ID to potentially hijack an authenticated session.",
"id": "GHSA-7xmm-c892-6jf8",
"modified": "2026-01-29T21:30:30Z",
"published": "2026-01-28T21:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69602"
},
{
"type": "WEB",
"url": "https://gist.github.com/Waqar-Arain/c8117308325a91b8f3b7829646915275"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-7XWP-2CPP-P8R7
Vulnerability from github – Published: 2025-07-16 14:09 – Updated: 2025-07-29 23:17Summary
File Browser’s authentication system issues long-lived JWT tokens that remain valid even after the user logs out. Please refer to the CWE's listed in this report for further reference and system standards. In summary, the main issue is:
- Tokens remain valid after logout (session replay attacks)
In this report, I used docker as the documentation instruct:
docker run \
-v filebrowser_data:/srv \
-v filebrowser_database:/database \
-v filebrowser_config:/config \
-p 8080:80 \
filebrowser/filebrowser
Details
Issue: Tokens remain valid after logout (session replay attacks)
After logging in and receiving a JWT token, the user can explicitly "log out." However, this action does not invalidate the issued JWT. Any captured token can be replayed post-logout until it expires naturally. The backend does not track active sessions or invalidate existing tokens on logout. Login request:
POST /api/login HTTP/1.1
Host: machine.local:8090
Content-Length: 69
{"username":"admin","password":"password-here","recaptcha":""}
The check found in the code https://github.com/filebrowser/filebrowser/blob/master/http/auth.go is not enough. There is no server-side blacklist or token invalidation on logout. Token renewal and validity only depends on expiry and user store timestamps:
expired := !tk.VerifyExpiresAt(time.Now().Add(time.Hour), true)
updated := tk.IssuedAt != nil && tk.IssuedAt.Unix() < d.store.Users.LastUpdate(tk.User.ID)
PoC
Issue: Tokens remain valid after logout (session replay attacks)
- Login and capture the generate JWT. Eg. the http request:
POST /api/login HTTP/1.1
Host: machine.local:8090
Content-Length: 69
{"username":"admin","password":"password-here","recaptcha":""}
- Logout in the dashboard. And then try to use the old generated JWT to access any authenticated endpoint eg:
GET /api/resources HTTP/1.1
Host: machine.local:8090
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
X-Auth: Old-JWT-token-here
Content-Length: 173
Accept: */*
Referer: http://machine.local:8090/files/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Content-Length: 26
Connection: keep-alive
Impact
- A valid JWT remains active after user logout.
- If stolen, tokens persist access indefinitely until expiry.
- Violates OWASP Top 10 A2:2021 - Broken Authentication.
Recommendations
- Read all CWE's attached in this report
- Invalidate JWTs on logout via session store / token blacklist.
- Reduce JWT ExpiresAt where possible or use short-lived + refresh tokens.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.39.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.39.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-53826"
],
"database_specific": {
"cwe_ids": [
"CWE-305",
"CWE-384",
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-16T14:09:28Z",
"nvd_published_at": "2025-07-15T18:15:24Z",
"severity": "HIGH"
},
"details": "### Summary\n\nFile Browser\u2019s authentication system issues long-lived JWT tokens that remain valid even after the user logs out. Please refer to the CWE\u0027s listed in this report for further reference and system standards. In summary, the main issue is:\n\n- Tokens remain valid after logout (session replay attacks)\n\nIn this report, I used docker as the documentation instruct:\n\n```\ndocker run \\\n -v filebrowser_data:/srv \\\n -v filebrowser_database:/database \\\n -v filebrowser_config:/config \\\n -p 8080:80 \\\n filebrowser/filebrowser\n```\n\n### Details\n\n**Issue: Tokens remain valid after logout (session replay attacks)**\n\nAfter logging in and receiving a JWT token, the user can explicitly \"log out.\" However, this action does not invalidate the issued JWT. Any captured token can be replayed post-logout until it expires naturally. The backend does not track active sessions or invalidate existing tokens on logout. Login request:\n\n```\nPOST /api/login HTTP/1.1\nHost: machine.local:8090\nContent-Length: 69\n\n{\"username\":\"admin\",\"password\":\"password-here\",\"recaptcha\":\"\"}\n```\n\nThe check found in the code `https://github.com/filebrowser/filebrowser/blob/master/http/auth.go` is not enough. There is no server-side blacklist or token invalidation on logout. Token renewal and validity only depends on expiry and user store timestamps:\n\n```\nexpired := !tk.VerifyExpiresAt(time.Now().Add(time.Hour), true)\nupdated := tk.IssuedAt != nil \u0026\u0026 tk.IssuedAt.Unix() \u003c d.store.Users.LastUpdate(tk.User.ID)\n```\n\n### PoC\n\n**Issue: Tokens remain valid after logout (session replay attacks)**\n\n- Login and capture the generate JWT. Eg. the http request:\n\n```\nPOST /api/login HTTP/1.1\nHost: machine.local:8090\nContent-Length: 69\n\n{\"username\":\"admin\",\"password\":\"password-here\",\"recaptcha\":\"\"}\n```\n\n- Logout in the dashboard. And then try to use the old generated JWT to access any authenticated endpoint eg:\n\n```\nGET /api/resources HTTP/1.1\nHost: machine.local:8090\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36\nX-Auth: Old-JWT-token-here\nContent-Length: 173\nAccept: */*\nReferer: http://machine.local:8090/files/\nAccept-Encoding: gzip, deflate, br\nAccept-Language: en-US,en;q=0.9\nContent-Length: 26\n\nConnection: keep-alive\n```\n\n### Impact\n\n- A valid JWT remains active after user logout.\n- If stolen, tokens persist access indefinitely until expiry.\n- Violates OWASP Top 10 A2:2021 - Broken Authentication.\n\n### Recommendations\n\n- Read all CWE\u0027s attached in this report\n- Invalidate JWTs on logout via session store / token blacklist.\n- Reduce JWT ExpiresAt where possible or use short-lived + refresh tokens.",
"id": "GHSA-7xwp-2cpp-p8r7",
"modified": "2025-07-29T23:17:56Z",
"published": "2025-07-16T14:09:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-7xwp-2cpp-p8r7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53826"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/issues/5216"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "File Browser\u2019s insecure JWT handling can lead to session replay attacks after logout"
}
GHSA-823Q-MRWW-7V59
Vulnerability from github – Published: 2022-05-14 01:36 – Updated: 2022-05-14 01:36Session fixation exists in ZoneMinder through 1.32.3, as an attacker can fixate his own session cookies to the next logged-in user, thereby hijacking the victim's account. This occurs because a set of multiple cookies (between 3 and 5) is being generated when a user successfully logs in, and these sets overlap for successive logins.
{
"affected": [],
"aliases": [
"CVE-2019-7350"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-04T19:29:00Z",
"severity": "HIGH"
},
"details": "Session fixation exists in ZoneMinder through 1.32.3, as an attacker can fixate his own session cookies to the next logged-in user, thereby hijacking the victim\u0027s account. This occurs because a set of multiple cookies (between 3 and 5) is being generated when a user successfully logs in, and these sets overlap for successive logins.",
"id": "GHSA-823q-mrww-7v59",
"modified": "2022-05-14T01:36:34Z",
"published": "2022-05-14T01:36:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7350"
},
{
"type": "WEB",
"url": "https://github.com/ZoneMinder/zoneminder/issues/2471"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8345-V559-5VW2
Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2022-05-24 16:58A session fixation vulnerability in J-Web on Junos OS may allow an attacker to use social engineering techniques to fix and hijack a J-Web administrators web session and potentially gain administrative access to the device. This issue affects: Juniper Networks Junos OS 12.3 versions prior to 12.3R12-S15 on EX Series; 12.3X48 versions prior to 12.3X48-D85 on SRX Series; 14.1X53 versions prior to 14.1X53-D51; 15.1 versions prior to 15.1F6-S13, 15.1R7-S5; 15.1X49 versions prior to 15.1X49-D180 on SRX Series; 15.1X53 versions prior to 15.1X53-D238; 16.1 versions prior to 16.1R4-S13, 16.1R7-S5; 16.2 versions prior to 16.2R2-S10; 17.1 versions prior to 17.1R3-S1; 17.2 versions prior to 17.2R2-S8, 17.2R3-S3; 17.3 versions prior to 17.3R3-S5; 17.4 versions prior to 17.4R2-S8, 17.4R3; 18.1 versions prior to 18.1R3-S8; 18.2 versions prior to 18.2R3; 18.3 versions prior to 18.3R3; 18.4 versions prior to 18.4R2; 19.1 versions prior to 19.1R1-S2, 19.1R2.
{
"affected": [],
"aliases": [
"CVE-2019-0062"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-09T20:15:00Z",
"severity": "MODERATE"
},
"details": "A session fixation vulnerability in J-Web on Junos OS may allow an attacker to use social engineering techniques to fix and hijack a J-Web administrators web session and potentially gain administrative access to the device. This issue affects: Juniper Networks Junos OS 12.3 versions prior to 12.3R12-S15 on EX Series; 12.3X48 versions prior to 12.3X48-D85 on SRX Series; 14.1X53 versions prior to 14.1X53-D51; 15.1 versions prior to 15.1F6-S13, 15.1R7-S5; 15.1X49 versions prior to 15.1X49-D180 on SRX Series; 15.1X53 versions prior to 15.1X53-D238; 16.1 versions prior to 16.1R4-S13, 16.1R7-S5; 16.2 versions prior to 16.2R2-S10; 17.1 versions prior to 17.1R3-S1; 17.2 versions prior to 17.2R2-S8, 17.2R3-S3; 17.3 versions prior to 17.3R3-S5; 17.4 versions prior to 17.4R2-S8, 17.4R3; 18.1 versions prior to 18.1R3-S8; 18.2 versions prior to 18.2R3; 18.3 versions prior to 18.3R3; 18.4 versions prior to 18.4R2; 19.1 versions prior to 19.1R1-S2, 19.1R2.",
"id": "GHSA-8345-v559-5vw2",
"modified": "2022-05-24T16:58:12Z",
"published": "2022-05-24T16:58:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0062"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA10961"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-87P9-X75H-P4J2
Vulnerability from github – Published: 2024-06-06 21:27 – Updated: 2024-06-17 15:26Summary
The CVE allows unauthorized access to the sensitive settings exposed by /api/v1/settings endpoint without authentication.
Details
Unauthenticated Access:
Endpoint: /api/v1/settings
Description: This endpoint is accessible without any form of authentication as expected. All sensitive settings are hidden except passwordPattern.
Patches A patch for this vulnerability has been released in the following Argo CD versions:
v2.11.3 v2.10.12 v2.9.17
Impact
Unauthenticated Access:
- Type: Unauthorized Information Disclosure.
- Affected Parties: All users and administrators of the Argo CD instance.
- Potential Risks: Exposure of sensitive configuration data, including but not limited to deployment settings, security configurations, and internal network information.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v2/server"
},
"ranges": [
{
"events": [
{
"introduced": "2.9.3"
},
{
"fixed": "2.9.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v2/server"
},
"ranges": [
{
"events": [
{
"introduced": "2.10.0"
},
{
"fixed": "2.10.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-cd/v2/server"
},
"ranges": [
{
"events": [
{
"introduced": "2.11.0"
},
{
"fixed": "2.11.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-37152"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-287",
"CWE-306",
"CWE-384"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-06T21:27:43Z",
"nvd_published_at": "2024-06-06T16:15:13Z",
"severity": "MODERATE"
},
"details": "# Summary\nThe CVE allows unauthorized access to the sensitive settings exposed by /api/v1/settings endpoint without authentication. \n\n# Details\n## **Unauthenticated Access:**\n\n### Endpoint: /api/v1/settings\nDescription: This endpoint is accessible without any form of authentication as expected. All sensitive settings are hidden except `passwordPattern`. \n\nPatches\nA patch for this vulnerability has been released in the following Argo CD versions:\n\nv2.11.3\nv2.10.12\nv2.9.17\n\n\n# Impact\n## Unauthenticated Access:\n\n* Type: Unauthorized Information Disclosure.\n* Affected Parties: All users and administrators of the Argo CD instance.\n* Potential Risks: Exposure of sensitive configuration data, including but not limited to deployment settings, security configurations, and internal network information.\n\n",
"id": "GHSA-87p9-x75h-p4j2",
"modified": "2024-06-17T15:26:55Z",
"published": "2024-06-06T21:27:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-87p9-x75h-p4j2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37152"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-cd/commit/256d90178b11b04bc8174d08d7b663a2a7b1771b"
},
{
"type": "PACKAGE",
"url": "https://github.com/argoproj/argo-cd"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2024-2902"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Unauthenticated Access to sensitive settings in Argo CD"
}
GHSA-887X-J4CF-3PQH
Vulnerability from github – Published: 2022-05-24 17:16 – Updated: 2024-04-04 02:50Initially, a user opens a Private Browsing Window and generates a password for a site, then closes the Private Browsing Window but leaves Firefox open. Subsequently, if the user had opened a new Private Browsing Window, revisited the same site, and generated a new password - the generated passwords would have been identical, rather than independent. This vulnerability affects Firefox < 75.
{
"affected": [],
"aliases": [
"CVE-2020-6824"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-24T16:15:00Z",
"severity": "LOW"
},
"details": "Initially, a user opens a Private Browsing Window and generates a password for a site, then closes the Private Browsing Window but leaves Firefox open. Subsequently, if the user had opened a new Private Browsing Window, revisited the same site, and generated a new password - the generated passwords would have been identical, rather than independent. This vulnerability affects Firefox \u003c 75.",
"id": "GHSA-887x-j4cf-3pqh",
"modified": "2024-04-04T02:50:12Z",
"published": "2022-05-24T17:16:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6824"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1621853"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2020-12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-88J4-PCX8-Q4Q3
Vulnerability from github – Published: 2023-12-12 00:59 – Updated: 2023-12-12 00:59Overview:
A moderate security vulnerability has been identified in Uptime Kuma platform that poses a significant threat to the confidentiality and integrity of user accounts.
When a user changes their login password in Uptime Kuma, a previously logged-in user retains access without being logged out.
This behaviour persists consistently, even after system restarts or browser restarts.
This vulnerability allows unauthorized access to user accounts, compromising the security of sensitive information.
The same vulnerability was partially fixed in https://github.com/louislam/uptime-kuma/security/advisories/GHSA-g9v2-wqcj-j99g but logging existing users out of their accounts was forgotten.
Impact:
The impact of this vulnerability is moderate, as it enables attackers or unauthorized individuals to maintain access to user accounts even after the account password has been changed. This can lead to unauthorized data access, manipulation, or compromise of user accounts, posing a threat to the integrity and confidentiality of Uptime Kuma. A better impact-analysis is included in https://github.com/louislam/uptime-kuma/security/advisories/GHSA-g9v2-wqcj-j99g
PoC
- Change the password for a user account
- Access the platform using the previously logged-in account without logging out
- Note that access (read-write) remains despite the password change
- Expected behaviour:
After changing the password for a user account, all previously logged-in sessions should be invalidated, requiring users to log in again with the updated credentials. - Actual behaviour:
The system retains sessions and never logs out users unless explicitly done by clicking logout.
Remediation:
To mitigate the risks associated with this vulnerability, we made the server emit a refresh event (clients handle this by reloading) and then disconnecting all clients except the one initiating the password change.
It is recommended to Update Uptime Kuma to >= 1.23.9.
Timeline:
| Date | Event |
|---|---|
| 2023-12-07 14:35 UTC | @manoonabbasi discovered and posts this information as a bug-report in issue #4188 [^1] into our public issue tracker, which is against our security policy |
| 2023-12-07 16:50 UTC | The Uptime Kuma team deleted the post in our issue tracker |
| 2023-12-10 18:10 UTC | Uptime Kuma team released patch and this Advisory |
[^1]: deleted to prevent the spread of this vulnerability without there being a fix available
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "uptime-kuma"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.23.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-49804"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": true,
"github_reviewed_at": "2023-12-12T00:59:30Z",
"nvd_published_at": "2023-12-11T23:15:07Z",
"severity": "MODERATE"
},
"details": "## Overview:\n\nA moderate security vulnerability has been identified in Uptime Kuma platform that poses a significant threat to the confidentiality and integrity of user accounts. \nWhen a user changes their login password in Uptime Kuma, a previously logged-in user retains access without being logged out.\nThis behaviour persists consistently, even after system restarts or browser restarts.\nThis vulnerability allows unauthorized access to user accounts, compromising the security of sensitive information.\n\nThe same vulnerability was partially fixed in https://github.com/louislam/uptime-kuma/security/advisories/GHSA-g9v2-wqcj-j99g but logging existing users out of their accounts was forgotten.\n\n## Impact:\n\nThe impact of this vulnerability is moderate, as it enables attackers or unauthorized individuals to maintain access to user accounts even after the account password has been changed. This can lead to unauthorized data access, manipulation, or compromise of user accounts, posing a threat to the integrity and confidentiality of Uptime Kuma.\nA better impact-analysis is included in https://github.com/louislam/uptime-kuma/security/advisories/GHSA-g9v2-wqcj-j99g\n\n## PoC\n\n- Change the password for a user account\n- Access the platform using the previously logged-in account without logging out\n- Note that access (read-write) remains despite the password change \n- Expected behaviour: \n After changing the password for a user account, all previously logged-in sessions should be invalidated, requiring users to log in again with the updated credentials.\n- Actual behaviour: \n The system retains sessions and never logs out users unless explicitly done by clicking logout.\n\n## Remediation:\n\nTo mitigate the risks associated with this vulnerability, we made the server emit a `refresh` event (clients handle this by reloading) and then disconnecting all clients except the one initiating the password change.\n\nIt is recommended to Update Uptime Kuma to `\u003e= 1.23.9`. \n\n## Timeline:\n\n|Date|Event|\n|--|--|\n|2023-12-07 14:35 UTC| @manoonabbasi discovered and posts this information as a `bug`-report in issue #4188 [^1] into our **public issue tracker**, which is [**against our security policy**](https://github.com/louislam/uptime-kuma/security/policy) |\n| 2023-12-07 16:50 UTC | The Uptime Kuma team deleted the post in our issue tracker |\n| 2023-12-10 18:10 UTC | Uptime Kuma team released patch and this Advisory |\n\n[^1]: deleted to prevent the spread of this vulnerability without there being a fix available",
"id": "GHSA-88j4-pcx8-q4q3",
"modified": "2023-12-12T00:59:30Z",
"published": "2023-12-12T00:59:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/louislam/uptime-kuma/security/advisories/GHSA-88j4-pcx8-q4q3"
},
{
"type": "WEB",
"url": "https://github.com/louislam/uptime-kuma/security/advisories/GHSA-g9v2-wqcj-j99g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49804"
},
{
"type": "WEB",
"url": "https://github.com/louislam/uptime-kuma/commit/482049c72b3a650c7bc5c26c2f4d57a21c0e0aa0"
},
{
"type": "PACKAGE",
"url": "https://github.com/louislam/uptime-kuma"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Password Change Vulnerability"
}
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.