Update Java to 21 and kotlinc to 2.4

[mottljan]

Also fix some other issues

[github-actions]

🔍 Vulnerabilities of ackee/gitlab-builder-android:pr

📦 Image Reference ackee/gitlab-builder-android:pr

digest	sha256:1fd18241256fd2fc06d5c3b141795d28414c14ad9b6284e4441ffcbc919f57cb
vulnerabilities
platform	linux/amd64
size	749 MB
packages	806

org.bouncycastle/bcprov-jdk18on 1.79 (maven) pkg:maven/org.bouncycastle/[email protected] Reusing a Nonce, Key Pair in Encryption Affected range >=1.59 <=1.80.1 Fixed version 1.80.2 CVSS Score 9.3 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/RE:M/U:Red EPSS Score 0.313% EPSS Percentile 23rd percentile Description 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).

undici 7.3.0 (npm) pkg:npm/[email protected] Uncaught Exception Affected range >=7.0.0 <7.24.0 Fixed version 7.24.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.874% EPSS Percentile 55th percentile Description Impact The undici WebSocket client is vulnerable to a denial-of-service attack due to improper validation of the server_max_window_bits parameter in the permessage-deflate extension. When a WebSocket client connects to a server, it automatically advertises support for permessage-deflate compression. A malicious server can respond with an out-of-range server_max_window_bits value (outside zlib's valid range of 8-15). When the server subsequently sends a compressed frame, the client attempts to create a zlib InflateRaw instance with the invalid windowBits value, causing a synchronous RangeError exception that is not caught, resulting in immediate process termination. The vulnerability exists because: The isValidClientWindowBits() function only validates that the value contains ASCII digits, not that it falls within the valid range 8-15 The createInflateRaw() call is not wrapped in a try-catch block The resulting exception propagates up through the call stack and crashes the Node.js process Patches Has the problem been patched? What versions should users upgrade to? Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Improper Validation of Specified Quantity in Input Affected range >=7.0.0 <7.24.0 Fixed version 7.24.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.488% EPSS Percentile 39th percentile Description Impact A server can reply with a WebSocket frame using the 64-bit length form and an extremely large length. undici's ByteParser overflows internal math, ends up in an invalid state, and throws a fatal TypeError that terminates the process. Patches Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later. Workarounds There are no workarounds. Improper Handling of Highly Compressed Data (Data Amplification) Affected range >=7.0.0 <7.24.0 Fixed version 7.24.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 1.150% EPSS Percentile 63rd percentile Description Description The undici WebSocket client is vulnerable to a denial-of-service attack via unbounded memory consumption during permessage-deflate decompression. When a WebSocket connection negotiates the permessage-deflate extension, the client decompresses incoming compressed frames without enforcing any limit on the decompressed data size. A malicious WebSocket server can send a small compressed frame (a "decompression bomb") that expands to an extremely large size in memory, causing the Node.js process to exhaust available memory and crash or become unresponsive. The vulnerability exists in the PerMessageDeflate.decompress() method, which accumulates all decompressed chunks in memory and concatenates them into a single Buffer without checking whether the total size exceeds a safe threshold. Impact Remote denial of service against any Node.js application using undici's WebSocket client A single compressed WebSocket frame of ~6 MB can decompress to ~1 GB or more Memory exhaustion occurs in native/external memory, bypassing V8 heap limits No application-level mitigation is possible as decompression occurs before message delivery Patches Users should upgrade to fixed versions. Workarounds No workaround are possible. Uncontrolled Resource Consumption Affected range >=7.0.0 <7.28.0 Fixed version 7.28.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.759% EPSS Percentile 51st percentile Description Impact The undici WebSocket client enforces maxPayloadSize on the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service. Affected applications are those using the undici WebSocket client (new WebSocket(...)) or the WebSocketStream API that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint. All releases starting at undici 6.17.0 are affected. Patches Upgrade to undici v6.27.0, v7.28.0 or v8.5.0. Workarounds No workaround is available. The fix must be applied through an upgrade.

com.google.protobuf/protobuf-java 2.6.1 (maven) pkg:maven/com.google.protobuf/[email protected] Improper Input Validation Affected range <3.25.5 Fixed version 3.25.5 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 2.772% EPSS Percentile 85th percentile Description Summary When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash. Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team <[email protected]> Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime. Severity CVE-2024-7254 High CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker. Proof of Concept For reproduction details, please refer to the unit tests (Protobuf Java LiteTest and CodedInputStreamTest) that identify the specific inputs that exercise this parsing weakness. Remediation and Mitigation We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: protobuf-java (3.25.5, 4.27.5, 4.28.2) protobuf-javalite (3.25.5, 4.27.5, 4.28.2) protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2) OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <3.16.3 Fixed version 3.16.3, 3.19.6, 3.20.3, 3.21.7 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.483% EPSS Percentile 38th percentile Description A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <3.16.3 Fixed version 3.16.3, 3.19.6, 3.20.3, 3.21.7 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.567% EPSS Percentile 43rd percentile Description A parsing issue similar to CVE-2022-3171, but with textformat in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above. Incorrect Behavior Order Affected range <3.16.1 Fixed version 3.16.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 1.655% EPSS Percentile 74th percentile Description Summary A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data. Reporter: OSS-Fuzz Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected. Severity CVE-2021-22569 High - CVSS Score: 7.5, An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses. Proof of Concept For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness. Remediation and Mitigation Please update to the latest available versions of the following packages: protobuf-java (3.16.1, 3.18.2, 3.19.2) protobuf-kotlin (3.18.2, 3.19.2) google-protobuf [JRuby gem only] (3.19.2)

