URI versions before 5.36 for Perl encode non-NFC host names to non-standard punycode labels via missing normalization in nameprep.
nameprep lowercases each host label but performs no Unicode normalization. IDNA requires a label to be normalized to Form C before it is encoded (RFC 5891), so a label that is not already in NFC is encoded to a different A-label than its normalized form. A label built from the precomposed Devanagari sequence U+0958 U+093E encodes to xn–72b5c without normalization but to xn–11b2fg after NFC normalization, and xn–72b5c does not round-trip back to the original label.
Any caller that reads host() from a URI built from untrusted input and uses it for a security decision (an allow or deny list, an SSRF filter, deduplication, a cache key) sees the non-standard label, while a client that fetches the same URL resolves the NFC form, so the check and the fetch can disagree about the host.
Weakness
The product receives an input value that is used as a resource identifier or other type of reference, but it does not validate or incorrectly validates that the input is equivalent to a potentially-unsafe value.
Affected Software
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Red Hat Enterprise Linux 10 | RedHat | perl-URI-0:5.27-3.el10_2.1 | * |
| Red Hat Enterprise Linux 8 | RedHat | perl-URI-0:1.73-4.el8_10 | * |
| Red Hat Enterprise Linux 9 | RedHat | perl-URI-0:5.09-3.el9_8.1 | * |
| Red Hat OpenShift Container Platform 4.22 | RedHat | openshift/ose-rhel-coreos-9:4.22.9.8.202610241758-0 | * |
| Red Hat Cost Management On-Premise 1 | RedHat | costmanagement/costmanagement-ui-rhel10:1792605272 | * |
| Red Hat Update Infrastructure 5 | RedHat | rhui5/rhua-rhel9:1793005812 | * |
| Liburi-perl | Ubuntu | upstream | * |
Extended Description
Attackers can sometimes bypass input validation schemes by finding inputs that appear to be safe, but will be dangerous when processed at a lower layer or by a downstream component. For example, a simple XSS protection mechanism might try to validate that an input has no “” tags using case-sensitive matching, but since HTML is case-insensitive when processed by web browsers, an attacker could inject “” and trigger XSS.
Potential Mitigations
- 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.