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-G8VQ-9QGG-P683
Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43Honeywell NVR devices allow remote attackers to create a user account in the admin group by leveraging access to a guest account to obtain a session ID, and then sending that session ID in a userManager.addUser request to the /RPC2 URI. The attacker can login to the device with that new user account to fully control the device.
{
"affected": [],
"aliases": [
"CVE-2017-14263"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-09-11T09:29:00Z",
"severity": "HIGH"
},
"details": "Honeywell NVR devices allow remote attackers to create a user account in the admin group by leveraging access to a guest account to obtain a session ID, and then sending that session ID in a userManager.addUser request to the /RPC2 URI. The attacker can login to the device with that new user account to fully control the device.",
"id": "GHSA-g8vq-9qgg-p683",
"modified": "2022-05-13T01:43:21Z",
"published": "2022-05-13T01:43:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14263"
},
{
"type": "WEB",
"url": "https://github.com/zzz66686/Honeywell_NVR_vul"
}
],
"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-G9MM-555G-3956
Vulnerability from github – Published: 2022-05-13 01:32 – Updated: 2022-05-13 01:32Navarino Infinity is prone to session fixation attacks. The server accepts the session ID as a GET parameter which can lead to bypassing the two factor authentication in some installations. This could lead to phishing attacks that can bypass the two factor authentication that is present in some installations.
{
"affected": [],
"aliases": [
"CVE-2018-5385"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-24T15:29:00Z",
"severity": "HIGH"
},
"details": "Navarino Infinity is prone to session fixation attacks. The server accepts the session ID as a GET parameter which can lead to bypassing the two factor authentication in some installations. This could lead to phishing attacks that can bypass the two factor authentication that is present in some installations.",
"id": "GHSA-g9mm-555g-3956",
"modified": "2022-05-13T01:32:12Z",
"published": "2022-05-13T01:32:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5385"
},
{
"type": "WEB",
"url": "https://medium.com/@evstykas/pwning-ships-vsat-for-fun-and-profit-ba0fe9f42fb3"
},
{
"type": "WEB",
"url": "https://packetstormsecurity.com/files/146506/Navarino-Infinity-Blind-SQL-Injection-Session-Fixation.html"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/184077"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/103544"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G9V2-WQCJ-J99G
Vulnerability from github – Published: 2023-10-10 21:29 – Updated: 2023-10-13 22:04Summary
Attackers with access to a users' device can gain persistent account access. This is caused by missing verification of Session Tokens after password changes and/or elapsed inactivity-periods.
Details
uptime-kuma sets JWT tokens for users after successful authentication.
These tokens have the following design flaws:
- After successful login, a JWT token and it is stored in sessionStorage or localStorage.
Which of the two is decided based on the Remember Me button.
The users' token is valid without any time limitation, even after long periods of inactivity.
This increases the risk of session hijacking if, for example, a user forgets to log off and leaves the PC.
- 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
- If a user changes a password
- any previously logged in clients are not logged out
- previously issued tokens remained valid forever
These flaws allow user cookies to remain valid even after changing passwords or being inactive, posing a high security risk.
POC
Password resets not deactivating cookies
- Log in.
- Note the user cookie.
- Change your password.
- Attempt to log in again with the same cookie.
- The cookie remains valid despite the password change.
Inactivity not deactivating sessions
In testing, even after a period of over a day of inactivity, the session was still valid
Impact
Another person with local access to the device could take over the session permanently, even after hours of previous inactivity or a password change. Such activity would not be obvious to the user (see https://github.com/louislam/uptime-kuma/issues/3481 if you want to help with this).
With this gained account access, an attacker can cause:
confidentially loss
- monitors (including private ones not shared on public status pages)
- notification providers
- settings like
api-keys(only used for accessing/metrics) - settings like secrets like the
Steam API Key - maintenance periods
availability loss
- by creating a lot of monitors and setting the retention policy very high leading to degraded database performance or out of storage
- by creating a lot of
HTTP(s) - Browser Engine (Chrome/Chromium) (Beta)leading to RAM exhaustion
integrity loss
- by the attacker deleting a monitor
- by the attacker deleting a monitor's history
- by the atacker changing the meaning of a monitor (changing where it points)
scope creep
If 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.
We 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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "uptime-kuma"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.23.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-44400"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-10T21:29:23Z",
"nvd_published_at": "2023-10-09T16:15:10Z",
"severity": "HIGH"
},
"details": "# Summary\n\nAttackers with access to a users\u0027 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\u0027 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\u0027s 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.",
"id": "GHSA-g9v2-wqcj-j99g",
"modified": "2023-10-13T22:04:34Z",
"published": "2023-10-10T21:29:23Z",
"references": [
{
"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-44400"
},
{
"type": "WEB",
"url": "https://github.com/louislam/uptime-kuma/issues/3481"
},
{
"type": "WEB",
"url": "https://github.com/louislam/uptime-kuma/commit/88afab6571ef7d4d41bb395cdb6ecd3968835a4a"
},
{
"type": "PACKAGE",
"url": "https://github.com/louislam/uptime-kuma"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Uptime Kuma has Persistentent User Sessions"
}
GHSA-GGV4-GH8G-HP7P
Vulnerability from github – Published: 2022-08-11 00:00 – Updated: 2022-08-14 00:00Dell Wyse Management Suite 3.6.1 and below contains a Session Fixation vulnerability. A unauthenticated attacker could exploit this by taking advantage of a user with multiple active sessions in order to hijack a user's session.
{
"affected": [],
"aliases": [
"CVE-2022-33927"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-10T17:15:00Z",
"severity": "MODERATE"
},
"details": "Dell Wyse Management Suite 3.6.1 and below contains a Session Fixation vulnerability. A unauthenticated attacker could exploit this by taking advantage of a user with multiple active sessions in order to hijack a user\u0027s session.",
"id": "GHSA-ggv4-gh8g-hp7p",
"modified": "2022-08-14T00:00:23Z",
"published": "2022-08-11T00:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33927"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000201383/dsa-2022-134-dell-wyse-management-suite-security-update-for-multiple-vulnerabilities"
}
],
"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"
}
]
}
GHSA-GH6X-HCRX-8H8G
Vulnerability from github – Published: 2026-06-04 18:30 – Updated: 2026-06-04 18:30Improper Authentication (Authentication Bypass) exists in Neterbit NW-431F Router 20241014-IR03 and before. The router uses a weak/predictable cookie value for authentication. By modifying the cookie value (e.g., setting it to "admin"), an attacker can bypass the authentication schema and gain unauthorized access to admin functionalities.
{
"affected": [],
"aliases": [
"CVE-2025-67446"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-04T17:16:30Z",
"severity": "CRITICAL"
},
"details": "Improper Authentication (Authentication Bypass) exists in Neterbit NW-431F Router 20241014-IR03 and before. The router uses a weak/predictable cookie value for authentication. By modifying the cookie value (e.g., setting it to \"admin\"), an attacker can bypass the authentication schema and gain unauthorized access to admin functionalities.",
"id": "GHSA-gh6x-hcrx-8h8g",
"modified": "2026-06-04T18:30:32Z",
"published": "2026-06-04T18:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67446"
},
{
"type": "WEB",
"url": "https://github.com/fun-beep/CVEs/tree/main/CVE-2025-67446"
},
{
"type": "WEB",
"url": "https://neterbit.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-GP27-VHQC-JQVP
Vulnerability from github – Published: 2022-04-30 18:18 – Updated: 2022-04-30 18:18mod_usertrack in Apache 1.3.11 through 1.3.20 generates session ID's using predictable information including host IP address, system time and server process ID, which allows local users to obtain session ID's and bypass authentication when these session ID's are used for authentication.
{
"affected": [],
"aliases": [
"CVE-2001-1534"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2001-12-31T05:00:00Z",
"severity": "LOW"
},
"details": "mod_usertrack in Apache 1.3.11 through 1.3.20 generates session ID\u0027s using predictable information including host IP address, system time and server process ID, which allows local users to obtain session ID\u0027s and bypass authentication when these session ID\u0027s are used for authentication.",
"id": "GHSA-gp27-vhqc-jqvp",
"modified": "2022-04-30T18:18:14Z",
"published": "2022-04-30T18:18:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2001-1534"
},
{
"type": "WEB",
"url": "http://cert.uni-stuttgart.de/archive/bugtraq/2001/11/msg00084.html"
},
{
"type": "WEB",
"url": "http://www.iss.net/security_center/static/7494.php"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/3521"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GP2M-7CFP-H6GF
Vulnerability from github – Published: 2020-01-24 21:28 – Updated: 2024-02-07 18:42Background
When a SimpleSAMLphp Identity Provider is misconfigured, a bug in the software when trying to build a persistent NameID to univocally identify the authenticating subject could cause different users to get the same identifier generated, depending on the attributes available for them right after authentication.
Please note that even though this is possible thanks to a bug, an IdP must be misconfigured to release persistent NameIDs even if it is not properly configured to generate them based on the specifics of the deployment.
Description
Persistent NameIDs will typically be sent as part of the Subject element of a SAML assertion, or as the contents of the eduPersonTargetedID attribute. Here is an example of such a NameID:
<NameID Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:persistent“>
zbonsm0Yn9Gnw14uQEEPr6AO7d+IvxwCQN3t+o24jYs=
</NameID>
Some service providers will use this information to identify a user across sessions because a persistent NameID will never change for a given user. This could lead to different users accessing the same account in those service providers.
In order to be affected by this issue, the following circumstances must concur:
- SimpleSAMLphp acts as an identity provider.
- The service provider asking for authentication requests a persistent
NameID. - No
saml:PersistentNameIDauthentication processing filter is configured (neither for the whole IdP, nor for a given SP). - No
simplesaml.nameidattributeconfiguration option is set (neither for the whole IdP, nor for a given SP). - One of the following alternatives:
- No
userid.attributeconfiguration option is set and the users don't have aneduPersonPrincipalNameattribute in the users backend, or - the
userid.attributeconfiguration option is set to an empty or missing attribute.
If all these requirements are met, the SimpleSAML_Auth_ProcessingChain class will try to keep a unique user identifier in the state array (addUserID() method). Bear in mind that this code is executed before all the authentication processing filters configured, meaning that only those attributes retrieved for the user during initial authentication will be available. If no userid.attribute configuration option is set, the default eduPersonPrincipalName will then be used. However, since it is missing, no identifier will be kept. Alternatively, if userid.attribute is set to a missing or empty attribute, the addUserID() method will abort trying to register an identifier.
After executing all authentication processing filters, SimpleSAMLphp will build a SAML assertion. If the service provider requests persistent NameIDs, SimpleSAMLphp will attempt to generate one given that none is already available (because the saml:PersistentNameID filter was not used). At this point, the code will look for the simplesaml.nameidattribute configuration option in either the local IdP metadata or in the remote SP metadata. If none of them are configured, it will default to the unique user identifier previously registered by SimpleSAML_Auth_ProcessingChain. If no identifier was kept there, the code will log an error message:
Unable to generate NameID. Check the userid.attribute option.
However, instead of aborting the NameID generation at that point, it will go on and use a value missing from the state array as the source for the computation, meaning the null type will be used. Hence, all users connecting to a given service provider will get the same NameID generated, because all the input parameters will be the same:
- The SP's entity identifier.
- The IdP's entity identifier.
- The
nullvalue. - The common secret salt from the main configuration.
Affected versions
All SimpleSAMLphp versions between 1.7.0 and 1.14.10, inclusive.
Impact
Those identity providers affected by this bug and misconfigured as previously described could be issuing SAML assertions with common NameIDs for all or a subset of their users. If a service provider uses those NameIDs to identify the users of the affected IdP, all the users will be associated with the same user account at the service provider, causing all sorts of potential security issues like information disclosure or unauthorized access.
While we can consider this unlikely to happen, some cases have been already observed. In particular, some identity providers using default configurations and consuming metadata automatically (i.e. using the metarefresh module) while using a user backend like Active Directory that does not populate eduPersonPrincipalName are particularly sensitive to this issue.
Resolution
Upgrade to the latest version.
Configure a saml:PersistentNameID authentication processing filter according to your needs. Remember to check that the attribute used as the source for the NameID is present at the moment the saml:PersistentNameID filter is executed. The attribute used must be unique per user, and must not change over time.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "simplesamlphp/simplesamlphp"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"fixed": "1.14.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-12873"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": true,
"github_reviewed_at": "2020-01-24T21:24:46Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Background\nWhen a SimpleSAMLphp Identity Provider is misconfigured, a bug in the software when trying to build a persistent `NameID` to univocally identify the authenticating subject could cause different users to get the same identifier generated, depending on the attributes available for them right after authentication.\n\nPlease note that even though this is possible thanks to a bug, **an IdP must be misconfigured** to release persistent `NameID`s even if it is not properly configured to generate them based on the specifics of the deployment.\n\n### Description\nPersistent `NameID`s will typically be sent as part of the `Subject` element of a SAML assertion, or as the contents of the `eduPersonTargetedID` attribute. Here is an example of such a `NameID`:\n\n \u003cNameID Format=\u201curn:oasis:names:tc:SAML:2.0:nameid-format:persistent\u201c\u003e\n zbonsm0Yn9Gnw14uQEEPr6AO7d+IvxwCQN3t+o24jYs=\n \u003c/NameID\u003e\n\nSome service providers will use this information to identify a user across sessions because a persistent `NameID` will never change for a given user. This could lead to different users accessing the same account in those service providers.\n\nIn order to be affected by this issue, the following circumstances must concur:\n\n- SimpleSAMLphp acts as an identity provider.\n- The service provider asking for authentication requests a persistent `NameID`.\n- No `saml:PersistentNameID` authentication processing filter is configured (neither for the whole IdP, nor for a given SP).\n- No `simplesaml.nameidattribute` configuration option is set (neither for the whole IdP, nor for a given SP).\n- One of the following alternatives:\n - No `userid.attribute` configuration option is set **and** the users don\u0027t have an `eduPersonPrincipalName` attribute in the users backend, **or**\n - the `userid.attribute` configuration option is set to an empty or missing attribute.\n\nIf all these requirements are met, the `SimpleSAML_Auth_ProcessingChain` class will try to keep a unique user identifier in the state array (`addUserID()` method). Bear in mind that this code is executed **before** all the authentication processing filters configured, meaning that only those attributes retrieved for the user during **initial authentication** will be available. If no `userid.attribute` configuration option is set, the default `eduPersonPrincipalName` will then be used. However, since it is missing, no identifier will be kept. Alternatively, if `userid.attribute` is set to a missing or empty attribute, the `addUserID()` method will abort trying to register an identifier.\n\nAfter executing all authentication processing filters, SimpleSAMLphp will build a SAML assertion. If the service provider requests persistent `NameID`s, SimpleSAMLphp will attempt to generate one given that none is already available (because the `saml:PersistentNameID` filter was not used). At this point, the code will look for the `simplesaml.nameidattribute` configuration option in either the local IdP metadata or in the remote SP metadata. If none of them are configured, it will default to the unique user identifier previously registered by `SimpleSAML_Auth_ProcessingChain`. If no identifier was kept there, the code will log an error message:\n\n Unable to generate NameID. Check the userid.attribute option.\n\nHowever, instead of aborting the `NameID` generation at that point, it will go on and use a value missing from the state array as the source for the computation, meaning the `null` type will be used. Hence, all users connecting to a given service provider will get the same `NameID` generated, because all the input parameters will be the same:\n\n- The SP\u0027s entity identifier.\n- The IdP\u0027s entity identifier.\n- The `null` value.\n- The common secret salt from the main configuration.\n\n### Affected versions\nAll SimpleSAMLphp versions between 1.7.0 and 1.14.10, inclusive.\n\n### Impact\nThose identity providers affected by this bug and misconfigured as previously described could be issuing SAML assertions with common `NameID`s for all or a subset of their users. If a service provider uses those `NameID`s to identify the users of the affected IdP, all the users will be associated with the same user account at the service provider, causing all sorts of potential security issues like information disclosure or unauthorized access.\n\nWhile we can consider this unlikely to happen, some cases have been already observed. In particular, some identity providers using default configurations and consuming metadata automatically (i.e. using the _metarefresh_ module) while using a user backend like _Active Directory_ that does not populate `eduPersonPrincipalName` are particularly sensitive to this issue.\n\n### Resolution\nUpgrade to the latest version.\n\nConfigure a `saml:PersistentNameID` authentication processing filter according to your needs. Remember to check that **the attribute used as the source** for the `NameID` **is present at the moment the `saml:PersistentNameID` filter is executed**. The attribute used must be **unique** per user, and **must not change** over time.",
"id": "GHSA-gp2m-7cfp-h6gf",
"modified": "2024-02-07T18:42:34Z",
"published": "2020-01-24T21:28:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/simplesamlphp/simplesamlphp/security/advisories/GHSA-gp2m-7cfp-h6gf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12873"
},
{
"type": "WEB",
"url": "https://github.com/simplesamlphp/simplesamlphp/commit/90dca835158495b173808273e7df127303b8b953"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/simplesamlphp/simplesamlphp/CVE-2017-12873.yaml"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2017/12/msg00007.html"
},
{
"type": "WEB",
"url": "https://simplesamlphp.org/security/201612-04"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4127"
}
],
"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"
}
],
"summary": "Incorrect persistent NameID generation in SimpleSAMLphp"
}
GHSA-GPQQ-6QQR-W84G
Vulnerability from github – Published: 2022-02-19 00:01 – Updated: 2023-08-08 15:31TP-Link TL-WA850RE Wi-Fi Range Extender before v6_200923 was discovered to use highly predictable and easily detectable session keys, allowing attackers to gain administrative privileges.
{
"affected": [],
"aliases": [
"CVE-2022-22922"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-18T01:15:00Z",
"severity": "CRITICAL"
},
"details": "TP-Link TL-WA850RE Wi-Fi Range Extender before v6_200923 was discovered to use highly predictable and easily detectable session keys, allowing attackers to gain administrative privileges.",
"id": "GHSA-gpqq-6qqr-w84g",
"modified": "2023-08-08T15:31:44Z",
"published": "2022-02-19T00:01:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22922"
},
{
"type": "WEB",
"url": "https://github.com/emremulazimoglu/cve/blob/main/CWE330-TL-WA850RE-v6.md"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/support/download/tl-wa850re/v6/#Firmware"
}
],
"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-GQ25-78JF-V78C
Vulnerability from github – Published: 2025-11-26 21:31 – Updated: 2026-06-08 19:52An issue was discovered in Overhang.IO (tutor-open-edx) (overhangio/tutor) 20.0.2 allowing local unauthorized attackers to gain access to sensitive information due to the absence of proper cache-control HTTP headers and client-side session checks.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tutor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "20.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-65681"
],
"database_specific": {
"cwe_ids": [
"CWE-384"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-01T22:57:57Z",
"nvd_published_at": "2025-11-26T19:15:49Z",
"severity": "LOW"
},
"details": "An issue was discovered in Overhang.IO (tutor-open-edx) (overhangio/tutor) 20.0.2 allowing local unauthorized attackers to gain access to sensitive information due to the absence of proper cache-control HTTP headers and client-side session checks.",
"id": "GHSA-gq25-78jf-v78c",
"modified": "2026-06-08T19:52:17Z",
"published": "2025-11-26T21:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65681"
},
{
"type": "WEB",
"url": "https://docs.tutor.edly.io"
},
{
"type": "WEB",
"url": "https://github.com/Rivek619/CVE-2025-65681"
},
{
"type": "PACKAGE",
"url": "https://github.com/overhangio/tutor"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tutor/PYSEC-2025-219.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Overhang Tutor Discloses Sensitive Information due to Improper Cache-Control"
}
GHSA-GQ2M-77HF-VWGH
Vulnerability from github – Published: 2026-03-05 20:53 – Updated: 2026-03-06 22:52Summary
OliveTin does not revoke server-side sessions when a user logs out. Although the browser cookie is cleared, the corresponding session remains valid in server storage until expiry (default ≈ 1 year).
An attacker with a previously stolen or captured session cookie can continue authenticating after logout, resulting in a post-logout authentication bypass.
This is a session management flaw that violates expected logout semantics.
Details
During logout:
// Logout only clears browser cookie
response.Header().Set("Set-Cookie", localCookie.String())
However, the server still accepts the session:
session := sessionStorage.Providers[provider].Sessions[sid]
...
return session
The SID is not deleted from sessionStorage.
Why vulnerable: Logout does not remove the SID from sessionStorage; old cookie is still accepted until expiry (~1 year).
File: api.go, sessions.go, local.go Lines: api.go:392-427; sessions.go:39-59, 61-80; local.go:32-47 Behavior - Login → receive SID cookie - Logout → cookie cleared client-side - Replay old SID manually → still authenticated
Expected: - Logout invalidates session immediately
Actual: - Old SID remains usable until expiry
PoC
Minimal config
listenAddressSingleHTTPFrontend: 0.0.0.0:16642
authRequireGuestsToLogin: true
authLocalUsers:
enabled: true
users:
- username: low
usergroup: users
password: "$argon2id$..."
actions:
- title: Dummy
id: dummy
shell: "echo dummy"
Reproduction
Login and capture SID:
LOGIN=$(curl -i -X POST http://localhost:16642/api/LocalUserLogin \
-H 'Content-Type: application/json' \
-d '{"username":"low","password":"lowpass"}')
SID=$(printf '%s\n' "$LOGIN" | awk -F'[=;]' '/olivetin-sid-local/{print $2}')
Works before logout:
curl -X POST http://localhost:16642/api/WhoAmI \
-H "Cookie: olivetin-sid-local=$SID"
Logout:
curl -X POST http://localhost:16642/api/Logout \
-H "Cookie: olivetin-sid-local=$SID"
Replay old cookie:
curl -X POST http://localhost:16642/api/WhoAmI \
-H "Cookie: olivetin-sid-local=$SID"
Result
User is still authenticated after logout.
Impact
Type:
Session Management Flaw
- Logout Bypass
- Session Replay
Risk: - Stolen cookies remain valid - Persistent unauthorized access - Users falsely believe logout ended the session
Attack scenarios: - Shared computers - XSS/session theft - Proxy logs - Malware/browser compromise
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/OliveTin/OliveTin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260304233115-d6a0abc3755d15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30224"
],
"database_specific": {
"cwe_ids": [
"CWE-384",
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-05T20:53:08Z",
"nvd_published_at": "2026-03-06T21:16:16Z",
"severity": "MODERATE"
},
"details": "### Summary\nOliveTin does not revoke server-side sessions when a user logs out. Although the browser cookie is cleared, the corresponding session remains valid in server storage until expiry (default \u2248 1 year).\n\nAn attacker with a previously stolen or captured session cookie can continue authenticating after logout, resulting in a post-logout authentication bypass.\n\nThis is a session management flaw that violates expected logout semantics.\n\n### Details\nDuring logout:\n```\n// Logout only clears browser cookie\nresponse.Header().Set(\"Set-Cookie\", localCookie.String())\n```\nHowever, the server still accepts the session:\n```\nsession := sessionStorage.Providers[provider].Sessions[sid]\n...\nreturn session\n```\nThe SID is not deleted from sessionStorage.\n\nWhy vulnerable: Logout does not remove the SID from sessionStorage; old cookie is still accepted until expiry (~1 year).\n\nFile: [api.go](app://-/index.html?hostId=local#), [sessions.go](app://-/index.html?hostId=local#), [local.go](app://-/index.html?hostId=local#)\nLines: api.go:392-427; sessions.go:39-59, 61-80; local.go:32-47\nBehavior\n- Login \u2192 receive SID cookie\n- Logout \u2192 cookie cleared client-side\n- Replay old SID manually \u2192 still authenticated\n\nExpected:\n- Logout invalidates session immediately\n\nActual:\n- Old SID remains usable until expiry\n\n### PoC\n\nMinimal config\n```\nlistenAddressSingleHTTPFrontend: 0.0.0.0:16642\nauthRequireGuestsToLogin: true\n\nauthLocalUsers:\n enabled: true\n users:\n - username: low\n usergroup: users\n password: \"$argon2id$...\"\n\nactions:\n - title: Dummy\n id: dummy\n shell: \"echo dummy\"\n```\n\n### Reproduction\n\nLogin and capture SID:\n```\nLOGIN=$(curl -i -X POST http://localhost:16642/api/LocalUserLogin \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"low\",\"password\":\"lowpass\"}\u0027)\n\nSID=$(printf \u0027%s\\n\u0027 \"$LOGIN\" | awk -F\u0027[=;]\u0027 \u0027/olivetin-sid-local/{print $2}\u0027)\n```\nWorks before logout:\n```\ncurl -X POST http://localhost:16642/api/WhoAmI \\\n -H \"Cookie: olivetin-sid-local=$SID\"\n```\nLogout:\n```\ncurl -X POST http://localhost:16642/api/Logout \\\n -H \"Cookie: olivetin-sid-local=$SID\"\n```\nReplay old cookie:\n```\ncurl -X POST http://localhost:16642/api/WhoAmI \\\n -H \"Cookie: olivetin-sid-local=$SID\"\n```\nResult\n\nUser is still authenticated after logout.\n### Impact\nType:\n\nSession Management Flaw\n\n- Logout Bypass\n- Session Replay\n\nRisk:\n- Stolen cookies remain valid\n- Persistent unauthorized access\n- Users falsely believe logout ended the session\n\nAttack scenarios:\n- Shared computers\n- XSS/session theft\n- Proxy logs\n- Malware/browser compromise",
"id": "GHSA-gq2m-77hf-vwgh",
"modified": "2026-03-06T22:52:14Z",
"published": "2026-03-05T20:53:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-gq2m-77hf-vwgh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30224"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/commit/d6a0abc3755d43107be1939567c52953bcbec3d5"
},
{
"type": "PACKAGE",
"url": "https://github.com/OliveTin/OliveTin"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.11.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "OliveTin Session Fixation: Logout Fails to Invalidate Server-Side Session"
}
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.