Live › vulnerability › CVE-2026-110676
Go to dashboardCpanel::JSON::XS before 4.80 expands a JSON number with a large exponent into its full decimal form when it is encoded under allow_bignum. A 12-byte input such as [1e30000000] becomes about 30 MB, so untrusted input decoded and re-encoded can exhaust memory and CPU.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Applications that decode untrusted JSON with allow_bignum enabled and then encode the result again are exposed. Services that only decode without bignum, or that never re-encode attacker-supplied numbers, are unlikely to be affected.
No product ranges from the sources yet.
perl -MCpanel::JSON::XS -e 'print $Cpanel::JSON::XS::VERSION'allow_bignum and check whether decoded untrusted JSON is passed back to an encoder4.80 or laterallow_bignumEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-110676")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.