Security Advisories (14)
CVE-2026-110672 (2026-10-19)

Cpanel::JSON::XS versions before 4.80 for Perl leak the decoded key of an object rejected for a duplicate key or a missing colon in decode_hv. A quoted key of 24 or more bytes, or one containing a non-ASCII byte or an escape sequence, is decoded into a new scalar. Nothing frees that scalar when the object is rejected for a missing ':' after the key or, from 4.09, for a duplicate key. Duplicate keys are an error unless allow_dupkeys, dupkeys_as_arrayref or relaxed is set. A process that keeps running after a failed decode retains one key per rejected document, with its size chosen by the sender. Repeated requests exhaust process memory.

CVE-2026-110673 (2026-10-19)

Cpanel::JSON::XS versions before 4.80 for Perl allow stack exhaustion via nested tagged values under allow_tags in decode_tag. With allow_tags, "(" starts a tagged value. Its tag and value are decoded recursively, and each can start another tagged value. Unlike arrays and objects, this nesting is not counted against max_depth. A run of "(" bytes exhausts the C stack and triggers an uncatchable segmentation fault regardless of max_depth.

CVE-2026-110674 (2026-10-19)

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.

CVE-2026-110675 (2026-10-19)

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.

CVE-2026-110676 (2026-10-19)

Cpanel::JSON::XS versions before 4.80 for Perl allow memory exhaustion by encoding exponent notation as full decimal digits under allow_bignum. With allow_bignum, a JSON number with a fraction or exponent decodes to a Math::BigFloat, which stores the exponent separately and so decodes cheaply. Encoding it untyped or as JSON_TYPE_FLOAT writes the plain decimal form with one digit per unit of exponent. Nothing bounds the exponent, so the 12-byte text [1e30000000] encodes to 30 MB. Untrusted JSON decoded with allow_bignum and encoded again can exhaust memory and CPU.

CVE-2026-110677 (2026-10-19)

Cpanel::JSON::XS versions from 4.28 before 4.80 for Perl leak the array collecting duplicate key values under dupkeys_as_arrayref in decode_hv. With dupkeys_as_arrayref, the values of a duplicate object key are collected into a new array. An extra reference is never released, so the array and every value in it outlive the decoded structure. The array also leaks when decoding fails after a duplicate key. Repeatedly decoding untrusted JSON with a duplicate key holding a large value exhausts process memory.

CVE-2026-110678 (2026-10-19)

Cpanel::JSON::XS versions before 4.80 for Perl allow memory exhaustion by buffering incremental input past max_size in incr_parse. The parser appends each chunk to its buffer. In scalar or list context, it compares max_size with how far it has progressed, not with the buffer length. A chunk that starts with a NUL byte stops the parser before it progresses, and a call in void context skips the check, so the buffer grows without limit. A peer streaming data to an incr_parse consumer can exhaust process memory regardless of max_size.

CVE-2026-110680 (2026-10-19)

Cpanel::JSON::XS versions from 4.20 before 4.80 for Perl write out of bounds when a tied or shared hash grows during canonical encoding in encode_hv. With canonical, the keys of a tied or threads::shared hash are counted before a second pass collects them for sorting. The encoder uses a fixed 64-entry stack array or, for larger counts, a heap array sized from the first pass. If the second pass exceeds that capacity, entries are written out of bounds before the counts are compared. This corrupts stack or heap memory and can crash the process.

CVE-2026-110681 (2026-10-19)

Cpanel::JSON::XS versions before 4.80 for Perl use the parent interpreter's scalars from a parser object cloned into a new ithread. A parser object holds its callbacks and its incremental parse buffer as raw scalar pointers. When a thread is created, these are copied into the new interpreter unchanged, so the child's parser uses, and later frees, scalars that belong to the parent and may already have been freed there. A parser created before a thread starts and used inside it can call freed callbacks, corrupt reference counts and crash the process.

CVE-2026-110682 (2026-10-19)

Cpanel::JSON::XS versions from 4.42 before 4.80 for Perl let input chunking change the decoded value of top-level numbers in incr_parse. allow_nonref is enabled by default and incr_parse inherits it. A top-level number, true, false or null has no closing delimiter, so the incremental parser decodes whatever has arrived. The bytes 12 decode as one value when read together, but as 1 and then 2 when split across two reads. A peer that can influence read boundaries can change how many messages a stream consumer decodes and what values they carry.

