CVE-2026-19954: Net::Whois::Raw Information Disclosure Flaw

CVE-2026-19954 Overview

CVE-2026-19954 affects the pwhois command-line tool shipped with the Perl module Net::Whois::Raw in versions before 2.99044. The tool queries WHOIS for the wrong domain when a user supplies an internationalized domain name (IDN). The flaw stems from incorrect Internationalized Domain Names in Applications (IDNA) processing: pwhois passes each non-ASCII label directly to Net::IDN::Punycode and prepends xn--, skipping the IDNA mapping and normalization steps required by RFC 5891 Section 5.2. The underlying Net::Whois::Raw library modules are not affected.

Critical Impact
Users receive WHOIS data for a different domain than the one they intended to query, which can mislead investigations, incident response, and automated tooling that relies on pwhois output.

Affected Products

Net::Whois::Raw for Perl, versions prior to 2.99044 (the pwhois command-line tool)
Downstream Perl distributions and scripts that invoke pwhois for IDN lookups
Workflows that rely on pwhois output for abuse, fraud, or threat intelligence analysis

Discovery Timeline

2026-10-05 - CVE-2026-19954 published to the National Vulnerability Database
2026-10-05 - Issue disclosed on the Openwall OSS-Security mailing list
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-19954

Vulnerability Analysis

The vulnerability is an incorrect encoding issue [CWE-176] in the pwhois wrapper script. IDNA defines a two-step process: first map and normalize the input Unicode label (case folding, NFC normalization, disallowed character checks), then Punycode-encode the resulting U-label into an A-label prefixed with xn--. The pwhois tool only lowercases ASCII and Cyrillic letters before invoking Net::IDN::Punycode::encode_punycode, bypassing full IDNA mapping and Unicode normalization.

As a result, a label containing uppercase non-ASCII characters, combining characters, or codepoints that are not in Normalization Form C (NFC) is encoded to a Punycode string that differs from its correct IDNA A-label. The advisory cites the example of a label consisting of U+00C9 (Latin capital letter E with acute) followed by cole, which pwhois encodes as xn--cole-pka instead of the IDNA-correct xn--cole-9oa.

Root Cause

The root cause is that pwhois treats Punycode encoding as equivalent to IDNA encoding. The upstream Net::IDN::Punycode warning explicitly states that Punycode alone is not IDNA. By skipping the mapping and normalization phases, the tool produces A-labels that do not match the label a browser or resolver would generate for the same user input.

Attack Vector

Exploitation requires user interaction: a victim must run pwhois against an attacker-chosen IDN or against a legitimate IDN that an attacker has registered the mis-encoded variant of. Because the resulting A-label points to a different domain, an attacker can pre-register the mis-encoded name and serve crafted WHOIS data. This can mislead analysts investigating abuse, phishing, or trademark infringement, and can corrupt downstream automation that pivots on WHOIS fields such as registrant, nameservers, or registrar.

No verified exploit code is published. The vulnerability mechanism and corrective patch are documented in the MetaCPAN patch for CVE-2026-19954 and GitHub Pull Request #35.

Detection Methods for CVE-2026-19954

Indicators of Compromise

Presence of pwhois from Net::Whois::Raw at a version earlier than 2.99044 on analyst workstations or automation hosts.
WHOIS query logs containing A-labels produced from uppercase or non-NFC Unicode input that differ from the labels generated by a browser or idn2 for the same source string.
Investigation artifacts referencing registered domains whose A-labels are visually similar but not identical to the IDN an analyst believed they queried.

Detection Strategies

Inventory Perl environments with cpan -l | grep Net::Whois::Raw or corelist tooling and flag any installation below 2.99044.
Compare pwhois output against a reference IDNA implementation such as idn2 --quiet for a representative set of IDNs; mismatches indicate a vulnerable build.
Review shell history, scheduled jobs, and SOAR playbooks for invocations of pwhois to identify where incorrect data may have influenced downstream decisions.

Monitoring Recommendations

Monitor package management events (cpan, cpanm, distribution package managers) for installations or upgrades of Net-Whois-Raw and alert when the installed version is below 2.99044.
Log outbound WHOIS traffic from investigation hosts and correlate queried domains against the IDN inputs analysts supplied.
Track newly registered IDNs that are mis-encodings of high-value brand or infrastructure domains, as these are candidates for abuse of this flaw.

How to Mitigate CVE-2026-19954

Immediate Actions Required

Upgrade Net::Whois::Raw to version 2.99044 or later on every host where pwhois is installed.
Audit recent WHOIS-driven investigations and automation output for IDN inputs, and re-query any affected domains using a patched tool.
Restrict pwhois use to patched systems and remove the binary from shared analyst images that cannot be updated immediately.

Patch Information

The fix is released in Net-Whois-Raw version 2.99044 on CPAN. Refer to the MetaCPAN change log for Net-Whois-Raw, the GitHub Pull Request #35, and the MetaCPAN patch for CVE-2026-19954. The patch replaces the bare Punycode call with a full IDNA encoding path that performs mapping and NFC normalization before Punycode conversion, aligning behavior with RFC 5891 Section 5.2.

Workarounds

Pre-encode IDN inputs with a compliant IDNA tool such as idn2 and pass the resulting A-label to pwhois instead of the Unicode form.
Replace pwhois in scripts with a direct call to Net::Whois::Raw library functions combined with Net::IDN::Encode::domain_to_ascii, which performs full IDNA processing.
Disable or remove pwhois from production investigation pipelines until the host is upgraded to 2.99044 or later.