CVE-2026-110674 in Cpanel::JSON::XS
Summary
by MITRE • 10/19/2026
Cpanel::JSON::XS versions from 4.33 before 4.80 for Perl miss duplicate non-ASCII bare keys, allowing type confusion under dupkeys_as_arrayref in decode_hv.
With allow_barekey, which relaxed enables, a bare key containing a non-ASCII byte is stored as UTF-8 but looked up as raw bytes, so a repeated key escapes the duplicate-key check and replaces the earlier value.
From 4.41, under dupkeys_as_arrayref, a bare repeat replaces the array that collects a key's values with a plain value, and the next quoted repeat pushes onto that value as if it were an array. A JSON integer there is dereferenced as a pointer.
Untrusted JSON decoded with relaxed and dupkeys_as_arrayref can crash the process or dereference an address chosen by a JSON number.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in Cpanel::JSON::XS versions ranging from 4.33 to just before 4.80 represents a critical type confusion flaw within the Perl module's hash value decoding logic, specifically triggered when processing untrusted JSON input under specific relaxed parsing configurations. This issue stems from an inconsistency in how bare keys containing non-ASCII bytes are handled during storage versus lookup operations. When the allow_barekey option is enabled, which relaxes standard JSON syntax requirements to permit unquoted strings as object keys, a bare key with non-ASCII characters is internally stored using UTF-8 encoding. However, subsequent lookups for this same key utilize raw byte sequences rather than the encoded form. This discrepancy allows an attacker to craft duplicate keys that appear identical during storage but distinct during lookup checks, effectively bypassing mechanisms designed to detect and handle repeated keys within JSON objects.
The operational impact of this flaw is severe due to its interaction with the dupkeys_as_arrayref configuration option introduced in version 4.41. Under normal circumstances, when multiple values are associated with a single key under this setting, they should be collected into an array reference for safe retrieval. However, because the duplicate-key check fails to recognize repeated non-ASCII bare keys due to the encoding mismatch, the first occurrence of such a key initializes an array reference to hold its values. A subsequent, logically identical but byte-different repeat replaces this entire array structure with a plain scalar value rather than appending to it. This substitution creates a state where the data structure expected by subsequent parsing steps is fundamentally corrupted.
The exploitation vector becomes critical when a third occurrence of the key follows these initial manipulations. The parser attempts to push additional values onto what it believes is an array reference, but instead operates on the plain scalar value left behind by the second duplicate. If this scalar happens to contain or be interpreted as a JSON integer, the Perl interpreter may attempt to dereference that integer address directly. This action leads to undefined behavior, typically resulting in process crashes due to segmentation faults caused by invalid memory access. In more sophisticated scenarios involving crafted numeric values, an attacker could potentially influence pointer arithmetic or cause arbitrary code execution if specific heap layouts and architecture-specific behaviors align favorably with the malformed data structure.
From a classification perspective, this vulnerability maps closely to CWE-841 Improper Enforcement of Behavioral Workflow, as the application fails to correctly enforce the expected state transitions for duplicate key handling under relaxed parsing rules. It also relates to CWE-20 Improper Input Validation because the module does not adequately normalize or validate input keys before performing structural operations that depend on their identity. Furthermore, this behavior aligns with ATT&CK technique T1568 Dynamic Resolution, where an attacker uses encoded or obfuscated inputs to bypass security controls and manipulate internal program logic for malicious effect. The root cause lies in the lack of consistent string normalization across different stages of JSON decoding, allowing type confusion that undermines memory safety guarantees within the Perl runtime environment.
Mitigation strategies must prioritize immediate upgrading to Cpanel::JSON::XS version 4.80 or later, where this encoding inconsistency and subsequent type confusion have been resolved by ensuring uniform handling of bare keys regardless of their byte content. For environments unable to upgrade immediately, strict input validation should be implemented at the application layer to reject JSON payloads containing non-ASCII characters within unquoted key fields if such usage is not strictly required. Additionally, disabling the dupkeys_as_arrayref option or restricting allow_barekey configurations can reduce the attack surface by preventing the specific code paths that lead to the array-to-scalar replacement vulnerability. Security monitoring should also be enhanced to detect unusual process terminations or memory access violations associated with JSON parsing modules, as these may indicate active exploitation attempts targeting this type confusion flaw.