Jackson Dataformats Binary
Monthly
Memory-exhaustion denial of service in FasterXML jackson-dataformats-binary affects the Smile binary parser on 2.16.0-and-later releases, where SmileParser buffers an entire JSON object property name in memory through an unconstrained _growArrayTo() call inside _handleLongFieldName() and never calls StreamReadConstraints.validateNameLength(), so the configured maxNameLength is silently ignored for this format. Any remote, unauthenticated attacker whose bytes reach SmileFactory parsing - directly or through an ObjectMapper configured with the Smile module - can embed a single unbounded property name and force heap exhaustion, because maxDocumentLength is also disabled by default (CVSS 3.1: 7.5, AV:N/AC:L/PR:N/UI:N, availability-only impact), leaving upload capacity and available heap as the only practical limits. No public exploit identified at time of analysis, and applications that parse only standard JSON are unaffected since jackson-core's JSON parsers enforce maxNameLength incrementally during name decoding.
Memory-exhaustion denial of service in the FasterXML jackson-dataformats-binary CBOR parser allows an unauthenticated remote attacker to force unbounded heap allocation by submitting a CBOR document containing a single property name of arbitrary length; the parser buffers the entire name in memory before returning it because maxNameLength is never validated for this binary format. The defect affects jackson-dataformats-binary running against jackson-core 2.16.0 or later (releases before 2.16.0 never contained the constraint that is left unenforced), and is reachable under default configuration because StreamReadConstraints.maxDocumentLength is disabled by default, leaving no built-in bound on the name. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) there is no confidentiality or integrity impact, and the practical damage ceiling is set by the attacker's upload capacity versus the victim's available heap; no public exploit code was identified at time of analysis, and exploitation requires only that attacker-controlled bytes actually reach CBORFactory or an ObjectMapper configured with the CBOR module.
Memory-exhaustion denial of service in FasterXML jackson-dataformats-binary affects the Smile binary parser on 2.16.0-and-later releases, where SmileParser buffers an entire JSON object property name in memory through an unconstrained _growArrayTo() call inside _handleLongFieldName() and never calls StreamReadConstraints.validateNameLength(), so the configured maxNameLength is silently ignored for this format. Any remote, unauthenticated attacker whose bytes reach SmileFactory parsing - directly or through an ObjectMapper configured with the Smile module - can embed a single unbounded property name and force heap exhaustion, because maxDocumentLength is also disabled by default (CVSS 3.1: 7.5, AV:N/AC:L/PR:N/UI:N, availability-only impact), leaving upload capacity and available heap as the only practical limits. No public exploit identified at time of analysis, and applications that parse only standard JSON are unaffected since jackson-core's JSON parsers enforce maxNameLength incrementally during name decoding.
Memory-exhaustion denial of service in the FasterXML jackson-dataformats-binary CBOR parser allows an unauthenticated remote attacker to force unbounded heap allocation by submitting a CBOR document containing a single property name of arbitrary length; the parser buffers the entire name in memory before returning it because maxNameLength is never validated for this binary format. The defect affects jackson-dataformats-binary running against jackson-core 2.16.0 or later (releases before 2.16.0 never contained the constraint that is left unenforced), and is reachable under default configuration because StreamReadConstraints.maxDocumentLength is disabled by default, leaving no built-in bound on the name. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) there is no confidentiality or integrity impact, and the practical damage ceiling is set by the attacker's upload capacity versus the victim's available heap; no public exploit code was identified at time of analysis, and exploitation requires only that attacker-controlled bytes actually reach CBORFactory or an ObjectMapper configured with the CBOR module.