CVE-2026-110684 (2026-10-19)

Cpanel::JSON::XS versions from 3.0202 before 4.80 for Perl leak memory and retain overloaded objects when encoding values as strings in encode_stringify. encode_stringify writes a value in its string form under allow_stringify, under convert_blessed for objects without TO_JSON, and under allow_bignum. For an array or hash object with a "" overload, and from 4.20 a scalar object, it takes an extra reference that is never released, so the object and everything it references are never freed. From 4.10 it also never frees its copy of the string. Repeatedly encoding data that contains such values grows process memory without bound.

CVE-2026-110685 (2026-10-19)

Cpanel::JSON::XS versions before 4.80 for Perl leak the decoded arguments of a tagged value when its THAW method dies in decode_tag. With allow_tags, a tagged value's class name and argument array are decoded and passed to the class's THAW method. Both are released only after THAW returns, so a THAW that dies leaves the whole decoded argument structure allocated. Each rejected document leaks data of a size the sender chooses, so a process that catches the error and keeps running exhausts its memory.

CVE-2026-110686 (2026-10-19)

Cpanel::JSON::XS versions before 4.80 for Perl use freed filter callbacks when a filter removes itself during decoding in decode_hv. A decode copies the parser's filter_json_object and filter_json_single_key_object callbacks without taking references to them. A filter callback that removes the last single-key filter frees the callback table while the decode in progress still uses it. The next object is dispatched through freed memory and can crash the process.

CVE-2026-110687 (2026-10-19)

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.

NAME

Cpanel::JSON::XS::Type - Type support for JSON encode

SYNOPSIS

use Cpanel::JSON::XS;
use Cpanel::JSON::XS::Type;


encode_json([10, "10", 10.25], [JSON_TYPE_INT, JSON_TYPE_INT, JSON_TYPE_STRING]);
# '[10,10,"10.25"]'

encode_json([10, "10", 10.25], json_type_arrayof(JSON_TYPE_INT));
# '[10,10,10]'

encode_json(1, JSON_TYPE_BOOL);
# 'true'

my $perl_struct = { key1 => 1, key2 => "2", key3 => 1 };
my $type_spec = { key1 => JSON_TYPE_STRING, key2 => JSON_TYPE_INT, key3 => JSON_TYPE_BOOL };
my $json_string = encode_json($perl_struct, $type_spec);
# '{"key1":"1","key2":2,"key3":true}'

my $perl_struct = { key1 => "value1", key2 => "value2", key3 => 0, key4 => 1, key5 => "string", key6 => "string2" };
my $type_spec = json_type_hashof(JSON_TYPE_STRING);
my $json_string = encode_json($perl_struct, $type_spec);
# '{"key1":"value1","key2":"value2","key3":"0","key4":"1","key5":"string","key6":"string2"}'

my $perl_struct = { key1 => { key2 => [ 10, "10", 10.6 ] }, key3 => "10.5" };
my $type_spec = { key1 => json_type_anyof(JSON_TYPE_FLOAT, json_type_hashof(json_type_arrayof(JSON_TYPE_INT))), key3 => JSON_TYPE_FLOAT };
my $json_string = encode_json($perl_struct, $type_spec);
# '{"key1":{"key2":[10,10,10]},"key3":10.5}'


my $value = decode_json('false', 1, my $type);
# $value is 0 and $type is JSON_TYPE_BOOL

my $value = decode_json('0', 1, my $type);
# $value is 0 and $type is JSON_TYPE_INT

my $value = decode_json('"0"', 1, my $type);
# $value is 0 and $type is JSON_TYPE_STRING

my $json_string = '{"key1":{"key2":[10,"10",10.6]},"key3":"10.5"}';
my $perl_struct = decode_json($json_string, 0, my $type_spec);
# $perl_struct is { key1 => { key2 => [ 10, 10, 10.6 ] }, key3 => 10.5 }
# $type_spec is { key1 => { key2 => [ JSON_TYPE_INT, JSON_TYPE_STRING, JSON_TYPE_FLOAT ] }, key3 => JSON_TYPE_STRING }

DESCRIPTION

