Vulnerabilities

8 via 8 paths

Dependencies

20

Source

GitHub

Find, fix and prevent vulnerabilities in your code.

Severity
  • 7
  • 1
Status
  • 8
  • 0
  • 0

high severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: brace-expansion
  • Introduced through: brace-expansion@4.0.1

Detailed paths

  • Introduced through: vscode-fileutils@sleistner/vscode-fileutils › brace-expansion@4.0.1
    Remediation: Upgrade to brace-expansion@5.0.8.

Overview

brace-expansion is a Brace expansion as known from sh/bash

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the expand() function and its recursive expand_ helper, which cap the number of results via the max option but do not bound the length of each result string. An attacker can crash the Node process with a fatal, uncatchable out-of-memory error by supplying a pattern that chains many brace groups, such as {a,b} repeated, keeping the result count under max while each result grows with the group count so total output scales unbounded. Exploitation requires the application to pass untrusted input to expand(), directly or transitively through minimatch or glob brace patterns.

Workaround

This vulnerability can be avoided by passing small explicit max and maxLength options to expand(), bounding both the number of results and the length of each so total output stays limited.

Remediation

Upgrade brace-expansion to version 1.1.16, 2.1.2, 5.0.8 or higher.

References

high severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: brace-expansion
  • Introduced through: brace-expansion@4.0.1

Detailed paths

  • Introduced through: vscode-fileutils@sleistner/vscode-fileutils › brace-expansion@4.0.1
    Remediation: Upgrade to brace-expansion@5.0.9.

Overview

brace-expansion is a Brace expansion as known from sh/bash

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the expand(), expand_(), combine(), and expandSequence() functions, which bound the accumulator where results are combined but not the intermediate arrays that feed it. An attacker can crash the process with an uncatchable out-of-memory error, or stall the event loop for minutes, by supplying a pattern with many comma-separated alternatives that each receive an independent maxLength allowance and accumulate without a cumulative limit, or a padded sequence whose generation ignores maxLength and does work proportional to max * width. Exploitation requires the application to pass untrusted input to expand(), directly or transitively through a glob or pattern-matching library.

Workaround

This vulnerability can be avoided by passing an explicitly small max together with a small maxLength to expand(), bounding both the result count and length, since a small maxLength alone is insufficient on affected versions where it is applied per alternative rather than cumulatively.

Note: This is a bypass of the fix for the vulnerability described in CVE-2026-14257.

Remediation

Upgrade brace-expansion to version 1.1.18, 2.1.4, 3.0.6, 5.0.9 or higher.

References

high severity

Inefficient Algorithmic Complexity

  • Vulnerable module: brace-expansion
  • Introduced through: brace-expansion@4.0.1

Detailed paths

  • Introduced through: vscode-fileutils@sleistner/vscode-fileutils › brace-expansion@4.0.1
    Remediation: Upgrade to brace-expansion@5.0.7.

Overview

brace-expansion is a Brace expansion as known from sh/bash

Affected versions of this package are vulnerable to Inefficient Algorithmic Complexity via the expand function. An attacker can cause excessive CPU consumption and block the event loop by supplying a specially crafted string containing multiple consecutive non-expanding '{}' brace groups. The max option does not prevent this issue, as it only limits the output size and not the computational workload.

Remediation

Upgrade brace-expansion to version 1.1.16, 2.1.2, 5.0.7 or higher.

References

high severity

Infinite loop

  • Vulnerable module: brace-expansion
  • Introduced through: brace-expansion@4.0.1

Detailed paths

  • Introduced through: vscode-fileutils@sleistner/vscode-fileutils › brace-expansion@4.0.1
    Remediation: Upgrade to brace-expansion@5.0.5.

Overview

brace-expansion is a Brace expansion as known from sh/bash

Affected versions of this package are vulnerable to Infinite loop through the expand function when processing a brace pattern with a zero step value. An attacker can cause the process to hang and exhaust system memory by supplying specially crafted input, such as {1..2..0}. This can lead to significant resource consumption and denial of service.

Workaround

This vulnerability can be mitigated by sanitizing strings passed to expand to ensure a step value of 0 is not used.

Remediation

Upgrade brace-expansion to version 1.1.13, 2.0.3, 3.0.2, 5.0.5 or higher.