minimatch 9.0.3 (npm) pkg:npm/[email protected] Inefficient Regular Expression Complexity Affected range >=9.0.0 <9.0.6 Fixed version 10.2.1 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.519% EPSS Percentile 40th percentile Description 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. Inefficient Regular Expression Complexity Affected range >=9.0.0 <9.0.7 Fixed version 9.0.7 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.472% EPSS Percentile 38th percentile Description 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. 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: : 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 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 [email protected], 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: 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: 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. Inefficient Algorithmic Complexity Affected range >=9.0.0 <9.0.7 Fixed version 9.0.7 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.517% EPSS Percentile 40th percentile Description 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: 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 [email protected], Node.js 20. Step 1 -- inline script 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: // 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: // 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.

org.jline/jline-remote-telnet 3.24.1 (maven) pkg:maven/org.jline/[email protected] Uncontrolled Resource Consumption Affected range <4.2.1 Fixed version 4.2.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Description Summary The JLine3 Telnet server (remote-telnet module) does not limit the number of environment variables a client may inject via the Telnet NEW-ENVIRON option. An unauthenticated attacker can flood the server with a large number of unique variable pairs before sending the terminating IAC SE byte, exhausting JVM heap memory and causing an OutOfMemoryError (denial of service). Approximately 3–4 MB of network traffic is sufficient to consume a 512 MB JVM heap. Details TelnetIO.readNEVariables() (TelnetIO.java:1127-1180) processes incoming NEW-ENVIRON variable pairs in a loop and stores each pair in a HashMap held by ConnectionData: // TelnetIO.java:1139-1178 boolean cont = true; if (i == NE_VAR || i == NE_USERVAR) { do { switch (readNEVariableName(sbuf)) { case NE_VAR_OK: TelnetIO.this.connectionData.getEnvironment().put(str, sbuf.toString()); // ← no per-connection count limit break; case NE_VAR_UNDEFINED: break; // cont remains true, loop continues } } while (cont); // cont is never set to false; only exits via return } The variable accumulator map is a plain HashMap initialized with capacity 20 and no maximum size: // ConnectionData.java:98 environment = new HashMap<String, String>(20); Per-variable limits exist (name: max 50 chars, value: max 1000 chars), but there is no cap on the count of variables. Each map entry occupies approximately 2 KB of heap (String headers + Map.Entry + backing char arrays). On a JVM with a 512 MB heap, approximately 250,000 unique entries trigger an OutOfMemoryError. Network cost: using sequential 1-byte names (e.g., \x01, \x02, ...) and 1-byte values, each variable pair requires roughly 13 protocol bytes. Sending 250,000 pairs requires only ~3.25 MB of network traffic — feasible in seconds over any reasonable network connection. No authentication is required. NEW-ENVIRON negotiation occurs before login. Affected source files: remote-telnet/src/main/java/org/jline/builtins/telnet/TelnetIO.java lines 1127-1180 remote-telnet/src/main/java/org/jline/builtins/telnet/ConnectionData.java line 98 PoC Connect to the JLine3 Telnet server and, after completing WILL/DO option negotiation, send a NEW-ENVIRON SEND subneg followed by a single large IS subneg containing thousands of unique variable pairs before the final IAC SE. Protocol structure (no authentication required): Standard Telnet option negotiation (IAC DO NEW-ENVIRON, IAC WILL NEW-ENVIRON) Server sends IAC SB NEW-ENVIRON SEND IAC SE Client responds with: IAC SB NEW-ENVIRON IS [NE_VAR 0x01 NE_VALUE 0x01] ← variable pair 1 [NE_VAR 0x02 NE_VALUE 0x01] ← variable pair 2 ... repeated N times ... IAC SE ← only sent after N pairs Each iteration adds one entry to the per-connection environment map. The connection thread blocks reading from the socket while accumulating pairs, so the attacker controls the timing of the OOM. Reproduction environment: JLine3 built from current master on x86_64 Linux, OpenJDK 25.0.2 remote-telnet module started with its default configuration Confirmed by source-code analysis; loop exit condition and missing count guard verified by inspection of readNEVariables() and ConnectionData constructor Impact Type: Denial of Service (heap memory exhaustion / OutOfMemoryError) Who is affected: Any application embedding the JLine3 remote-telnet module and exposing its Telnet server. No credentials are required. A single connection can exhaust the entire JVM heap, crashing the host process or triggering JVM out-of-memory handling that impacts all users sharing that JVM instance. Credits This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team. Uncontrolled Resource Consumption Affected range <4.2.1 Fixed version 4.2.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Description Summary The JLine3 Telnet server (remote-telnet module) does not apply an upper bound to terminal dimensions received via the Telnet NAWS (Negotiate About Window Size) option. An unauthenticated remote attacker can send a NAWS subnegotiation advertising a 65535×65535 terminal and repeatedly alternate values to trigger continuous, expensive rendering work on the server, causing CPU exhaustion and denial of service. Details TelnetIO.handleNAWS() (TelnetIO.java:856-879) reads the client-supplied width and height as 16-bit unsigned integers and passes them to setTerminalGeometry(): // TelnetIO.java:869-875 private void setTerminalGeometry(int columns, int rows) { if (columns < SMALLEST_BELIEVABLE_WIDTH) columns = DEFAULT_WIDTH; // lower bound only if (rows < SMALLEST_BELIEVABLE_HEIGHT) rows = DEFAULT_HEIGHT; connectionData.setTerminalGeometry(columns, rows); connection.processConnectionEvent( new ConnectionEvent(connection, ConnectionEvent.Type.CONNECTION_TERMINAL_GEOMETRY_CHANGED)); } Only a lower bound is enforced (minimum 20 columns / 6 rows). Values up to 65535 are accepted and stored. The geometry change event propagates to Telnet.java:153-158 where it calls: terminal.setSize(new Size(65535, 65535)); terminal.raise(Signal.WINCH); The WINCH signal triggers LineReaderImpl.handleSignal() → redisplay(). Inside redisplay(), multiple paths iterate up to size.getColumns() times: freshLine() (LineReaderImpl.java:937,953): loops size.getColumns()-1 = 65534 iterations, building and writing a space-padding string across the network socket. columnSplitLength(terminal, size.getColumns(), ...): called multiple times, each processing all characters against the 65535-wide line width. Because WINCH only fires on change, the attacker alternates between two large values (e.g., 65535 and 65534) to trigger an unlimited stream of expensive render cycles. No authentication is required; the NAWS option is negotiated before any login sequence. Affected source files: remote-telnet/src/main/java/org/jline/builtins/telnet/TelnetIO.java lines 856-879 remote-telnet/src/main/java/org/jline/builtins/telnet/Telnet.java lines 140-175 reader/src/main/java/org/jline/reader/impl/LineReaderImpl.java lines 929-962, 1293-1313 PoC Send the following two raw Telnet packets in a loop to a running JLine Telnet server. No login or authentication is required. Packet 1 — NAWS 65535 × 65535: FF FA 1F FF FF FF FF FF F0 (IAC SB NAWS 0xFF 0xFF 0xFF 0xFF IAC SE) Packet 2 — NAWS 65534 × 65534: FF FA 1F FF FE FF FE FF F0 (IAC SB NAWS 0xFF 0xFE 0xFF 0xFE IAC SE) Sending these alternately at ~10 packets/second is sufficient to peg one CPU core on the server. The server remains in this state for as long as the connection is open. Reproduction environment: JLine3 built from current master on x86_64 Linux, OpenJDK 25.0.2 remote-telnet module started with its default Telnet server configuration Test confirmed by source-code analysis and tracing the call chain at runtime Impact Type: Denial of Service (CPU exhaustion) Who is affected: Any application that embeds the JLine3 remote-telnet module and exposes its Telnet server on a network interface. The attacker requires no credentials. A single connection making ~10 alternating NAWS packets per second fully occupies the connection-handling thread and produces continuous I/O on the server's output stream. Because connection threads are re-used for the life of the session, one attacker per available connection slot can deny service to all users of that slot. Credits This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.

org.codehaus.plexus/plexus-utils 3.4.1 (maven) pkg:maven/org.codehaus.plexus/[email protected] Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <3.6.1 Fixed version 4.0.3 EPSS Score 0.663% EPSS Percentile 47th percentile Description Directory Traversal vulnerability in the extractFile method of org.codehaus.plexus.util.Expand in plexus-utils before 6d780b3378829318ba5c2d29547e0012d5b29642. This allows an attacker to execute arbitrary code

commons-io/commons-io 2.11.0 (maven) pkg:maven/commons-io/[email protected] Uncontrolled Resource Consumption Affected range >=2.0 <2.14.0 Fixed version 2.14.0 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 1.249% EPSS Percentile 66th percentile Description 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.