CVE-2026-110676 in Cpanel::JSON::XS
Summary
by MITRE • 10/19/2026
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.
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 prior to 4.80 represents a significant resource exhaustion risk within Perl-based applications that process unstructured data formats. This flaw is rooted in the handling of large numbers when the allow_bignum feature is enabled, which allows JSON parsers to decode numeric values with fractions or exponents into Math::BigFloat objects for precise arithmetic representation. While decoding such values is computationally inexpensive because the exponent is stored separately rather than expanded immediately, the encoding process lacks corresponding safeguards. When a BigFloat object is serialized back into JSON format using untyped serialization or as a JSON_TYPE_FLOAT, the library converts the value into its full decimal string representation. This conversion expands every unit of the exponent into individual digits without any upper bound on the resulting length. Consequently, an input payload such as [1e30000000], which is only twelve bytes in size, can trigger the generation of a thirty-megabyte output string during encoding.
This behavior creates a direct path to denial-of-service conditions through memory exhaustion and excessive CPU utilization. Attackers who can supply untrusted JSON data that triggers this specific encoding pathway can force the application to allocate disproportionate amounts of system resources relative to the size of the input. In web applications or API endpoints that accept user-supplied JSON, an attacker could repeatedly send these optimized payloads to deplete available memory on the server host. This resource consumption can lead to service degradation for legitimate users, potential crashes of the hosting process, and in severe cases, a complete outage if system-level limits are not configured to restrict such allocations effectively. The vulnerability is particularly dangerous because it allows an attacker to amplify small inputs into massive outputs, bypassing typical input size restrictions that might otherwise mitigate simpler buffer overflow or memory exhaustion attacks based on raw data volume.
From a classification perspective, this issue aligns with CWE-400, which covers Uncontrolled Resource Consumption, as the application fails to limit the amount of resources consumed by processing specific inputs. It also relates closely to CWE-789, Memory Exhaustion, due to the unbounded allocation triggered during the serialization phase. In terms of attack tactics, this vulnerability supports techniques associated with MITRE ATT&CK T1496, Resource Hijacking, where an adversary uses computing resources for their own benefit or to disrupt service availability by exhausting system capacity. The exploitation vector typically involves remote network access if the vulnerable JSON parsing functionality is exposed via a web interface or API endpoint that does not strictly validate or sanitize numeric fields before processing them through the bignum-enabled decoder and encoder pipeline.
Mitigation strategies must focus on updating the underlying library to version 4.80 or later, where these encoding bounds have been addressed by the maintainers at cPanel. For environments where immediate patching is not feasible, developers should implement strict input validation that rejects JSON payloads containing excessively large exponents before they reach the parsing logic. Additionally, configuring application-level memory limits and utilizing web server configurations to restrict request body sizes can provide a layer of defense against this specific exploitation technique. It is also advisable to audit codebases for any custom serialization routines that might replicate similar unbounded expansion behaviors when converting high-precision numeric types back into string representations. Regular security assessments should include testing with edge-case numerical inputs to ensure that resource consumption remains proportional to input size, thereby preventing denial-of-service scenarios arising from algorithmic complexity in data transformation processes.