Improper Handling of Alternate Encoding
CWE-173
The product does not properly handle when an input uses an alternate encoding that is valid for the control sphere to which the input is being sent.
We track 2 vulnerabilities of this type. 100% are rated high or critical, and the average CVSS score is 8.3.
How this weakness is prevented
- Architecture and Design: Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
- Implementation: 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.
Latest Improper Handling of Alternate Encoding vulnerabilities
- 7.4 High severity
Red Hat Build of Apache Camel 3.33.3.SP2: Improper Handling of Alternate Encoding
A flaw was found in WildFly Elytron. Password hashing and verification normalize input with Unicode NFKC, which can collapse fullwidth characters to ASCII equivalents. A remote attacker can more easily guess affected passwords by using an ASCII-only dictionary
- 9.1 Critical severity
Eclipse Jetty - EE8: Improper Handling of Alternate Encoding
In Eclipse Jetty, the Digest authentication server-side component uses ISO-8859-1 to encode the password as bytes. This was done because the initial specification for HTTP did not specify explicitly a charset, and it was assumed to be ISO-8859-1 for historical