CVE-2026-110675 in Cpanel::JSON::XS
Summary
by MITRE • 10/19/2026
Cpanel::JSON::XS versions from 4.33 before 4.80 for Perl accept malformed UTF-8 in bare hash keys under allow_barekey in decode_hv.
With utf8 and allow_barekey, which relaxed enables, a quoted key is validated as UTF-8 but a bare key's bytes are stored as a UTF-8 flagged string without any check. Malformed UTF-8, control bytes and backslashes reach the decoded hash, while malformed UTF-8 and control bytes in a quoted key or a value are rejected.
Later operations on the key, including lc, uc or encoding the hash again, die with a malformed UTF-8 error.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in Cpanel::JSON::XS versions prior to 4.80 represents a significant input validation failure within the Perl JSON parsing library. This flaw specifically affects the handling of bare keys when the allow_barekey configuration option is enabled alongside UTF-8 encoding support. In standard JSON processing, string values and quoted object keys are subject to strict syntax rules that include proper escaping and valid character sequences. However, this implementation exhibits an inconsistency where quoted keys undergo rigorous validation as valid UTF-8 strings, while bare keys bypass these checks entirely. When a user provides input with the allow_barekey flag set, the parser accepts raw byte sequences for unquoted object keys without verifying their structural integrity or encoding validity. This discrepancy creates a pathway for malformed data to infiltrate the internal data structures of the application relying on this library.
The technical root cause lies in how the decode_hv function processes hash entries under specific relaxed parsing modes. While quoted strings are parsed through routines that enforce UTF-8 compliance and reject control characters or invalid byte sequences, bare keys are treated as raw bytes and immediately flagged as valid UTF-8 without actual validation of their content. This allows malformed UTF-8 sequences, including null bytes and other control characters, to be stored directly into the hash key slots. Furthermore, backslashes within these bare keys are not escaped or processed according to JSON standards, leading to potential interpretation ambiguities when the data is subsequently serialized or manipulated. The lack of sanitization means that arbitrary binary data can be embedded in what should be a structured text-based format, violating the fundamental assumptions made by downstream code about the nature and safety of hash keys.
The operational impact of this vulnerability manifests primarily through denial-of-service conditions triggered during subsequent string operations on the affected hashes. When application logic attempts to perform case-insensitive comparisons using functions like lc or uc, or when the data structure is re-encoded into JSON format for transmission or storage, Perl's internal UTF-8 handling mechanisms detect the invalid byte sequences embedded in the keys. This detection results in fatal runtime errors that terminate the executing process. For web applications or API services utilizing Cpanel::JSON::XS to parse incoming requests, this can lead to immediate service disruption if an attacker crafts a malicious JSON payload containing malformed bare keys. The inconsistency between how quoted and unquoted inputs are handled also complicates security auditing, as standard input validation filters may pass these payloads through because they do not trigger the same error paths as invalid quoted strings.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, specifically regarding the failure to validate character encoding constraints during parsing. It also relates to CWE-754 Improper Check for Unusual or Exceptional Conditions, as the library fails to handle edge cases in byte sequence validity before marking strings as valid UTF-8. In terms of attack vectors, this could be leveraged within ATT&CK technique T1059 Command and Scripting Interpreter if an attacker can influence script execution flow through crash-induced state changes or memory corruption scenarios, although the primary impact here is availability rather than code execution. The vulnerability underscores the importance of consistent validation logic across all input types in security-critical libraries.
To mitigate this risk, organizations must upgrade Cpanel::JSON::XS to version 4.80 or later where these parsing inconsistencies have been resolved and bare keys are subjected to the same UTF-8 validity checks as quoted strings. Until an update can be applied, developers should implement strict input filtering at the application layer to reject JSON payloads containing unquoted object keys if such usage is not strictly required by business logic. Additionally, wrapping JSON decoding operations in error handling blocks that catch fatal exceptions related to malformed encoding can prevent process crashes and allow for graceful degradation or rejection of malicious inputs. Regular security assessments should include fuzzing tests targeting edge cases in string parsing libraries to identify similar inconsistencies before they are exploited in production environments.