CVE-2026-19954 in Net::Whois::Raw
Summary
by MITRE • 10/05/2026
Net::Whois::Raw versions before 2.99044 for Perl ship a pwhois command-line tool that queries WHOIS for the wrong domain for unicode domain names.
pwhois encodes each non-ASCII label directly using Net::IDN::Punycode and prepends xn--. Apart from lowercasing ASCII and Cyrillic letters, it skips the IDNA mapping and normalization steps, so a label with other uppercase letters, or not in NFC, encodes to a different A-label than its IDNA form. For example, a label of U+00C9 followed by "cole" encodes to "xn--cole-pka" rather than "xn--cole-9oa".
The Net::Whois::Raw library modules are not affected.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in versions of the Perl module Net::Whois::Raw prior to 2.99044 represents a significant flaw in internationalized domain name processing within its accompanying command-line utility, pwhois. This tool is designed to query WHOIS servers for domain registration information, but it fails to correctly handle Unicode domain names due to an incomplete implementation of the Internationalizing Domain Names in Applications (IDNA) standard. The core issue lies in how the application processes non-ASCII characters within domain labels. Instead of adhering to the full IDNA protocol which includes mapping and normalization steps, the tool relies solely on Net::IDN::Punycode encoding while only lowercasing ASCII and Cyrillic letters. This selective processing bypasses critical standardization procedures required for consistent domain name resolution across different systems and registrars.
The technical flaw manifests when labels containing uppercase characters outside of the ASCII or Cyrillic alphabets, or those not in Normalization Form Canonical Composition (NFC), are processed. The application encodes these labels directly using Punycode without applying the necessary IDNA mapping rules that would normalize the input to NFC and map compatibility characters to their canonical equivalents. Consequently, a domain label such as U+00C9 followed by cole is encoded into xn--cole-pka rather than the correct IDNA-compliant form xn--cole-9oa. This discrepancy arises because the Unicode character U+00C9 (Latin Capital Letter E With Acute) has a compatibility decomposition that maps to e with acute in NFC, which then encodes differently under Punycode rules compared to the direct encoding of the precomposed character or other variants. The result is a mismatch between the domain name intended by the user and the actual A-label sent to the WHOIS server.
The operational impact of this vulnerability extends beyond simple query errors. By querying for an incorrect domain, users may receive WHOIS data belonging to a completely different entity or no data at all if the misencoded domain does not exist in public registries. This can lead to significant confusion and potential security risks during incident response activities where accurate domain intelligence is critical. Attackers could potentially exploit this inconsistency through IDN homograph attacks, although the primary risk here is functional rather than direct exploitation for phishing. The discrepancy allows an attacker to register a visually similar but technically distinct internationalized domain name that might evade detection by tools relying on naive Punycode encoding without proper normalization checks. This undermines the reliability of WHOIS lookups which are often used for threat intelligence gathering and asset discovery.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation as it involves failing to properly validate or normalize input data according to established standards before processing. It also relates to CWE-697 Incorrect Comparison since the resulting A-label does not match the expected IDNA-compliant form, leading to incorrect lookups. In terms of MITRE ATT&CK tactics, this flaw could facilitate reconnaissance activities by allowing an adversary to bypass certain normalization-based defenses or mislead automated analysis tools that depend on consistent domain name representations for threat correlation and reporting. The lack of proper IDNA handling means that security monitoring systems relying on WHOIS data might miss connections between related malicious domains if those domains differ only in their Unicode composition but resolve to the same underlying IP address after correct normalization.
Mitigation strategies primarily involve upgrading the Net::Whois::Raw module to version 2.99044 or later, where this issue has been addressed by implementing full IDNA compliance including proper NFC normalization and character mapping before Punycode encoding. For organizations unable to upgrade immediately, it is advisable to validate domain names using a robust internationalization library that adheres strictly to RFC 5891 and RFC 6724 standards before passing them to the pwhois utility. Additionally, security teams should be aware of this limitation when interpreting WHOIS data for internationalized domains during investigations. Implementing additional validation layers at the application level can help ensure that domain names are normalized correctly regardless of the underlying library version in use. This includes checking for NFC normalization and ensuring that all non-ASCII characters are processed through a complete IDNA pipeline rather than just Punycode conversion.