CVE-2026-57053

Description

A flaw was found in GNU libidn. This vulnerability allows an attacker to cause out-of-bounds reads of uninitialized memory within the ToUnicode APIs due to mishandling in the idna_to_unicode_internal function. This could lead to information disclosure or a denial of service.

Statement

This flaw resides in GNU libidn's idna_to_unicode_internal() function, used by the idna_to_unicode_* API family. The function assumes its internal ToASCII comparison buffer always begins with the "xn--" ACE prefix. When a decoded label is pure ASCII and shorter than four characters, no prefix is added, and the round-trip verification instead reads past the buffer's null terminator into uninitialized stack memory. Under certain call sequences that leave matching residual data on the stack, this allows an ACE-encoded label that should fail validation to be silently accepted and normalized to a different, shorter string, which could affect domain-based security decisions (allow/deny-list matching, hostname comparisons, routing, logging) made by applications relying on the result.

This flaw does not affect libidn2. Its round-trip verification in lookup.c never assumes the "xn--" prefix is present on caller-supplied data; every prefix-relative offset is either guarded by an explicit prefix check beforehand or applied to a buffer the function itself just wrote the prefix into, and it compares the full label rather than a bare suffix.

Mitigation

No configuration-level mitigation is available; triggering the incorrect result depends on uninitialized stack content from earlier processing, so behavior is non-deterministic and cannot be reliably suppressed via input filtering. Users should update to a fixed libidn package once available. Applications that must process untrusted internationalized domain names before a fix is available should treat output of idna_to_unicode_8z8z()/idna_to_unicode_8zlz() as unverified, perform an independent comparison against the original ACE-encoded input, or use libidn2 for IDNA processing, which is not affected.

Common Vulnerability Scoring System (CVSS) Score Details

Info alert:Important note

CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).

CVSS v3 Score Breakdown

Red HatNVDcve.org
Base Score2.92.54
Attack VectorLocalLocalLocal
Attack ComplexityHighHighHigh
Privileges RequiredNoneLowNone
User InteractionNoneNoneNone
ScopeUnchangedUnchangedUnchanged
ConfidentialityNoneNoneNone
Integrity ImpactLowLowLow
Availability ImpactNoneNoneLow

Vector

Red Hat: CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

NVD: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N

cve.org: CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Understanding the Weakness (CWE)

Confidentiality

Technical Impact: Read Memory

An attacker could get secret values such as cryptographic keys, PII, memory addresses, or other information that could be used in additional attacks.

Confidentiality

Technical Impact: Bypass Protection Mechanism

Out-of-bounds memory could contain memory addresses or other information that can be used to bypass ASLR and other protection mechanisms in order to improve the reliability of exploiting a separate weakness for code execution.

Availability

Technical Impact: DoS: Crash, Exit, or Restart

An attacker could cause a segmentation fault or crash by causing memory to be read outside of the bounds of the buffer. This is especially likely when the code reads a variable amount of data and assumes that a sentinel exists to stop the read operation, such as a NUL in a string.

Other

Technical Impact: Varies by Context

The read operation could produce other undefined or unexpected results.

Frequently Asked Questions

Want to get errata notifications? Sign up here.