CWE-303
AllowedIncorrect Implementation of Authentication Algorithm
Abstraction: Base · Status: Draft
The requirements for the product dictate the use of an established authentication algorithm, but the implementation of the algorithm is incorrect.
189 vulnerabilities reference this CWE, most recent first.
GHSA-2FVJ-HGJ9-J2GR
Vulnerability from github – Published: 2026-07-22 22:55 – Updated: 2026-07-22 22:55Summary
The DigestAuthentication.apply() method in Jetty's HTTP client uses getBytes(StandardCharsets.ISO_8859_1) at three locations (lines 171, 179, 196) to compute Digest auth response hashes. ISO-8859-1 silently replaces any character above U+00FF (Chinese, Japanese, Cyrillic, Arabic, Emoji, etc.) with 0x3F (?), causing all such characters to produce identical hash contributions. An attacker who knows a victim's username can bypass Digest authentication by replacing all non-Latin-1 characters in the password with ? characters, since the collision password produces the same MD5-based Digest response hash as the original password.
Details
Root Cause
In jetty-core/jetty-client/src/main/java/org/eclipse/jetty/client/DigestAuthentication.java, the apply() method computes the three Digest auth hashes (H(A1), H(A2), and the final response) using ISO-8859-1 character encoding:
// Line 171 — H(A1)
String hashA1 = toHexString(digester.digest(a1.getBytes(StandardCharsets.ISO_8859_1)));
// Line 179 — H(A2)
String hashA2 = toHexString(digester.digest(a2.getBytes(StandardCharsets.ISO_8859_1)));
// Line 196 — Final response hash
final String hashA3 = toHexString(digester.digest(a3.getBytes(StandardCharsets.ISO_8859_1)));
ISO-8859-1 (Latin-1) can only encode characters in the range U+0000–U+00FF. Any character outside this range — including all CJK, Cyrillic, Arabic, Greek, Hangul, and emoji characters — is silently replaced with the byte 0x3F (?). String.getBytes(ISO_8859_1) in Java performs this replacement without any warning or exception.
PoC
Password: "我爱Java!密码123★" (7 non-Latin-1 characters)
UTF-8 encoding: 45 bytes → MD5 H(A1) = 9a4e61484f228633d5d0f95d1bbb0a99
ISO-8859-1: 31 bytes → MD5 H(A1) = d60ddc903d71913bcc3ab4a94f7fc239
Collision "??...": 31 bytes → MD5 H(A1) = d60ddc903d71913bcc3ab4a94f7fc239 ← IDENTICAL
Multi-language confirmation — all four language passwords below produce the same hash:
Chinese (密码123) → H(A1) = db87f31e8d96cd15f9acec7eabdc4560
Korean (비번123) → H(A1) = db87f31e8d96cd15f9acec7eabdc4560
Cyrillic(аб123) → H(A1) = db87f31e8d96cd15f9acec7eabdc4560
Greek (αβ123) → H(A1) = db87f31e8d96cd15f9acec7eabdc4560
Attacker(??123) → H(A1) = db87f31e8d96cd15f9acec7eabdc4560 ← all collide!
Impact
Scenario 1: Authentication Bypass (Collision Attack)
If a service using Jetty for Digest authentication has a user with a non-Latin-1 password (e.g., Chinese, Japanese, Russian), an attacker can authenticate as that user using a collision password where all non-Latin-1 characters are replaced with ?:
- Original password:
我爱Java!密码123★ - Collision password:
??Java!??123? - Both produce identical MD5 hashes under ISO-8859-1 → Authentication succeeds
This affects any password containing characters > U+00FF, which covers: - Chinese (CJK): U+4E00–U+9FFF - Japanese (Hiragana/Katakana/Kanji): U+3040–U+30FF, U+4E00+ - Korean (Hangul): U+AC00–U+D7AF - Cyrillic: U+0400–U+04FF (Russian, Ukrainian, Bulgarian, etc.) - Arabic: U+0600–U+06FF - Greek: U+0370–U+03FF - Latin Extended: U+0100–U+024F (accented European characters like ĉ, ğ, ñ when > U+00FF) - Emoji / Symbols > U+00FF
Scenario 2: Denial of Service for Non-Latin-1 Users
Most modern web applications store password hashes computed using UTF-8. When Jetty's Digest client computes a hash with ISO-8859-1, the bytes differ from what the server stored/expects. This means any user with non-ASCII (Latin-1+) characters in their password can never successfully authenticate via Digest auth — even the legitimate user. This is not just a security issue but a functional correctness bug that silently breaks authentication for most non-European-language users.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.4.58.v20250814"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-security"
},
"ranges": [
{
"events": [
{
"introduced": "9.4.0.v20161208"
},
{
"fixed": "9.4.63"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.26"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-security"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.26"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-security"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.0.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.35"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-security"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.36"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.35"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee8:jetty-ee8-security"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.36"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.35"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee9:jetty-ee9-security"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.0.36"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.9"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-security"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.9"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee8:jetty-ee8-security"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.1.9"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty.ee9:jetty-ee9-security"
},
"ranges": [
{
"events": [
{
"introduced": "12.1.0"
},
{
"fixed": "12.1.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-10050"
],
"database_specific": {
"cwe_ids": [
"CWE-173",
"CWE-303"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T22:55:18Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nThe `DigestAuthentication.apply()` method in Jetty\u0027s HTTP client uses `getBytes(StandardCharsets.ISO_8859_1)` at three locations (lines 171, 179, 196) to compute Digest auth response hashes. ISO-8859-1 silently replaces any character above U+00FF (Chinese, Japanese, Cyrillic, Arabic, Emoji, etc.) with 0x3F (`?`), causing all such characters to produce identical hash contributions. An attacker who knows a victim\u0027s username can bypass Digest authentication by replacing all non-Latin-1 characters in the password with `?` characters, since the collision password produces the same MD5-based Digest response hash as the original password.\n\n### Details\n### Root Cause\n\nIn `jetty-core/jetty-client/src/main/java/org/eclipse/jetty/client/DigestAuthentication.java`, the `apply()` method computes the three Digest auth hashes (H(A1), H(A2), and the final response) using ISO-8859-1 character encoding:\n\n```java\n// Line 171 \u2014 H(A1)\nString hashA1 = toHexString(digester.digest(a1.getBytes(StandardCharsets.ISO_8859_1)));\n\n// Line 179 \u2014 H(A2)\nString hashA2 = toHexString(digester.digest(a2.getBytes(StandardCharsets.ISO_8859_1)));\n\n// Line 196 \u2014 Final response hash\nfinal String hashA3 = toHexString(digester.digest(a3.getBytes(StandardCharsets.ISO_8859_1)));\n```\n\nISO-8859-1 (Latin-1) can only encode characters in the range U+0000\u2013U+00FF. Any character outside this range \u2014 including all CJK, Cyrillic, Arabic, Greek, Hangul, and emoji characters \u2014 is silently replaced with the byte `0x3F` (`?`). `String.getBytes(ISO_8859_1)` in Java performs this replacement without any warning or exception.\n\n### PoC\n```\nPassword: \"\u6211\u7231Java!\u5bc6\u7801123\u2605\" (7 non-Latin-1 characters)\n\nUTF-8 encoding: 45 bytes \u2192 MD5 H(A1) = 9a4e61484f228633d5d0f95d1bbb0a99\nISO-8859-1: 31 bytes \u2192 MD5 H(A1) = d60ddc903d71913bcc3ab4a94f7fc239\nCollision \"??...\": 31 bytes \u2192 MD5 H(A1) = d60ddc903d71913bcc3ab4a94f7fc239 \u2190 IDENTICAL\n```\n\nMulti-language confirmation \u2014 all four language passwords below produce the same hash:\n\n```\nChinese (\u5bc6\u7801123) \u2192 H(A1) = db87f31e8d96cd15f9acec7eabdc4560\nKorean (\ube44\ubc88123) \u2192 H(A1) = db87f31e8d96cd15f9acec7eabdc4560\nCyrillic(\u0430\u0431123) \u2192 H(A1) = db87f31e8d96cd15f9acec7eabdc4560\nGreek (\u03b1\u03b2123) \u2192 H(A1) = db87f31e8d96cd15f9acec7eabdc4560\nAttacker(??123) \u2192 H(A1) = db87f31e8d96cd15f9acec7eabdc4560 \u2190 all collide!\n```\n\n### Impact\n**Scenario 1: Authentication Bypass (Collision Attack)**\n\nIf a service using Jetty for Digest authentication has a user with a non-Latin-1 password (e.g., Chinese, Japanese, Russian), an attacker can authenticate as that user using a collision password where all non-Latin-1 characters are replaced with `?`:\n\n- Original password: `\u6211\u7231Java!\u5bc6\u7801123\u2605`\n- Collision password: `??Java!??123?`\n- **Both produce identical MD5 hashes under ISO-8859-1** \u2192 Authentication succeeds\n\nThis affects any password containing characters \u003e U+00FF, which covers:\n- Chinese (CJK): U+4E00\u2013U+9FFF\n- Japanese (Hiragana/Katakana/Kanji): U+3040\u2013U+30FF, U+4E00+\n- Korean (Hangul): U+AC00\u2013U+D7AF\n- Cyrillic: U+0400\u2013U+04FF (Russian, Ukrainian, Bulgarian, etc.)\n- Arabic: U+0600\u2013U+06FF\n- Greek: U+0370\u2013U+03FF\n- Latin Extended: U+0100\u2013U+024F (accented European characters like \u0109, \u011f, \u00f1 when \u003e U+00FF)\n- Emoji / Symbols \u003e U+00FF\n\n**Scenario 2: Denial of Service for Non-Latin-1 Users**\n\nMost modern web applications store password hashes computed using UTF-8. When Jetty\u0027s Digest client computes a hash with ISO-8859-1, the bytes differ from what the server stored/expects. This means **any user with non-ASCII (Latin-1+) characters in their password can never successfully authenticate via Digest auth** \u2014 even the legitimate user. This is not just a security issue but a functional correctness bug that silently breaks authentication for most non-European-language users.",
"id": "GHSA-2fvj-hgj9-j2gr",
"modified": "2026-07-22T22:55:19Z",
"published": "2026-07-22T22:55:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-2fvj-hgj9-j2gr"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/issues/15136"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/pull/15160"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/pull/15183"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/commit/4bcdbc7db387ce9e20e2c7571a7250280466221d"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/commit/d0bb829ccecbf19e3ad3d32f2649b2800f01222d"
},
{
"type": "PACKAGE",
"url": "https://github.com/jetty/jetty.project"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.36"
},
{
"type": "WEB",
"url": "https://github.com/jetty/jetty.project/releases/tag/jetty-12.1.10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Eclipse Jetty Digest Authentication: ISO-8859-1 lossy encoding allows authentication bypass via character substitution"
}
GHSA-2GR8-3WC7-XHJ3
Vulnerability from github – Published: 2024-04-24 18:47 – Updated: 2024-08-28 20:09Impact
Due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match.
Patches
This issue has been addressed by https://github.com/python-social-auth/social-app-django/pull/566 and fix released in 5.4.1.
Workarounds
An immediate workaround would be to change collation of the affected field:
ALTER TABLE `social_auth_usersocialauth` MODIFY `uid` varchar(255) COLLATE `utf8_bin`;
References
This issue was discovered by folks at https://opencraft.com/.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "social-auth-app-django"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-32879"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-303"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-24T18:47:21Z",
"nvd_published_at": "2024-04-24T20:15:07Z",
"severity": "MODERATE"
},
"details": "### Impact\nDue to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match.\n\n### Patches\nThis issue has been addressed by https://github.com/python-social-auth/social-app-django/pull/566 and fix released in 5.4.1.\n\n### Workarounds\nAn immediate workaround would be to change collation of the affected field:\n\n```mysql\nALTER TABLE `social_auth_usersocialauth` MODIFY `uid` varchar(255) COLLATE `utf8_bin`;\n```\n\n### References\nThis issue was discovered by folks at https://opencraft.com/.\n",
"id": "GHSA-2gr8-3wc7-xhj3",
"modified": "2024-08-28T20:09:46Z",
"published": "2024-04-24T18:47:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/python-social-auth/social-app-django/security/advisories/GHSA-2gr8-3wc7-xhj3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32879"
},
{
"type": "WEB",
"url": "https://github.com/python-social-auth/social-app-django/pull/566"
},
{
"type": "WEB",
"url": "https://github.com/python-social-auth/social-app-django/commit/31c3e0c7edb187004d8abbde7e9c4f7ef9098138"
},
{
"type": "PACKAGE",
"url": "https://github.com/python-social-auth/social-app-django"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "social-auth-app-django affected by Improper Handling of Case Sensitivity"
}
GHSA-2JPF-9R3F-F5P3
Vulnerability from github – Published: 2025-10-14 18:30 – Updated: 2025-10-14 18:30Incorrect implementation of authentication algorithm in Microsoft Exchange Server allows an unauthorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2025-53782"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-14T17:15:44Z",
"severity": "HIGH"
},
"details": "Incorrect implementation of authentication algorithm in Microsoft Exchange Server allows an unauthorized attacker to elevate privileges locally.",
"id": "GHSA-2jpf-9r3f-f5p3",
"modified": "2025-10-14T18:30:30Z",
"published": "2025-10-14T18:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53782"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53782"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3968-4QVG-96WM
Vulnerability from github – Published: 2026-09-03 15:32 – Updated: 2026-09-09 21:31A vulnerability exists in SYS600 RBAC mechanism where users having access to the engineering tools could elevate their privileges to administrator level on the underlying Windows host, granting themselves full control over the host machine.
{
"affected": [],
"aliases": [
"CVE-2026-9854"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-03T13:06:26Z",
"severity": "HIGH"
},
"details": "A vulnerability exists in SYS600 RBAC mechanism where users having access to the engineering tools could elevate their privileges to administrator level on the underlying Windows host, granting themselves full control over the host machine.",
"id": "GHSA-3968-4qvg-96wm",
"modified": "2026-09-09T21:31:15Z",
"published": "2026-09-03T15:32:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9854"
},
{
"type": "WEB",
"url": "https://publisher.hitachienergy.com/preview?DocumentID=8DBD000249\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/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-3C9R-7F29-QP32
Vulnerability from github – Published: 2026-02-16 12:30 – Updated: 2026-02-19 19:34Mattermost versions 11.1.x <= 11.1.2, 10.11.x <= 10.11.9, 11.2.x <= 11.2.1 fail to properly validate login method restrictions which allows an authenticated user to bypass SSO-only login requirements via userID-based authentication. Mattermost Advisory ID: MMSA-2025-00548
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0-20251212052346-61651b0df7ea"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 11.1.3"
},
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 10.11.10"
},
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.11.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 11.2.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.2.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.3.2-0.20251212052346-61651b0df7ea"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-0999"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-19T19:34:56Z",
"nvd_published_at": "2026-02-16T10:16:08Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 11.1.x \u003c= 11.1.2, 10.11.x \u003c= 10.11.9, 11.2.x \u003c= 11.2.1 fail to properly validate login method restrictions which allows an authenticated user to bypass SSO-only login requirements via userID-based authentication. Mattermost Advisory ID: MMSA-2025-00548",
"id": "GHSA-3c9r-7f29-qp32",
"modified": "2026-02-19T19:34:56Z",
"published": "2026-02-16T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0999"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/61651b0df7ea5db55d1e54f8d6fb5fce4149309c"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"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": "Mattermost fails to properly validate login method restrictions"
}
GHSA-3M6R-M23G-M2W9
Vulnerability from github – Published: 2026-08-07 21:30 – Updated: 2026-08-07 21:30Grav CMS's scheduler-webhook plugin contains an authentication bypass in the webhook token check. When the webhook feature is enabled but no webhookToken is configured, a compound conditional short-circuits and skips token validation, so an unauthenticated remote attacker who can reach POST /scheduler/webhook can trigger the operator's already-configured scheduled jobs by sending a single request. The primitive is triggering-existing-jobs, not attacker-chosen command execution: the attacker controls when the jobs run and which one runs (via ?job=), but does not control what the jobs do. Code execution follows only when the operator has configured a job that shells out, and even then the attacker controls timing rather than payload. Not a default-install issue: reaching the endpoint requires the separate scheduler-webhook GPM plugin to be installed, scheduler.modern.webhook.enabled to be true (default false), and no webhookToken to be configured; a stock Grav or Grav-Admin install exposes nothing here.
{
"affected": [],
"aliases": [
"CVE-2026-11430"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-07T19:17:34Z",
"severity": "MODERATE"
},
"details": "Grav CMS\u0027s scheduler-webhook plugin contains an authentication bypass in the webhook token check. When the webhook feature is enabled but no webhookToken is configured, a compound conditional short-circuits and skips token validation, so an unauthenticated remote attacker who can reach POST /scheduler/webhook can trigger the operator\u0027s already-configured scheduled jobs by sending a single request. The primitive is triggering-existing-jobs, not attacker-chosen command execution: the attacker controls when the jobs run and which one runs (via ?job=), but does not control what the jobs do. Code execution follows only when the operator has configured a job that shells out, and even then the attacker controls timing rather than payload. Not a default-install issue: reaching the endpoint requires the separate scheduler-webhook GPM plugin to be installed, scheduler.modern.webhook.enabled to be true (default false), and no webhookToken to be configured; a stock Grav or Grav-Admin install exposes nothing here.",
"id": "GHSA-3m6r-m23g-m2w9",
"modified": "2026-08-07T21:30:37Z",
"published": "2026-08-07T21:30:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getgrav/grav/security/advisories/GHSA-xwv3-2mv2-w33x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11430"
},
{
"type": "WEB",
"url": "https://github.com/getgrav/grav/commit/694f1dae06d9061bbf0669c4291e3b206f998d71"
},
{
"type": "WEB",
"url": "https://github.com/getgrav/grav"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/grav-cms-scheduler-webhook-authentication-bypass-via-null-short-circuit"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/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-3X39-62H4-F8J6
Vulnerability from github – Published: 2025-11-27 18:30 – Updated: 2025-12-17 00:41Mattermost versions 10.12.x <= 10.12.1, 10.11.x <= 10.11.4, 10.5.x <= 10.5.12, 11.0.x <= 11.0.3 fail to properly validate OAuth state tokens during OpenID Connect authentication which allows an authenticated attacker with team creation privileges to take over a user account via manipulation of authentication data during the OAuth completion flow. This requires email verification to be disabled (default: disabled), OAuth/OpenID Connect to be enabled, and the attacker to control two users in the SSO system with one of them never having logged into Mattermost.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0-20251028000919-d3ed703dc833"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.12.0"
},
{
"fixed": "10.12.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.11.0"
},
{
"fixed": "10.11.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.5.0"
},
{
"fixed": "10.5.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-12419"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-303"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-01T23:56:55Z",
"nvd_published_at": "2025-11-27T16:15:46Z",
"severity": "CRITICAL"
},
"details": "Mattermost versions 10.12.x \u003c= 10.12.1, 10.11.x \u003c= 10.11.4, 10.5.x \u003c= 10.5.12, 11.0.x \u003c= 11.0.3 fail to properly validate OAuth state tokens during OpenID Connect authentication which allows an authenticated attacker with team creation privileges to take over a user account via manipulation of authentication data during the OAuth completion flow. This requires email verification to be disabled (default: disabled), OAuth/OpenID Connect to be enabled, and the attacker to control two users in the SSO system with one of them never having logged into Mattermost.",
"id": "GHSA-3x39-62h4-f8j6",
"modified": "2025-12-17T00:41:08Z",
"published": "2025-11-27T18:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12419"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/pull/34296"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/15364790cc277cfaa372693d2d5442b87f70fd42"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/364c2203de00fe0d8424b6b46d6f0eeb02a2539a"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/46b5c436bb3093cc1da3fa2455f93d4c52389eee"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/c3f4818afe46a7084740e809708ae22641c76d8d"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/d3ed703dc8330684952eb8d49a375bac6ea7b0c6"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-3x39-62h4-f8j6"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Mattermost fails to properly validate OAuth state tokens during OpenID Connect authentication"
}
GHSA-44H9-27PC-757G
Vulnerability from github – Published: 2023-03-29 21:30 – Updated: 2023-04-07 15:30This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of TP-Link TL-WR940N 6_211111 3.20.1(US) routers. Authentication is not required to exploit this vulnerability. The specific flaw exists within the httpd service, which listens on TCP port 80 by default. The issue results from the incorrect implementation of the authentication algorithm. An attacker can leverage this vulnerability to disclose stored credentials, leading to further compromise. Was ZDI-CAN-17332.
{
"affected": [],
"aliases": [
"CVE-2022-43635"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-29T19:15:00Z",
"severity": "MODERATE"
},
"details": "This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of TP-Link TL-WR940N 6_211111 3.20.1(US) routers. Authentication is not required to exploit this vulnerability. The specific flaw exists within the httpd service, which listens on TCP port 80 by default. The issue results from the incorrect implementation of the authentication algorithm. An attacker can leverage this vulnerability to disclose stored credentials, leading to further compromise. Was ZDI-CAN-17332.",
"id": "GHSA-44h9-27pc-757g",
"modified": "2023-04-07T15:30:39Z",
"published": "2023-03-29T21:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43635"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-22-1615"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-487Q-2WVG-5JPV
Vulnerability from github – Published: 2023-05-10 18:30 – Updated: 2024-04-04 04:01An authentication bypass vulnerability exists in the Authentication functionality of Weston Embedded uC-FTPs v 1.98.00. A specially crafted set of network packets can lead to authentication bypass and denial of service. An attacker can send a sequence of unauthenticated packets to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-41985"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-303"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-10T16:15:09Z",
"severity": "HIGH"
},
"details": "An authentication bypass vulnerability exists in the Authentication functionality of Weston Embedded uC-FTPs v 1.98.00. A specially crafted set of network packets can lead to authentication bypass and denial of service. An attacker can send a sequence of unauthenticated packets to trigger this vulnerability.",
"id": "GHSA-487q-2wvg-5jpv",
"modified": "2024-04-04T04:01:05Z",
"published": "2023-05-10T18:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41985"
},
{
"type": "WEB",
"url": "https://github.com/weston-embedded/uC-FTPs/pull/1"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2022-1680"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4J6X-2764-M8GH
Vulnerability from github – Published: 2026-07-01 20:51 – Updated: 2026-07-01 20:51Impact
A vulnerability has been identified within Rancher Manager in the GitHub App authentication provider. When evaluating permissions, the provider incorrectly expands user team memberships to include all teams within the associated GitHub organization, rather than restricting access to the specific teams to which the user actually belongs.
Specifically, when a user authenticates via the GitHub App provider, Rancher's team membership evaluation logic incorrectly handles cached data. Instead of checking the user-specific list, the evaluation logic iterates over all teams defined within the entire GitHub organization. The authentication provider should consult the correctly cached, per-user membership list to assign the user's specific group permissions. Consequently, any authenticated user who belongs to at least one team in a GitHub organization is mistakenly granted group principals for every team within that entire organization during authentication and authorization checks.
This issue allows a malicious user who is a member of a low-privilege team within a GitHub organization to gain unauthorized access to or permissions for any other team in that organization. If those other teams are bound to Rancher login allowlists or RBAC roles (cluster-level, project-level, or global), the attacker can pass access checks that should otherwise fail, inheriting permissions they were never granted.
Exploitation of this vulnerability requires the following conditions to be met:
- The GitHub App authentication provider must be enabled and configured for the target GitHub organization.
- The attacker must possess a valid GitHub account with membership in at least one team within that target organization.
- A separate team within the same GitHub organization must be explicitly mapped to Rancher RBAC roles or specified within Rancher's login allowlist (allowedPrincipalIds).
Please consult the associated MITRE ATT&CK - Technique - Valid Accounts for further information about this category of attack.
Patches
This fix corrects the team listing logic to iterate only the teams stored in the per-user membership cache and includes a one-time startup migration that marks all affected User resources for refresh, forcing Rancher to rebuild group principals using the now-corrected logic.
Patched versions of Rancher include releases v2.14.2 and v2.13.6.
Workarounds
If upgrading to a patched version immediately is not feasible, users are encouraged to consider these temporary mitigations:
- Disable GitHub App authentication provider and switch to an alternative authentication provider (GitHub OAuth).
- Remove or restrict team-based group principals from allowed principalIds.
- Audit and temporarily remove RBAC bindings (GlobalRoleBindings, ClusterRoleTemplateBindings, ProjectRoleTemplateBindings) that reference GitHub App team principals until the patch is applied.
- Disable provider refresh and clean up inflated group membership for users (manually or by writing a script).
These workarounds reduce the attack surface but do not eliminate the vulnerability. Existing user sessions and cached principals remain inflated until a provider refresh occurs. Upgrading to a patched version is strongly recommended.
References
If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.14.0"
},
{
"fixed": "2.14.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.13.0"
},
{
"fixed": "2.13.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260519172014-d0c047bbc6d2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41053"
],
"database_specific": {
"cwe_ids": [
"CWE-303"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T20:51:54Z",
"nvd_published_at": "2026-06-30T12:16:23Z",
"severity": "HIGH"
},
"details": "### Impact\nA vulnerability has been identified within Rancher Manager in the GitHub App authentication provider. When evaluating permissions, the provider incorrectly expands user team memberships to include all teams within the associated GitHub organization, rather than restricting access to the specific teams to which the user actually belongs. \n\nSpecifically, when a user authenticates via the GitHub App provider, Rancher\u0027s team membership evaluation logic incorrectly handles cached data. Instead of checking the user-specific list, the evaluation logic iterates over all teams defined within the entire GitHub organization. The authentication provider should consult the correctly cached, per-user membership list to assign the user\u0027s specific group permissions. Consequently, any authenticated user who belongs to at least one team in a GitHub organization is mistakenly granted `group principals` for every team within that entire organization during authentication and authorization checks.\n\nThis issue allows a malicious user who is a member of a low-privilege team within a GitHub organization to gain unauthorized access to or permissions for any other team in that organization. If those other teams are bound to Rancher login allowlists or RBAC roles (cluster-level, project-level, or global), the attacker can pass access checks that should otherwise fail, inheriting permissions they were never granted.\n\n**Exploitation of this vulnerability requires the following conditions to be met:**\n- The GitHub App authentication provider must be enabled and configured for the target GitHub organization.\n- The attacker must possess a valid GitHub account with membership in at least one team within that target organization. \n- A separate team within the same GitHub organization must be explicitly mapped to Rancher RBAC roles or specified within Rancher\u0027s login allowlist (`allowedPrincipalIds`). \n\nPlease consult the associated [MITRE ATT\u0026CK - Technique - Valid Accounts](https://attack.mitre.org/techniques/T1078/) for further information about this category of attack.\n\n### Patches\nThis fix corrects the team listing logic to iterate only the teams stored in the per-user membership cache and includes a one-time startup migration that marks all affected User resources for refresh, forcing Rancher to rebuild `group principals` using the now-corrected logic.\n\nPatched versions of Rancher include releases `v2.14.2` and `v2.13.6`.\n\n### Workarounds\nIf upgrading to a patched version immediately is not feasible, users are encouraged to consider these temporary mitigations:\n- Disable GitHub App authentication provider and switch to an alternative authentication provider (GitHub OAuth).\n- Remove or restrict team-based `group principals` from allowed principalIds.\n- Audit and temporarily remove RBAC bindings (`GlobalRoleBindings`, `ClusterRoleTemplateBindings`, `ProjectRoleTemplateBindings`) that reference GitHub App team `principals` until the patch is applied.\n- Disable provider refresh and clean up inflated group membership for users (manually or by writing a script).\n\nThese workarounds reduce the attack surface but do not eliminate the vulnerability. Existing user sessions and cached principals remain inflated until a provider refresh occurs. Upgrading to a patched version is strongly recommended.\n\n### References\nIf you have any questions or comments about this advisory:\n- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.\n- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.\n- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).",
"id": "GHSA-4j6x-2764-m8gh",
"modified": "2026-07-01T20:51:54Z",
"published": "2026-07-01T20:51:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/security/advisories/GHSA-4j6x-2764-m8gh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41053"
},
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/pull/55093"
},
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/pull/55147"
},
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/commit/361d4d57cd09b87f3c53f88af42046ffaa7b57e4"
},
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/commit/d0c047bbc6d202e953d7557b82cbb354367db6ae"
},
{
"type": "PACKAGE",
"url": "https://github.com/rancher/rancher"
}
],
"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"
}
],
"summary": "Rancher has over-inclusive team membership expansion in GitHub App authentication provider"
}
No mitigation information available for this CWE.
CAPEC-90: Reflection Attack in Authentication Protocol
An adversary can abuse an authentication protocol susceptible to reflection attack in order to defeat it. Doing so allows the adversary illegitimate access to the target system, without possessing the requisite credentials. Reflection attacks are of great concern to authentication protocols that rely on a challenge-handshake or similar mechanism. An adversary can impersonate a legitimate user and can gain illegitimate access to the system by successfully mounting a reflection attack during authentication.