CVE-2026-110687 in Cpanel::JSON::XS
Summary
by MITRE • 10/19/2026
Cpanel::JSON::XS versions from 4.43 before 4.80 for Perl misorder byte-string keys during canonical encoding in utf16_cmp.
canonical sorts keys by UTF-16 code units. When any key in a hash is UTF-8 flagged, every key is decoded as UTF-8 for the comparison, including byte-string keys that the encoder writes out as Latin-1 characters. A byte-string key whose bytes are valid UTF-8 is sorted out of order, and two keys that encode differently can compare equal and are left in hash order.
The same data can encode to different canonical documents across processes.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/19/2026
Cpanel::JSON::XS versions ranging from 4.43 up to but not including 4.80 for the Perl programming language contain a critical logic flaw within its UTF-16 comparison function, specifically affecting how hash keys are sorted during canonical JSON encoding. The vulnerability stems from an incorrect handling of character encodings when determining the sort order of object keys. Canonical JSON requires that all keys in an object be sorted lexicographically to ensure deterministic output, which is essential for data integrity and verification processes such as digital signing or hashing. In this implementation, the sorting mechanism relies on UTF-16 code units for comparison. However, the logic fails to properly distinguish between byte-string keys and those explicitly flagged as UTF-8 encoded strings within Perl's internal representation.
The technical root cause involves a flaw in how the encoder processes mixed encoding types within a single hash structure. When any key in a given hash is marked with the UTF-8 flag, the sorting algorithm incorrectly assumes that all other keys are also valid UTF-8 sequences and proceeds to decode them accordingly for comparison purposes. This behavior is problematic because byte-string keys, which may contain arbitrary binary data or Latin-1 characters, do not necessarily conform to valid UTF-8 structures. Consequently, a byte-string key whose bytes happen to form a valid UTF-8 sequence will be decoded and sorted based on its interpreted Unicode value rather than its raw byte values. This results in the key being placed out of order relative to other keys that should have been compared as raw bytes or distinct string entities.
Furthermore, this encoding mishandling leads to severe consistency issues where two different keys can compare as equal if their UTF-8 decoded representations match, even though they are semantically and structurally distinct in the original data structure. When such equality is falsely detected by the sorting algorithm, these keys remain in their default hash order rather than being sorted according to canonical rules. This breaks the fundamental guarantee of deterministic output provided by canonical JSON encoding. As a direct operational consequence, identical input data structures can produce different canonical JSON documents when processed across different Perl processes or environments where internal string flags might differ due to varying prior operations on the strings.
The impact of this vulnerability extends beyond mere formatting inconsistencies. In security-sensitive applications that rely on canonical JSON for generating hashes, digital signatures, or message authentication codes, such non-determinism can lead to verification failures or acceptance of tampered data if an attacker can manipulate string flags to influence sort order. This aligns with CWE-20 Improper Input Validation and CWE-754 Incorrect Check or Comparison of Exceptional Conditions, as the software fails to correctly validate and handle different character encoding states within a single data structure. From an ATT&CK perspective, this could be leveraged in techniques related to Data Obfuscation (T1001) if an attacker aims to bypass integrity checks by exploiting inconsistent canonicalization across system boundaries.
To mitigate this vulnerability, organizations using Cpanel::JSON::XS must upgrade the module to version 4.80 or later, where the sorting logic has been corrected to properly handle mixed encoding types and ensure that byte-string keys are compared based on their raw bytes rather than being incorrectly decoded as UTF-8. Until an upgrade is feasible, developers should avoid mixing UTF-8 flagged strings with byte-string keys in hashes intended for canonical JSON output or explicitly convert all keys to a consistent encoding before serialization. Additionally, implementing strict input validation and ensuring that external systems expecting canonical JSON are aware of this historical inconsistency can help prevent downstream integrity issues. Regular auditing of data processing pipelines for deterministic behavior is also recommended to detect any anomalies resulting from non-canonical outputs in legacy environments.