The vulnerability stems from two distinct but related issues in the brace-expansion library, both leading to a denial-of-service. The analysis of the provided patches reveals that the core of the problem lies in the expand (or expand_) and expandSequence functions.
-
Memory Exhaustion in expand/expand_: The advisory points out that the maxLength mitigation from a previous CVE was incomplete. The patches confirm this. The vulnerable code recursively expanded comma-separated parts ({a,b,c}) and aggregated the results into an intermediate array. The maxLength check was only performed after this array was fully constructed. The fix, as seen in commits 1e30c930238d7162802d88a94189182def178dac and 688a99eeaab02627c2b89ba8ba4821fecfa659cf, was to introduce a running total of the length of the intermediate array (valuesLength) and check it against maxLength within the loop that gathers the results. This prevents the intermediate array from growing uncontrollably.
-
CPU Exhaustion in expandSequence: The second issue was in the expandSequence function, which generates numeric or alphabetic sequences. The function's loop was bounded by the number of results (max) but not the total character length. For padded sequences like {00001..10000}, the function would generate a large number of very long strings, consuming significant CPU time, only for most of them to be discarded later. The patch adds a maxLength parameter to expandSequence and checks the accumulated length within the generation loop, stopping early if the limit is reached.
Both vulnerabilities are addressed by applying bounds checks earlier in the expansion process, on intermediate data structures, rather than just on the final combined output. Any application using brace-expansion to process untrusted input would be susceptible to either a process crash via memory exhaustion or a stall via CPU exhaustion. The functions expand, expand_, and expandSequence would be the primary indicators in a runtime profile during exploitation.