This module provides stable JSON type support for the Cpanel::JSON::XS encoder which doesn't depend on any internal perl scalar flags or characteristics. Also it provides real JSON types for Cpanel::JSON::XS decoder.

In most cases perl structures passed to encode_json come from other functions or from other modules and caller of Cpanel::JSON::XS module does not have control of internals or they are subject of change. So it is not easy to support enforcing types as described in the simple scalars section.

For services based on JSON contents it is sometimes needed to correctly process and enforce JSON types.

The function decode_json takes optional third scalar parameter and fills it with specification of json types.

The function encode_json takes a perl structure as its input and optionally also a json type specification in the second parameter.

If the specification is not provided (or is undef) internal perl scalar flags are used for the resulting JSON type. The internal flags can be changed by perl itself, but also by external modules. Which means that types in resulting JSON string aren't stable. Specially it does not work reliable for dual vars and scalars which were used in both numeric and string operations. See simple scalars.

To enforce that specification is always provided use require_types. In this case when encode is called without second argument (or is undef) then it croaks. It applies recursively for all sub-structures.

JSON type specification for scalars:

JSON_TYPE_BOOL

It enforces JSON boolean in resulting JSON, i.e. either true or false. For determining whether the scalar passed to the encoder is true, standard perl boolean logic is used.

JSON_TYPE_INT

It enforces JSON number without fraction part in the resulting JSON. Equivalent of perl function int is used for conversion.

JSON_TYPE_FLOAT

It enforces JSON number with fraction part in the resulting JSON. Equivalent of perl operation +0 is used for conversion.

JSON_TYPE_STRING

It enforces JSON string type in the resulting JSON.

JSON_TYPE_NULL

It represents JSON null value. Makes sense only when passing perl's undef value.

For each type, there also exists a type with the suffix _OR_NULL which encodes perl's undef into JSON null. Without type with suffix _OR_NULL perl's undef is converted to specific type according to above rules.

JSON type specification for arrays:

[...]

The array must contain the same number of elements as in the perl array passed for encoding. Each element of the array describes the JSON type which is enforced for the corresponding element of the perl array.

json_type_arrayof

This function takes a JSON type specification as its argument which is enforced for every element of the passed perl array.

JSON type specification for hashes:

{...}

Each hash value for corresponding key describes the JSON type specification for values of passed perl hash structure. Keys in hash which are not present in passed perl hash structure are simple ignored and not used.

json_type_hashof

This function takes a JSON type specification as its argument which is enforced for every value of passed perl hash structure.

JSON type specification for alternatives:

json_type_anyof

This function takes a list of JSON type alternative specifications (maximally one scalar, one array, and one hash) as its input and the JSON encoder chooses one that matches.

json_type_null_or_anyof

Like json_type_anyof, but scalar can be only perl's undef.

Recursive specifications

json_type_weaken

This function can be used as an argument for "json_type_arrayof", "json_type_hashof" or "json_type_anyof" functions to create weak references suitable for complicated recursive structures. It depends on the weaken function from Scalar::Util module. See following example:

my $struct = {
    type => JSON_TYPE_STRING,
    array => json_type_arrayof(JSON_TYPE_INT),
};
$struct->{recursive} = json_type_anyof(
    json_type_weaken($struct),
    json_type_arrayof(JSON_TYPE_STRING),
);

If you want to encode all perl scalars to JSON string types despite how complicated is input perl structure you can define JSON type specification for alternatives recursively. It could be defined as:

my $type = json_type_anyof();
$type->[0] = JSON_TYPE_STRING_OR_NULL;
$type->[1] = json_type_arrayof(json_type_weaken($type));
$type->[2] = json_type_hashof(json_type_weaken($type));

print encode_json([ 10, "10", { key => 10 } ], $type);
# ["10","10",{"key":"10"}]

An alternative solution for encoding all scalars to JSON strings is to use type_all_string method of Cpanel::JSON::XS itself:

my $json = Cpanel::JSON::XS->new->type_all_string;
print $json->encode([ 10, "10", { key => 10 } ]);
# ["10","10",{"key":"10"}]

AUTHOR

Pali <pali@cpan.org>

COPYRIGHT & LICENSE

Copyright (c) 2017, GoodData Corporation. All rights reserved.

This module is available under the same licences as perl, the Artistic license and the GPL.