References

high severity
new

Uncontrolled Recursion

  • Vulnerable module: brace-expansion
  • Introduced through: brace-expansion@4.0.1

Detailed paths

  • Introduced through: vscode-fileutils@sleistner/vscode-fileutils › brace-expansion@4.0.1
    Remediation: Upgrade to brace-expansion@5.0.11.

Overview

brace-expansion is a Brace expansion as known from sh/bash

Affected versions of this package are vulnerable to Uncontrolled Recursion via uncontrolled recursion in expand_ when processing deeply nested brace patterns. An attacker can supply approximately 6 KB of deeply nested braces (e.g., { repeated ~3,200 times followed by a,b and the matching } characters) to exhaust the native call stack and crash the process with a RangeError: Maximum call stack size exceeded. The max and maxLength bounds do not prevent this because the stack is exhausted during recursive descent into sub-expansions, before the result set grows.

Remediation

Upgrade brace-expansion to version 1.1.20, 2.1.6, 3.0.8, 5.0.11 or higher.

References

high severity
new

Uncontrolled Recursion

  • Vulnerable module: brace-expansion
  • Introduced through: brace-expansion@4.0.1

Detailed paths

  • Introduced through: vscode-fileutils@sleistner/vscode-fileutils › brace-expansion@4.0.1
    Remediation: Upgrade to brace-expansion@5.0.10.

Overview

brace-expansion is a Brace expansion as known from sh/bash

Affected versions of this package are vulnerable to Uncontrolled Recursion via two distinct stack-exhaustion paths in parseCommaParts. In the first, the function recurses on the remainder of the string once per brace group, so a chain of approximately 7,000 groups (~29 KB of input) exhausts the native call stack and throws a RangeError. In the second, push.apply passes one argument per element, meaning a single large comma-separated array inside a brace group overflows the stack at a recursion depth of exactly one, requiring roughly 125,000 comma-separated elements. Neither the max nor maxLength options can bound either path because the crash occurs during parsing, before any expansion takes place.

Remediation

Upgrade brace-expansion to version 1.1.19, 2.1.5, 3.0.7, 5.0.10 or higher.

References

high severity
new

Uncontrolled Recursion

  • Vulnerable module: braces
  • Introduced through: fast-glob@3.3.3

Detailed paths

  • Introduced through: vscode-fileutils@sleistner/vscode-fileutils › fast-glob@3.3.3 › micromatch@4.0.8 › braces@3.0.3

Overview

braces is a Bash-like brace expansion, implemented in JavaScript.

Affected versions of this package are vulnerable to Uncontrolled Recursion in the recursive AST walkers, which lack depth guards. An attacker can supply deeply nested brace patterns that stay within the character limit to exhaust the call stack and crash the Node.js process with an uncaught RangeError.

Remediation

There is no fixed version for braces.

References

medium severity
new

Regular Expression Denial of Service (ReDoS)

  • Vulnerable module: brace-expansion
  • Introduced through: brace-expansion@4.0.1

Detailed paths

  • Introduced through: vscode-fileutils@sleistner/vscode-fileutils › brace-expansion@4.0.1
    Remediation: Upgrade to brace-expansion@5.0.12.

Overview

brace-expansion is a Brace expansion as known from sh/bash

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the expand_ function, which implements a Bash quirk where a brace group followed by a comma set (e.g. {a},b}) causes the parser to rewrite the input string and restart the scan, absorbing one closing brace per pass. Because each pass re-reads the entire string and the string itself grows by approximately 25 characters per rewrite (due to the escClose sentinel), the work is quadratic in the number of trailing braces, allowing an attacker to block the event loop with a small input. An input of the form '{a}' + '}'.repeat(128000) + ',z}' takes approximately 27 seconds to process while producing only two results, and neither the existing max nor maxLength guards can prevent this because the cost is incurred during parsing before any result set is produced.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

  • A The string must start with the letter 'A'
  • (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
  • D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

  1. CCC
  2. CC+C
  3. C+CC
  4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String Number of C's Number of steps
ACCCX 3 38
ACCCCX 4 71
ACCCCCX 5 136
ACCCCCCCCCCCCCCX 14 65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade brace-expansion to version 1.1.21, 2.1.7, 3.0.9, 5.0.12 or higher.

References