{"id":"CVE-2023-44400","aliases":["EUVD-2023-2738","GHSA-g9v2-wqcj-j99g"],"status":"published","title":"Uptime Kuma has Persistentent User Sessions","description":"Uptime Kuma is a self-hosted monitoring tool. Prior to version 1.23.3, attackers with access to a user's device can gain persistent account access. This is caused by missing verification of Session Tokens after password changes and/or elapsed inactivity periods. Version 1.23.3 has a patch for the issue.","severity":{"version":"3.1","score":6.7,"vector":"CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00282,"percentile":0.2097,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-384"],"published":"2023-10-09T15:15:07Z","modified":"2026-10-28T02:30:47Z","fixes":[{"ecosystem":"npm","package":"uptime-kuma","fixed_in":["1.23.3"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"uptime-kuma","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.23.3"}]}]},{"source":"osv","ecosystem":"npm","package":"uptime-kuma","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.23.3"}]}]}],"products":[{"vendor":"louislam","product":"uptime-kuma"},{"vendor":"uptime.kuma","product":"uptime_kuma"}],"references":[{"url":"https://github.com/louislam/uptime-kuma/security/advisories/GHSA-g9v2-wqcj-j99g","tags":["x_refsource_CONFIRM","x_transferred","Exploit","Vendor Advisory","advisory","web"]},{"url":"https://github.com/louislam/uptime-kuma/issues/3481","tags":["x_refsource_MISC","x_transferred","Issue Tracking","Mitigation","report","web"]},{"url":"https://github.com/louislam/uptime-kuma/commit/88afab6571ef7d4d41bb395cdb6ecd3968835a4a","tags":["x_refsource_MISC","x_transferred","Patch","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-44400","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-g9v2-wqcj-j99g"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2023/44xxx/CVE-2023-44400.json","tags":["advisory"]},{"url":"https://github.com/louislam/uptime-kuma","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2023-44400","title":"Uptime Kuma has Persistentent User Sessions ","description":"Uptime Kuma is a self-hosted monitoring tool. Prior to version 1.23.3, attackers with access to a user's device can gain persistent account access. This is caused by missing verification of Session Tokens after password changes and/or elapsed inactivity periods. Version 1.23.3 has a patch for the issue.","status":"published","published":"2023-10-09T15:15:07.45Z","modified":"2024-09-18T20:18:45.881Z","cvss":[{"version":"3.1","score":6.7,"vector":"CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H","level":"medium","assessor":"cna"}],"cwes":["CWE-384"],"updated_at":"2026-11-02T14:35:21.232549Z"}],"euvd":[{"id":"EUVD-2023-2738","description":"Uptime Kuma is a self-hosted monitoring tool. Prior to version 1.23.3, attackers with access to a user's device can gain persistent account access. This is caused by missing verification of Session Tokens after password changes and/or elapsed inactivity periods. Version 1.23.3 has a patch for the issue.","status":"published","published":"2023-10-09T15:15:07Z","modified":"2024-09-18T20:18:45Z","cvss":[{"version":"3.1","score":6.7,"vector":"CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H","level":"medium"}],"updated_at":"2026-11-03T00:28:19.564867Z"}],"ghsa":[{"id":"GHSA-g9v2-wqcj-j99g","title":"Uptime Kuma has Persistentent User Sessions","description":"# Summary\n\nAttackers with access to a users' device can gain persistent account access.\nThis is caused by missing verification of Session Tokens after password changes and/or elapsed inactivity-periods.\n\n# Details\n\n`uptime-kuma` sets JWT tokens for users after successful authentication.\n\nThese tokens have the following design flaws:\n- After successful login, a JWT token and it is stored in `sessionStorage` or `localStorage`. \n  Which of the two is decided based on the `Remember Me` button. \n  The users' token is valid without any time limitation, even after long periods of inactivity. \n  This increases the risk of session hijacking if, for example, a user forgets to log off and leaves the PC.\n- sessions are only deleted on the client side after a user loggs out, meaning a local attacker could reuse said token with deep system access over the browser\n- If a user changes a password\n  - any previously logged in clients are not logged out\n  - previously issued tokens remained valid forever\n\nThese flaws allow user cookies to remain valid even after changing passwords or being inactive, posing a high security risk.\n\n# POC\n### Password resets not deactivating cookies\n- Log in.\n- Note the user cookie.\n- Change your password.\n- Attempt to log in again with the same cookie.\n- The cookie remains valid despite the password change.\n\n### Inactivity not deactivating sessions\n In testing, even after a period of over a day of inactivity, the session was still valid\n\n# Impact\n\nAnother person with local access to the device could take over the session permanently, even after hours of previous inactivity or a password change.\nSuch activity would not be obvious to the user (see https://github.com/louislam/uptime-kuma/issues/3481 if you want to help with this).\n\nWith this gained account access, an attacker can cause:\n\n## confidentially loss\n- monitors (including private ones not shared on public status pages)\n- notification providers \n- settings like `api-keys` (only used for accessing `/metrics`)\n- settings like secrets like the `Steam API Key`\n- maintenance periods\n\n## availability loss \n\n- by creating a lot of monitors and setting the retention policy very high leading to degraded database performance or out of storage\n- by creating a lot of `HTTP(s) - Browser Engine (Chrome/Chromium) (Beta)` leading to RAM exhaustion\n\n## integrity loss\n- by the attacker deleting a monitor\n- by the attacker deleting a monitor's history\n- by the atacker changing the meaning of a monitor (changing where it points)\n\n## scope creep\nIf operated in some restricted network, access to monitors may provide the ability to change the scope of the attack to a different piece of infrastructure, for example via SQL commands to a database server.\nWe have not classified this as `changed scope` because credentials stored in the application for accessing other systems are existing valid paths across the trust boundary, and the user should be aware of that.","status":"published","published":"2023-10-10T21:29:23Z","modified":"2023-11-08T05:05:04Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-384"],"updated_at":"2026-11-02T14:37:16.721714Z"}],"nvd":[{"id":"CVE-2023-44400","description":"Uptime Kuma is a self-hosted monitoring tool. Prior to version 1.23.3, attackers with access to a user's device can gain persistent account access. This is caused by missing verification of Session Tokens after password changes and/or elapsed inactivity periods. Version 1.23.3 has a patch for the issue.","status":"published","published":"2023-10-09T16:15:10.567Z","modified":"2026-06-17T06:27:34.31Z","cvss":[{"version":"3.1","score":6.7,"vector":"CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H","level":"medium","assessor":"secondary"},{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-384"],"updated_at":"2026-11-02T14:08:36.656095Z"}],"osv":[{"id":"CVE-2023-44400","title":"Uptime Kuma has Persistentent User Sessions ","description":"Uptime Kuma is a self-hosted monitoring tool. Prior to version 1.23.3, attackers with access to a user's device can gain persistent account access. This is caused by missing verification of Session Tokens after password changes and/or elapsed inactivity periods. Version 1.23.3 has a patch for the issue.","status":"published","published":"2023-10-09T15:15:07.45Z","modified":"2026-10-28T02:30:47.620231177Z","cvss":[{"version":"3.1","score":6.7,"vector":"CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H","level":"medium"}],"cwes":["CWE-384"],"updated_at":"2026-11-02T15:44:33.792101Z"},{"id":"GHSA-g9v2-wqcj-j99g","title":"Uptime Kuma has Persistentent User Sessions","description":"# Summary\n\nAttackers with access to a users' device can gain persistent account access.\nThis is caused by missing verification of Session Tokens after password changes and/or elapsed inactivity-periods.\n\n# Details\n\n`uptime-kuma` sets JWT tokens for users after successful authentication.\n\nThese tokens have the following design flaws:\n- After successful login, a JWT token and it is stored in `sessionStorage` or `localStorage`. \n  Which of the two is decided based on the `Remember Me` button. \n  The users' token is valid without any time limitation, even after long periods of inactivity. \n  This increases the risk of session hijacking if, for example, a user forgets to log off and leaves the PC.\n- sessions are only deleted on the client side after a user loggs out, meaning a local attacker could reuse said token with deep system access over the browser\n- If a user changes a password\n  - any previously logged in clients are not logged out\n  - previously issued tokens remained valid forever\n\nThese flaws allow user cookies to remain valid even after changing passwords or being inactive, posing a high security risk.\n\n# POC\n### Password resets not deactivating cookies\n- Log in.\n- Note the user cookie.\n- Change your password.\n- Attempt to log in again with the same cookie.\n- The cookie remains valid despite the password change.\n\n### Inactivity not deactivating sessions\n In testing, even after a period of over a day of inactivity, the session was still valid\n\n# Impact\n\nAnother person with local access to the device could take over the session permanently, even after hours of previous inactivity or a password change.\nSuch activity would not be obvious to the user (see https://github.com/louislam/uptime-kuma/issues/3481 if you want to help with this).\n\nWith this gained account access, an attacker can cause:\n\n## confidentially loss\n- monitors (including private ones not shared on public status pages)\n- notification providers \n- settings like `api-keys` (only used for accessing `/metrics`)\n- settings like secrets like the `Steam API Key`\n- maintenance periods\n\n## availability loss \n\n- by creating a lot of monitors and setting the retention policy very high leading to degraded database performance or out of storage\n- by creating a lot of `HTTP(s) - Browser Engine (Chrome/Chromium) (Beta)` leading to RAM exhaustion\n\n## integrity loss\n- by the attacker deleting a monitor\n- by the attacker deleting a monitor's history\n- by the atacker changing the meaning of a monitor (changing where it points)\n\n## scope creep\nIf operated in some restricted network, access to monitors may provide the ability to change the scope of the attack to a different piece of infrastructure, for example via SQL commands to a database server.\nWe have not classified this as `changed scope` because credentials stored in the application for accessing other systems are existing valid paths across the trust boundary, and the user should be aware of that.","status":"published","published":"2023-10-10T21:29:23Z","modified":"2026-02-04T03:43:57.78829Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-384"],"updated_at":"2026-11-02T15:46:47.472172Z"}]}}