CVE-2026-124539: JSON::XS versions before 4.05 for Perl leak the decoded key of an object rejected for a missing colon in decode_hv

Q: What kind of deployment is most exposed to this issue?

Long-running Perl processes that decode JSON from requests or other untrusted inputs are most exposed. The process retains one decoded key for each malformed document that reaches the missing-colon error path, allowing repeated inputs to exhaust memory.

Q: What must an attacker send to trigger the memory leak?

They must cause JSON::XS to decode an object with a quoted key that is followed by a missing colon. The key must not be short plain ASCII, because other quoted keys are decoded into a new scalar that is not freed when this parse error occurs.

Q: How can I determine whether a process may already be affected?

Look for a long-running process using JSON::XS before 4.05 that has processed malformed JSON objects missing a colon after a quoted, non-short-plain-ASCII key. Increasing memory use after repeated failed decode operations is consistent with the described behavior.

Q: What can be done if upgrading is not immediately possible?

Prevent untrusted senders from repeatedly submitting malformed JSON, especially objects with quoted non-ASCII or otherwise non-short-plain-ASCII keys lacking a colon. Restarting an affected long-running process releases memory retained from prior failed decodes, but does not prevent further leaks.

Published Nov 14, 2026

Updated

JSON::XS versions before 4.05 for Perl leak the decoded key of an object rejected for a missing colon in decodehv.

Unless it is short plain ASCII, a quoted key is decoded into a new scalar. Nothing frees that scalar when the object is rejected for a missing ':' after the key.

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.

Affected Software

4 affected components

debian/libjson-xs-perl*

debian/libjson-xs-perl<=4.040-1~deb12u1, <=4.040-1~deb13u1, <=4.040-1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade JSON-XS to a version that resolves this vulnerability.
Fixed in 4.05

Event History

Nov 14, 2026

CVE Published

via MITRE·11:52 AM

Data Sourced

via MITRE·11:52 AM

RemedyDescriptionWeakness

Data Sourced

via NVD·12:17 PM

DescriptionWeakness

Data Sourced

via OSV·12:17 PM

DescriptionAffected Software

Frequently Asked Questions

What kind of deployment is most exposed to this issue?

Long-running Perl processes that decode JSON from requests or other untrusted inputs are most exposed. The process retains one decoded key for each malformed document that reaches the missing-colon error path, allowing repeated inputs to exhaust memory.

What must an attacker send to trigger the memory leak?

They must cause JSON::XS to decode an object with a quoted key that is followed by a missing colon. The key must not be short plain ASCII, because other quoted keys are decoded into a new scalar that is not freed when this parse error occurs.

How can I determine whether a process may already be affected?

Look for a long-running process using JSON::XS before 4.05 that has processed malformed JSON objects missing a colon after a quoted, non-short-plain-ASCII key. Increasing memory use after repeated failed decode operations is consistent with the described behavior.

What can be done if upgrading is not immediately possible?

Prevent untrusted senders from repeatedly submitting malformed JSON, especially objects with quoted non-ASCII or otherwise non-short-plain-ASCII keys lacking a colon. Restarting an affected long-running process releases memory retained from prior failed decodes, but does not prevent further leaks.

CVE-2026-124539: JSON::XS versions before 4.05 for Perl leak the decoded key of an object rejected for a missing colon in decode_hv

Affected Software

Remediation

Event History

Frequently Asked Questions

What kind of deployment is most exposed to this issue?

What must an attacker send to trigger the memory leak?

How can I determine whether a process may already be affected?

What can be done if upgrading is not immediately possible?

Company

Resources

Contact

Frequently Asked Questions

What kind of deployment is most exposed to this issue?

What must an attacker send to trigger the memory leak?

How can I determine whether a process may already be affected?

What can be done if upgrading is not immediately possible?