CWE-176
AllowedImproper Handling of Unicode Encoding
Abstraction: Variant · Status: Draft
The product does not properly handle when an input contains Unicode encoding.
53 vulnerabilities reference this CWE, most recent first.
GHSA-W72W-8RM9-6684
Vulnerability from github – Published: 2024-09-25 03:30 – Updated: 2024-09-25 03:30In versions of Helix Core prior to 2024.1 Patch 2 (2024.1/2655224) a Windows ANSI API Unicode "best fit" argument injection was identified.
{
"affected": [],
"aliases": [
"CVE-2024-8067"
],
"database_specific": {
"cwe_ids": [
"CWE-176"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-25T01:15:45Z",
"severity": "MODERATE"
},
"details": "In versions of Helix Core prior to 2024.1 Patch 2 (2024.1/2655224) a Windows ANSI API Unicode \"best fit\" argument injection was identified.",
"id": "GHSA-w72w-8rm9-6684",
"modified": "2024-09-25T03:30:36Z",
"published": "2024-09-25T03:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8067"
},
{
"type": "WEB",
"url": "https://portal.perforce.com/s/detail/a91PA000001SXEzYAO"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/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-WPMX-564X-H2MH
Vulnerability from github – Published: 2023-12-28 21:16 – Updated: 2024-03-01 14:35Summary
The function lookupPreprocess() is meant to apply some transformations to a string by disabling characters in the regex [-_ .]. However, due to the use of late Unicode normalization of type NFKD, it is possible to bypass that validation and re-introduce all the characters in the regex [-_ .].
// lookupPreprocess applies transformations to s so that it can be compared
// to search for something.
// For example, it is used by (ThemeStore).Lookup
func lookupPreprocess(s string) string {
return strings.ToLower(norm.NFKD.String(regexp.MustCompile(`[-_ .]`).ReplaceAllString(s, "")))
}
Take the following equivalent Unicode character U+2024 (․). Initially, the lookupPreprocess() function would compile the regex and replace the regular dot (.). However, the U+2024 (․) would bypass the ReplaceAllString(). When the normalization operation is applied to U+2024 (․), the resulting character will be U+002E (.). Thus, the dot was reintroduced back.
Impact
The lookupPreprocess() can be easily bypassed with equivalent Unicode characters like U+FE4D (﹍), which would result in the omitted U+005F (_), for instance. It should be noted here that the variable s is user-controlled data coming from /cmd/ffcss/commands.go#L22-L28 the command args. The lookupPreprocess() function is only ever used to search for themes loosely (case insensitively, while ignoring dashes, underscores and dots), so the actual security impact is classified as low.
Remediation
A simple fix would be to initially perform the Unicode normalization and then the rest of validations.
References
- https://sim4n6.beehiiv.com/p/unicode-characters-bypass-security-checks
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/ewen-lbh/ffcss"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-52081"
],
"database_specific": {
"cwe_ids": [
"CWE-176",
"CWE-74"
],
"github_reviewed": true,
"github_reviewed_at": "2023-12-28T21:16:57Z",
"nvd_published_at": "2023-12-28T16:16:02Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe function `lookupPreprocess()` is meant to apply some transformations to a string by disabling characters in the regex `[-_ .]`. However, due to the use of late Unicode normalization of type NFKD, it is possible to bypass that validation and re-introduce all the characters in the regex `[-_ .]`. \n\n```go\n// lookupPreprocess applies transformations to s so that it can be compared\n// to search for something.\n// For example, it is used by (ThemeStore).Lookup\nfunc lookupPreprocess(s string) string {\n\treturn strings.ToLower(norm.NFKD.String(regexp.MustCompile(`[-_ .]`).ReplaceAllString(s, \"\")))\n}\n``` \n\nTake the following equivalent Unicode character U+2024 (\u2024). Initially, the `lookupPreprocess()` function would compile the regex and replace the regular dot (.). However, the U+2024 (\u2024) would bypass the `ReplaceAllString()`. When the normalization operation is applied to U+2024 (\u2024), the resulting character will be U+002E (.). Thus, the dot was reintroduced back.\n\n### Impact\n\nThe `lookupPreprocess()` can be easily bypassed with equivalent Unicode characters like U+FE4D (\ufe4d), which would result in the omitted U+005F (_), for instance. It should be noted here that the variable `s` is user-controlled data coming from [/cmd/ffcss/commands.go#L22-L28](https://github.com/ewen-lbh/ffcss/blob/master/cmd/ffcss/commands.go#L22-L28) the command args. The `lookupPreprocess()` function is only ever used to search for themes loosely (case insensitively, while ignoring dashes, underscores and dots), so the actual security impact is classified as low.\n\n### Remediation\n\nA simple fix would be to initially perform the Unicode normalization and then the rest of validations.\n\n### References\n\n - https://sim4n6.beehiiv.com/p/unicode-characters-bypass-security-checks\n",
"id": "GHSA-wpmx-564x-h2mh",
"modified": "2024-03-01T14:35:42Z",
"published": "2023-12-28T21:16:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ewen-lbh/ffcss/security/advisories/GHSA-wpmx-564x-h2mh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52081"
},
{
"type": "WEB",
"url": "https://github.com/ewen-lbh/ffcss/commit/f9c491874b858a32fcae15045f169fd7d02f90dc"
},
{
"type": "PACKAGE",
"url": "https://github.com/ewen-lbh/ffcss"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "ewen-lbh/ffcss Late-Unicode normalization vulnerability"
}
GHSA-XH5H-P8C5-4W4X
Vulnerability from github – Published: 2026-04-22 18:31 – Updated: 2026-07-06 19:53Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-jcjr-rh8q-7xqf. This link is maintained to preserve external references.
Original Description
A logic error in the ln utility of uutils coreutils causes the program to reject source paths containing non-UTF-8 filename bytes when using target-directory forms (e.g., ln SOURCE... DIRECTORY). While GNU ln treats filenames as raw bytes and creates the links correctly, the uutils implementation enforces UTF-8 encoding, resulting in a failure to stat the file and a non-zero exit code. In environments where automated scripts or system tasks process valid but non-UTF-8 filenames common on Unix filesystems, this divergence causes the utility to fail, leading to a local denial of service for those specific operations.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "coreutils"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-176"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-30T18:00:21Z",
"nvd_published_at": "2026-04-22T17:16:41Z",
"severity": "LOW"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-jcjr-rh8q-7xqf. This link is maintained to preserve external references.\n\n### Original Description\nA logic error in the ln utility of uutils coreutils causes the program to reject source paths containing non-UTF-8 filename bytes when using target-directory forms (e.g., ln SOURCE... DIRECTORY). While GNU ln treats filenames as raw bytes and creates the links correctly, the uutils implementation enforces UTF-8 encoding, resulting in a failure to stat the file and a non-zero exit code. In environments where automated scripts or system tasks process valid but non-UTF-8 filenames common on Unix filesystems, this divergence causes the utility to fail, leading to a local denial of service for those specific operations.",
"id": "GHSA-xh5h-p8c5-4w4x",
"modified": "2026-07-06T19:53:31Z",
"published": "2026-04-22T18:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35373"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/pull/11403"
},
{
"type": "PACKAGE",
"url": "https://github.com/uutils/coreutils"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Duplicate Advisory: uutils coreutils has an Improper Handling of Unicode Encoding Issue",
"withdrawn": "2026-07-06T19:53:31Z"
}
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.
CAPEC-71: Using Unicode Encoding to Bypass Validation Logic
An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.