CWE-565
AllowedReliance on Cookies without Validation and Integrity Checking
Abstraction: Base · Status: Incomplete
The product relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user.
95 vulnerabilities reference this CWE, most recent first.
GHSA-24W3-V7FC-CJWV
Vulnerability from github – Published: 2026-03-31 00:31 – Updated: 2026-03-31 00:31The Debugger & Troubleshooter plugin for WordPress was vulnerable to Unauthenticated Privilege Escalation in versions up to and including 1.3.2. This was due to the plugin accepting the wp_debug_troubleshoot_simulate_user cookie value directly as a user ID without any cryptographic validation or authorization checks. The cookie value was used to override the determine_current_user filter, which allowed unauthenticated attackers to impersonate any user by simply setting the cookie to their target user ID. This made it possible for unauthenticated attackers to gain administrator-level access and perform any privileged actions including creating new administrator accounts, modifying site content, installing plugins, or taking complete control of the WordPress site. The vulnerability was fixed in version 1.4.0 by implementing a cryptographic token-based validation system where only administrators can initiate user simulation, and the cookie contains a random 64-character token that must be validated against database-stored mappings rather than accepting arbitrary user IDs.
{
"affected": [],
"aliases": [
"CVE-2026-5130"
],
"database_specific": {
"cwe_ids": [
"CWE-565"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-30T23:17:04Z",
"severity": "HIGH"
},
"details": "The Debugger \u0026 Troubleshooter plugin for WordPress was vulnerable to Unauthenticated Privilege Escalation in versions up to and including 1.3.2. This was due to the plugin accepting the wp_debug_troubleshoot_simulate_user cookie value directly as a user ID without any cryptographic validation or authorization checks. The cookie value was used to override the determine_current_user filter, which allowed unauthenticated attackers to impersonate any user by simply setting the cookie to their target user ID. This made it possible for unauthenticated attackers to gain administrator-level access and perform any privileged actions including creating new administrator accounts, modifying site content, installing plugins, or taking complete control of the WordPress site. The vulnerability was fixed in version 1.4.0 by implementing a cryptographic token-based validation system where only administrators can initiate user simulation, and the cookie contains a random 64-character token that must be validated against database-stored mappings rather than accepting arbitrary user IDs.",
"id": "GHSA-24w3-v7fc-cjwv",
"modified": "2026-03-31T00:31:13Z",
"published": "2026-03-31T00:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5130"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/debugger-troubleshooter/tags/1.3.2/debug-troubleshooter.php#L827"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/debugger-troubleshooter/tags/1.3.2/debug-troubleshooter.php#L849"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3486202/debugger-troubleshooter/trunk/debug-troubleshooter.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/3e037931-870f-45eb-973c-0276911682ad?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2CJQ-GPFR-MW4C
Vulnerability from github – Published: 2022-05-24 22:01 – Updated: 2022-12-13 03:30IBM Security Guardium Big Data Intelligence (SonarG) 4.0 does not set the secure attribute for cookies in HTTPS sessions, which could cause the user agent to send those cookies in plaintext over an HTTP session. IBM X-Force ID: 161210.
{
"affected": [],
"aliases": [
"CVE-2019-4330"
],
"database_specific": {
"cwe_ids": [
"CWE-565"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-10-29T00:15:00Z",
"severity": "MODERATE"
},
"details": "IBM Security Guardium Big Data Intelligence (SonarG) 4.0 does not set the secure attribute for cookies in HTTPS sessions, which could cause the user agent to send those cookies in plaintext over an HTTP session. IBM X-Force ID: 161210.",
"id": "GHSA-2cjq-gpfr-mw4c",
"modified": "2022-12-13T03:30:44Z",
"published": "2022-05-24T22:01:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-4330"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/161210"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/1096384"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-33QG-7WPP-89CQ
Vulnerability from github – Published: 2026-04-08 00:15 – Updated: 2026-05-13 16:21Rack::Session::Cookie incorrectly handles decryption failures when configured with secrets:. If cookie decryption fails, the implementation falls back to a default decoder instead of rejecting the cookie. This allows an unauthenticated attacker to supply a crafted session cookie that is accepted as valid session data without knowledge of any configured secret.
Because this mechanism is used to load session state, an attacker can manipulate session contents and potentially gain unauthorized access.
Details
When secrets: is configured, Rack::Session::Cookie attempts to decrypt incoming session cookies using one of the configured encryptors. If all decrypt attempts fail, the implementation does not reject the cookie. Instead, it falls back to decoding the cookie using a default coder.
This fallback path processes attacker-controlled cookie data as trusted session state. The behavior is implicit and occurs even when encrypted cookies are expected.
The fallback decoder is applied automatically and does not require the application to opt into a non-encrypted session format. As a result, a client can send a specially crafted cookie value that bypasses the intended integrity protections provided by secrets:.
This issue affects both default configurations and those using alternative serializers for encrypted payloads.
Impact
Any Rack application using Rack::Session::Cookie with secrets: may be affected.
[!NOTE] Rails applications are typically not affected — Rails uses
ActionDispatch::Session::CookieStore, which is a separate implementation backed byActiveSupport::MessageEncryptorand does not share the vulnerable code path.
An unauthenticated attacker can supply a crafted session cookie that is accepted as valid session data. This can lead to authentication bypass or privilege escalation in applications that rely on session values for identity or authorization decisions.
Depending on application behavior and available runtime components, processing of untrusted session data may also expose additional risks.
Mitigation
- Update to a patched version of
rack-sessionthat rejects cookies when decryption fails under thesecrets:configuration. - After updating, rotate session secrets to invalidate existing session cookies, since attacker-supplied session data may have been accepted and re-issued prior to the fix.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rack-session"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39324"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-345",
"CWE-502",
"CWE-565"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T00:15:08Z",
"nvd_published_at": "2026-04-07T18:16:43Z",
"severity": "CRITICAL"
},
"details": "`Rack::Session::Cookie` incorrectly handles decryption failures when configured with `secrets:`. If cookie decryption fails, the implementation falls back to a default decoder instead of rejecting the cookie. This allows an unauthenticated attacker to supply a crafted session cookie that is accepted as valid session data without knowledge of any configured secret.\n\nBecause this mechanism is used to load session state, an attacker can manipulate session contents and potentially gain unauthorized access.\n\n## Details\n\nWhen `secrets:` is configured, `Rack::Session::Cookie` attempts to decrypt incoming session cookies using one of the configured encryptors. If all decrypt attempts fail, the implementation does not reject the cookie. Instead, it falls back to decoding the cookie using a default coder.\n\nThis fallback path processes attacker-controlled cookie data as trusted session state. The behavior is implicit and occurs even when encrypted cookies are expected.\n\nThe fallback decoder is applied automatically and does not require the application to opt into a non-encrypted session format. As a result, a client can send a specially crafted cookie value that bypasses the intended integrity protections provided by `secrets:`.\n\nThis issue affects both default configurations and those using alternative serializers for encrypted payloads.\n\n## Impact\n\nAny Rack application using `Rack::Session::Cookie` with `secrets:` may be affected.\n\n\u003e [!NOTE]\n\u003e Rails applications are typically not affected \u2014 Rails uses `ActionDispatch::Session::CookieStore`, which is a separate implementation backed by `ActiveSupport::MessageEncryptor` and does not share the vulnerable code path.\n\nAn unauthenticated attacker can supply a crafted session cookie that is accepted as valid session data. This can lead to authentication bypass or privilege escalation in applications that rely on session values for identity or authorization decisions.\n\nDepending on application behavior and available runtime components, processing of untrusted session data may also expose additional risks.\n\n## Mitigation\n\n* Update to a patched version of`rack-session` that rejects cookies when decryption fails under the `secrets:` configuration.\n * After updating, rotate session secrets to invalidate existing session cookies, since attacker-supplied session data may have been accepted and re-issued prior to the fix.",
"id": "GHSA-33qg-7wpp-89cq",
"modified": "2026-05-13T16:21:11Z",
"published": "2026-04-08T00:15:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rack/rack-session/security/advisories/GHSA-33qg-7wpp-89cq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39324"
},
{
"type": "PACKAGE",
"url": "https://github.com/rack/rack-session"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack-session/CVE-2026-39324.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Rack::Session::Cookie secrets: decrypt failure fallback enables secretless session forgery and Marshal deserialization"
}
GHSA-3R85-3GPW-C7MC
Vulnerability from github – Published: 2022-04-16 00:00 – Updated: 2022-04-26 00:00An issue in upload.csp of FANTEC GmbH MWiD25-DS Firmware v2.000.030 allows attackers to write files and reset the user passwords without having a valid session cookie.
{
"affected": [],
"aliases": [
"CVE-2022-28113"
],
"database_specific": {
"cwe_ids": [
"CWE-565"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-15T19:15:00Z",
"severity": "HIGH"
},
"details": "An issue in upload.csp of FANTEC GmbH MWiD25-DS Firmware v2.000.030 allows attackers to write files and reset the user passwords without having a valid session cookie.",
"id": "GHSA-3r85-3gpw-c7mc",
"modified": "2022-04-26T00:00:53Z",
"published": "2022-04-16T00:00:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28113"
},
{
"type": "WEB",
"url": "https://code-byter.com/2022/04/06/fantec-wifi.html"
},
{
"type": "WEB",
"url": "https://drive.google.com/file/d/1OvpNieX3pYFaZprglr5T0lV0WuLoLcLu/view?usp=sharing"
},
{
"type": "WEB",
"url": "https://drive.google.com/file/d/1s1AgI5Dw7_GNenmI-mw0Sx2B9MkNTbc7/view?usp=sharing"
},
{
"type": "WEB",
"url": "https://github.com/code-byter/CVE-2022-28113"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3XMP-RP4W-PJGV
Vulnerability from github – Published: 2026-01-06 18:31 – Updated: 2026-01-06 18:31An issue was discovered in NJHYST HY511 POE core before 2.1 and plugins before 0.1. The vulnerability stems from the device's insufficient cookie verification, allowing an attacker to directly request the configuration file address and download the core configuration file without logging into the device management backend. By reading the corresponding username and self-decrypted MD5 password in the core configuration file, the attacker can directly log in to the backend, thereby bypassing the front-end backend login page.
{
"affected": [],
"aliases": [
"CVE-2025-65212"
],
"database_specific": {
"cwe_ids": [
"CWE-565"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-06T16:15:51Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in NJHYST HY511 POE core before 2.1 and plugins before 0.1. The vulnerability stems from the device\u0027s insufficient cookie verification, allowing an attacker to directly request the configuration file address and download the core configuration file without logging into the device management backend. By reading the corresponding username and self-decrypted MD5 password in the core configuration file, the attacker can directly log in to the backend, thereby bypassing the front-end backend login page.",
"id": "GHSA-3xmp-rp4w-pjgv",
"modified": "2026-01-06T18:31:35Z",
"published": "2026-01-06T18:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65212"
},
{
"type": "WEB",
"url": "https://gist.github.com/a2148001284/bcdda75fc8718454f16a7b9259463719"
},
{
"type": "WEB",
"url": "https://github.com/a2148001284/test1/blob/main/%E6%9C%AA%E6%8E%88%E6%9D%83%E8%AE%BF%E9%97%AE%E5%90%8E%E5%8F%B0%E6%BC%8F%E6%B4%9EEN.md"
}
],
"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-47FQ-MM42-6V8W
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2025-04-20 03:40The Cloud Controller and Router in Cloud Foundry (CAPI-release capi versions prior to v1.32.0, Routing-release versions prior to v0.159.0, CF-release versions prior to v267) do not validate the issuer on JSON Web Tokens (JWTs) from UAA. With certain multi-zone UAA configurations, zone administrators are able to escalate their privileges.
{
"affected": [],
"aliases": [
"CVE-2017-8034"
],
"database_specific": {
"cwe_ids": [
"CWE-565"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-17T14:29:00Z",
"severity": "MODERATE"
},
"details": "The Cloud Controller and Router in Cloud Foundry (CAPI-release capi versions prior to v1.32.0, Routing-release versions prior to v0.159.0, CF-release versions prior to v267) do not validate the issuer on JSON Web Tokens (JWTs) from UAA. With certain multi-zone UAA configurations, zone administrators are able to escalate their privileges.",
"id": "GHSA-47fq-mm42-6v8w",
"modified": "2025-04-20T03:40:56Z",
"published": "2022-05-13T01:47:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8034"
},
{
"type": "WEB",
"url": "https://www.cloudfoundry.org/cve-2017-8034"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4M6C-649P-F6GF
Vulnerability from github – Published: 2026-04-14 22:32 – Updated: 2026-04-15 21:14Summary
The serendipity_setCookie() function uses $_SERVER['HTTP_HOST'] without validation as the domain parameter of setcookie(). An attacker can force authentication cookies — including session tokens and auto-login tokens — to be scoped to an attacker-controlled domain, facilitating session hijacking.
Details
In include/functions_config.inc.php:726:
function serendipity_setCookie($name, $value, $securebyprot = true, ...) {
$host = $_SERVER['HTTP_HOST']; // ← attacker-controlled, no validation
if ($securebyprot) {
if ($pos = strpos($host, ":")) {
$host = substr($host, 0, $pos); // strips port only
}
}
setcookie("serendipity[$name]", $value, [
'domain' => $host, // ← poisoned domain
'httponly' => $httpOnly,
'samesite' => 'Strict'
]);
}
This function is called during login with sensitive cookies:
// functions_config.inc.php:455-498
serendipity_setCookie('author_autologintoken', $rnd, true, false, true);
serendipity_setCookie('author_username', $user);
serendipity_setCookie('author_token', $hash);
If an attacker can influence the Host header at login time (e.g. via MITM, reverse proxy misconfiguration, or load balancer), authentication cookies are issued scoped to the attacker's domain instead of the legitimate one.
PoC
curl -v -X POST \
-H "Host: attacker.com" \
-d "serendipity[user]=admin&serendipity[pass]=admin" \
http://[TARGET]/serendipity_admin.php 2>&1 | grep -i "set-cookie"
Expected output:
Set-Cookie: serendipity[author_token]=; domain=attacker.com; HttpOnly
Impact
- Session fixation — attacker pre-sets a cookie scoped to their domain, then tricks the victim into authenticating, inheriting the poisoned token
- Token leakage —
author_autologintokenscoped to wrong domain may be sent to attacker-controlled infrastructure - Privilege escalation — if admin logs in under a poisoned Host header, their admin token is compromised
Suggested Fix
Validate HTTP_HOST against the configured $serendipity['url'] before use:
function serendipity_setCookie($name, $value, ...) {
global $serendipity;
$configured = parse_url($serendipity['url'], PHP_URL_HOST);
$host = preg_replace('/:[0-9]+$/', '', $_SERVER['HTTP_HOST']);
$host = ($host === $configured) ? $host : $configured;
setcookie("serendipity[$name]", $value, [
'domain' => $host,
...
]);
}
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "s9y/serendipity"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39963"
],
"database_specific": {
"cwe_ids": [
"CWE-565"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T22:32:29Z",
"nvd_published_at": "2026-04-15T04:17:39Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe `serendipity_setCookie()` function uses `$_SERVER[\u0027HTTP_HOST\u0027]` without validation as the `domain` parameter of `setcookie()`. An attacker can force authentication cookies \u2014 including session tokens and auto-login tokens \u2014 to be scoped to an attacker-controlled domain, facilitating session hijacking.\n\n### Details\nIn `include/functions_config.inc.php:726`:\n```php\nfunction serendipity_setCookie($name, $value, $securebyprot = true, ...) {\n $host = $_SERVER[\u0027HTTP_HOST\u0027]; // \u2190 attacker-controlled, no validation\n\n if ($securebyprot) {\n if ($pos = strpos($host, \":\")) {\n $host = substr($host, 0, $pos); // strips port only\n }\n }\n\n setcookie(\"serendipity[$name]\", $value, [\n \u0027domain\u0027 =\u003e $host, // \u2190 poisoned domain\n \u0027httponly\u0027 =\u003e $httpOnly,\n \u0027samesite\u0027 =\u003e \u0027Strict\u0027\n ]);\n}\n```\n\nThis function is called during login with sensitive cookies:\n```php\n// functions_config.inc.php:455-498\nserendipity_setCookie(\u0027author_autologintoken\u0027, $rnd, true, false, true);\nserendipity_setCookie(\u0027author_username\u0027, $user);\nserendipity_setCookie(\u0027author_token\u0027, $hash);\n```\n\nIf an attacker can influence the `Host` header at login time (e.g. via MITM, reverse proxy misconfiguration, or load balancer), authentication cookies are issued scoped to the attacker\u0027s domain instead of the legitimate one.\n\n### PoC\n```bash\ncurl -v -X POST \\\n -H \"Host: attacker.com\" \\\n -d \"serendipity[user]=admin\u0026serendipity[pass]=admin\" \\\n http://[TARGET]/serendipity_admin.php 2\u003e\u00261 | grep -i \"set-cookie\"\n```\n\nExpected output:\n```http\nSet-Cookie: serendipity[author_token]=; domain=attacker.com; HttpOnly\n```\n\n### Impact\n- **Session fixation** \u2014 attacker pre-sets a cookie scoped to their domain, then tricks the victim into authenticating, inheriting the poisoned token\n- **Token leakage** \u2014 `author_autologintoken` scoped to wrong domain may be sent to attacker-controlled infrastructure\n- **Privilege escalation** \u2014 if admin logs in under a poisoned Host header, their admin token is compromised\n\n### Suggested Fix\nValidate `HTTP_HOST` against the configured `$serendipity[\u0027url\u0027]` before use:\n```php\nfunction serendipity_setCookie($name, $value, ...) {\n global $serendipity;\n $configured = parse_url($serendipity[\u0027url\u0027], PHP_URL_HOST);\n $host = preg_replace(\u0027/:[0-9]+$/\u0027, \u0027\u0027, $_SERVER[\u0027HTTP_HOST\u0027]);\n $host = ($host === $configured) ? $host : $configured;\n\n setcookie(\"serendipity[$name]\", $value, [\n \u0027domain\u0027 =\u003e $host,\n ...\n ]);\n}\n```",
"id": "GHSA-4m6c-649p-f6gf",
"modified": "2026-04-15T21:14:19Z",
"published": "2026-04-14T22:32:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/s9y/Serendipity/security/advisories/GHSA-4m6c-649p-f6gf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39963"
},
{
"type": "PACKAGE",
"url": "https://github.com/s9y/Serendipity"
},
{
"type": "WEB",
"url": "https://github.com/s9y/Serendipity/releases/tag/2.6.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Serendipity has a Host Header Injection allows authentication cookie scoping to attacker-controlled domain in functions_config.inc.php"
}
GHSA-4VF4-QMVG-MH7H
Vulnerability from github – Published: 2022-01-21 23:22 – Updated: 2023-08-29 16:46CGI::Cookie.parse in Ruby through 2.6.8 mishandles security prefixes in cookie names. This also affects the CGI gem prior to versions 0.3.1, 0.2.1, 0.1.1, and 0.1.0.1 for Ruby.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.0"
},
{
"fixed": "0.3.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.3.0"
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0.2.0"
},
{
"fixed": "0.2.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.2.0"
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "cgi"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-41819"
],
"database_specific": {
"cwe_ids": [
"CWE-565"
],
"github_reviewed": true,
"github_reviewed_at": "2022-01-13T18:53:26Z",
"nvd_published_at": "2022-01-01T06:15:00Z",
"severity": "HIGH"
},
"details": "CGI::Cookie.parse in Ruby through 2.6.8 mishandles security prefixes in cookie names. This also affects the CGI gem prior to versions 0.3.1, 0.2.1, 0.1.1, and 0.1.0.1 for Ruby.",
"id": "GHSA-4vf4-qmvg-mh7h",
"modified": "2023-08-29T16:46:42Z",
"published": "2022-01-21T23:22:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41819"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/910552"
},
{
"type": "PACKAGE",
"url": "https://github.com/ruby/cgi"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/cgi/CVE-2021-41819.yml"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IUXQCH6FRKANCVZO2Q7D2SQX33FP3KWN"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UTOJGS5IEFDK3UOO7IY4OTTFGHGLSWZF"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IUXQCH6FRKANCVZO2Q7D2SQX33FP3KWN"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UTOJGS5IEFDK3UOO7IY4OTTFGHGLSWZF"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202401-27"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220121-0003"
},
{
"type": "WEB",
"url": "https://www.ruby-lang.org/en/news/2021/11/24/cookie-prefix-spoofing-in-cgi-cookie-parse-cve-2021-41819"
}
],
"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"
}
],
"summary": "Cookie Prefix Spoofing in CGI::Cookie.parse"
}
GHSA-4VWM-CMFJ-FP9Q
Vulnerability from github – Published: 2024-03-30 03:30 – Updated: 2024-11-04 18:31Ruijie RG-NBR700GW 10.3(4b12) router lacks cookie verification when resetting the password, resulting in an administrator password reset vulnerability. An attacker can use this vulnerability to log in to the device and disrupt the business of the enterprise.
{
"affected": [],
"aliases": [
"CVE-2024-28288"
],
"database_specific": {
"cwe_ids": [
"CWE-565"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-30T01:15:47Z",
"severity": "CRITICAL"
},
"details": "Ruijie RG-NBR700GW 10.3(4b12) router lacks cookie verification when resetting the password, resulting in an administrator password reset vulnerability. An attacker can use this vulnerability to log in to the device and disrupt the business of the enterprise.",
"id": "GHSA-4vwm-cmfj-fp9q",
"modified": "2024-11-04T18:31:17Z",
"published": "2024-03-30T03:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28288"
},
{
"type": "WEB",
"url": "https://github.com/adminquit/CVE-2024-28288/blob/d8223c6d45af877669c27fa0a95adfe51924fa86/CVE-2024-28288/CVE-2024-28288.md"
},
{
"type": "WEB",
"url": "https://pan.baidu.com/s/1H4J_eA6wSCnDEsUSAWIzsg?pwd=CVE1"
}
],
"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-55MM-5399-7R63
Vulnerability from github – Published: 2020-08-05 14:52 – Updated: 2021-03-04 18:25Impact
Previously encrypted cookie values were not tied to the name of the cookie the value belonged to. This meant that certain classes of attacks that took advantage of other theoretical vulnerabilities in user facing code (nothing exploitable in the core project itself) had a higher chance of succeeding.
Specifically, if your usage exposed a way for users to provide unfiltered user input and have it returned to them as an encrypted cookie (ex. storing a user provided search query in a cookie) they could then use the generated cookie in place of other more tightly controlled cookies; or if your usage exposed the plaintext version of an encrypted cookie at any point to the user they could theoretically provide encrypted content from your application back to it as an encrypted cookie and force the framework to decrypt it for them.
Patches
Issue has been patched in Build 468 (v1.0.468).
NOTE: If you are using the cookie session driver, all of your session data will be invalidated. All other session drivers should smoothly upgrade to the changes (although the backend authentication persist cookie will also be invalidated requiring users to login again once their current session expires).
Workarounds
Apply https://github.com/octobercms/library/commit/28310d4fb336a1741b39498f4474497644a6875c to your installation manually if unable to upgrade to Build 468.
References
- https://blog.laravel.com/laravel-cookie-security-releases
- https://github.com/laravel/framework/compare/4c7d118181d6c7f1f883643702df807ced016c5e...a731824421f9ebc586728ea9c7cff231a249aaa9
For more information
If you have any questions or comments about this advisory: * Email us at hello@octobercms.com
Threat Assessment
Assessed as Low given that it is not directly exploitable within the core but requires other security vulnerabilities within the application to have an effect and the severity of its effect depends entirely on the severity of those other holes in the application's defences.
Acknowledgements
Thanks to Takashi Terada of Mitsui Bussan Secure Directions, Inc. for finding the original issue in Laravel and @taylorotwell for sharing the report with the October CMS team.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "october/rain"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.319"
},
{
"fixed": "1.0.468"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-15128"
],
"database_specific": {
"cwe_ids": [
"CWE-327",
"CWE-565"
],
"github_reviewed": true,
"github_reviewed_at": "2020-07-31T17:44:58Z",
"nvd_published_at": "2020-07-31T18:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nPreviously encrypted cookie values were not tied to the name of the cookie the value belonged to. This meant that certain classes of attacks that took advantage of other theoretical vulnerabilities in user facing code (nothing exploitable in the core project itself) had a higher chance of succeeding. \n\nSpecifically, if your usage exposed a way for users to provide unfiltered user input and have it returned to them as an encrypted cookie (ex. storing a user provided search query in a cookie) they could then use the generated cookie in place of other more tightly controlled cookies; or if your usage exposed the plaintext version of an encrypted cookie at any point to the user they could theoretically provide encrypted content from your application back to it as an encrypted cookie and force the framework to decrypt it for them. \n\n### Patches\nIssue has been patched in Build 468 (v1.0.468).\n\n\u003e**NOTE**: If you are using the cookie session driver, all of your session data will be invalidated. All other session drivers should smoothly upgrade to the changes (although the backend authentication persist cookie will also be invalidated requiring users to login again once their current session expires).\n\n### Workarounds\nApply https://github.com/octobercms/library/commit/28310d4fb336a1741b39498f4474497644a6875c to your installation manually if unable to upgrade to Build 468.\n\n### References\n- https://blog.laravel.com/laravel-cookie-security-releases\n- https://github.com/laravel/framework/compare/4c7d118181d6c7f1f883643702df807ced016c5e...a731824421f9ebc586728ea9c7cff231a249aaa9\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [hello@octobercms.com](mailto:hello@octobercms.com)\n\n### Threat Assessment\nAssessed as Low given that it is not directly exploitable within the core but requires other security vulnerabilities within the application to have an effect and the severity of its effect depends entirely on the severity of those other holes in the application\u0027s defences.\n\n### Acknowledgements\n\nThanks to [Takashi Terada of Mitsui Bussan Secure Directions, Inc.](https://www.linkedin.com/in/takeshi-terada-b570a6100/) for finding the original issue in Laravel and @taylorotwell for sharing the report with the October CMS team.",
"id": "GHSA-55mm-5399-7r63",
"modified": "2021-03-04T18:25:42Z",
"published": "2020-08-05T14:52:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/octobercms/october/security/advisories/GHSA-55mm-5399-7r63"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15128"
},
{
"type": "WEB",
"url": "https://github.com/octobercms/library/pull/508"
},
{
"type": "WEB",
"url": "https://github.com/octobercms/library/commit/28310d4fb336a1741b39498f4474497644a6875c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Reliance on Cookies without validation in OctoberCMS"
}
Mitigation
Avoid using cookie data for a security-related decision.
Mitigation
Perform thorough input validation (i.e.: server side validation) on the cookie data if you're going to use it for a security related decision.
Mitigation
Add integrity checks to detect tampering.
Mitigation
Protect critical cookies from replay attacks, since cross-site scripting or other attacks may allow attackers to steal a strongly-encrypted cookie that also passes integrity checks. This mitigation applies to cookies that should only be valid during a single transaction or session. By enforcing timeouts, you may limit the scope of an attack. As part of your integrity check, use an unpredictable, server-side value that is not exposed to the client.
CAPEC-226: Session Credential Falsification through Manipulation
An attacker manipulates an existing credential in order to gain access to a target application. 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. An attacker may be able to manipulate a credential sniffed from an existing connection in order to gain access to a target server.
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.