Repository navigation
test(deps): bump @types/node from 26.6.3 to 26.6.4 in the npm group - #1489
dependabot[bot] wants to merge 1 commit into
Conversation
Bumps the npm group with 1 update: [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node). Updates `@types/node` from 26.6.3 to 26.6.4 - [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases) - [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node) --- updated-dependencies: - dependency-name: "@types/node" dependency-version: 26.6.4 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: npm ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
|
📦 Container Size AnalysisNote Comparing 📈 Size Comparison Table
|
✅
|
| Descriptor | Linter | Files | Fixed | Errors | Max errors | Warnings | Elapsed time |
|---|---|---|---|---|---|---|---|
| ✅ ACTION | actionlint | 23 | 0 | 0 | 0.17s | ||
| ✅ DOCKERFILE | hadolint | 4 | 0 | 0 | 0.23s | ||
| ✅ JSON | npm-package-json-lint | yes | no | no | 0.4s | ||
| ✅ JSON | prettier | 50 | 8 | 0 | 0 | 0.81s | |
| ✅ JSON | v8r | 50 | 0 | 0 | 14.0s | ||
| ✅ MARKDOWN | markdownlint | 13 | 0 | 0 | 0 | 0.91s | |
| ✅ MARKDOWN | markdown-table-formatter | 13 | 0 | 0 | 0 | 0.16s | |
| ✅ REPOSITORY | betterleaks | yes | no | no | 1.06s | ||
| ✅ REPOSITORY | checkov | yes | no | no | 25.26s | ||
| ✅ REPOSITORY | git_diff | yes | no | no | 0.01s | ||
| ✅ REPOSITORY | grype | yes | no | no | 86.9s | ||
| osv-scanner | yes | 1 | 8 | 2.53s | |||
| ✅ REPOSITORY | secretlint | yes | no | no | 0.95s | ||
| ✅ REPOSITORY | syft | yes | no | no | 3.33s | ||
| ✅ REPOSITORY | trivy | yes | no | no | 12.66s | ||
| ✅ REPOSITORY | trivy-sbom | yes | no | no | 0.41s | ||
| ✅ REPOSITORY | trufflehog | yes | no | no | 2.81s | ||
| lychee | 123 | 1 | 0 | 8.76s | |||
| ✅ YAML | prettier | 36 | 0 | 0 | 0 | 0.96s | |
| ✅ YAML | v8r | 36 | 0 | 0 | 11.61s | ||
| ✅ YAML | yamllint | 36 | 0 | 0 | 1.13s |
Detailed Issues
⚠️ SPELL / lychee - 1 error
📝 Summary
---------------------
🔍 Total..........154
🔗 Unique.........126
✅ Successful.....148
⏳ Timeouts.........0
🔀 Redirected......19
👻 Excluded.........0
❓ Unknown..........0
🚫 Errors...........1
⛔ Unsupported......1
Errors in .github/TOOL_VERSION_ISSUE_TEMPLATE.md
[403] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads (at 38:7) | Rejected status code: 403 Forbidden
Hint: Followed 19 redirects. You might want to consider replacing redirecting URLs with the resolved URLs. Use verbose mode (`-v`/`-vv`) to see redirection details.
Hint: You can configure accepted/rejected response codes with `-a` or `--accept`
⚠️ REPOSITORY / osv-scanner - 1 error
warning: Package 'brace-expansion@5.0.9' is vulnerable to 'CVE-2026-102276' (also known as 'GHSA-6j4f-fj2g-mc7p').
= CVE-2026-102276: brace-expansion: DoS via uncontrolled recursion in parseCommaParts causing stack exhaustion
= ### 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:
expand('{' + '{a},'.repeat(7000) + 'b}')
// RangeError: Maximum call stack size exceededAbout 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:
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:
expand('{{x},' + 'a,'.repeat(125000) + 'b}')
// RangeError: Maximum call stack size exceededThreshold 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.
warning: Package 'fast-uri@3.1.7' is vulnerable to 'CVE-2026-86472' (also known as 'GHSA-hrr3-gc8f-f4qj').
= CVE-2026-86472: fast-uri vulnerable to inconsistent host case normalization via percent-encoded octets
= ### Impact
fast-uri folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase unreserved octet such as %41 decodes to a literal A that is never folded. For a scheme-relative reference (//host) there is no scheme, so the host canonicalization that repairs this on a scheme-bearing URL does not run. As a result parse, normalize, and equal disagree on the same host: parse("//%41.com").host returns "A.com" while parse("//a.com").host and parse("//A.com").host return "a.com", and equal("//%41.com", "//a.com") is false even though equal("//A.com", "//a.com") is true. An application that makes a case-sensitive host decision on fast-uri output for a scheme-relative reference, for example a host allowlist or denylist that compares parse(url).host or uses fast-uri.equal, can be steered past the check with a percent-encoded uppercase octet. Because a hostname is case-insensitive in DNS and HTTP routing, the evading spelling reaches the same host the check meant to gate, so the effect is check evasion rather than reaching a different registrable host.
Patches
Upgrade to fast-uri 4.1.5, 3.1.8, or 2.4.7.
Workarounds
Compare hosts case-insensitively (lowercase the parsed host before any allowlist or denylist decision), or avoid making case-sensitive host decisions on scheme-relative input until upgrading.
warning: Package 'brace-expansion@5.0.9' is vulnerable to 'CVE-2026-102277' (also known as 'GHSA-q2hr-2g5m-vwhr').
= CVE-2026-102277: brace-expansion: Quadratic-time expansion of the {a},b} rewrite causes CPU denial of service
= ### 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
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.
warning: Package 'brace-expansion@5.0.9' is vulnerable to 'CVE-2026-102278' (also known as 'GHSA-qhr7-859c-m2p7').
= CVE-2026-102278: brace-expansion: DoS via uncontrolled recursion on nested brace groups causing stack exhaustion
= ### 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:
expand('{a,'.repeat(4000) + 'z' + '}'.repeat(4000))
// RangeError: Maximum call stack size exceededCrashes 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:
expand('{'.repeat(3200) + 'a,b' + '}'.repeat(3200))
// RangeError: Maximum call stack size exceededCrashes 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.
warning: Package 'braces@3.0.3' is vulnerable to 'CVE-2026-93687' (also known as 'GHSA-vfj7-8cjw-p6xm').
= CVE-2026-93687: braces vulnerable to stack-exhaustion denial of service through deeply nested patterns
= 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.
warning: Package 'braces@3.0.3' is vulnerable to 'CVE-2026-93687' (also known as 'GHSA-vfj7-8cjw-p6xm').
= CVE-2026-93687: braces vulnerable to stack-exhaustion denial of service through deeply nested patterns
= 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.
warning: Package 'bare-metal@0.2.5' is vulnerable to 'RUSTSEC-2026-0110'.
= RUSTSEC-2026-0110: bare-metal is deprecated
= The bare-metal crate has been deprecated and archived.
For Mutex and CriticalSection, see the critical-section crate instead.
warning: Package 'bare-metal@0.2.5' is vulnerable to 'RUSTSEC-2026-0110'.
= RUSTSEC-2026-0110: bare-metal is deprecated
= The bare-metal crate has been deprecated and archived.
For Mutex and CriticalSection, see the critical-section crate instead.
warning: 8 warnings emitted
</details>
See detailed reports in [MegaLinter artifacts](https://github.com/philips-software/amp-devcontainer/actions/runs/37906850613)
You could have the same capabilities but better runtime performances if you use a MegaLinter flavor:
- [oxsecurity/megalinter/flavors/salesforce@v10.1.0](https://megalinter.io/10.1.0/flavors/salesforce/) (58 linters)
Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining `FLAVOR_SUGGESTIONS: false`)
- Documentation: [Custom Flavors](https://megalinter.io/10.1.0/custom-flavors/)
- Command: `npx mega-linter-runner@10.1.0 --custom-flavor-setup --custom-flavor-linters ACTION_ACTIONLINT,DOCKERFILE_HADOLINT,JSON_V8R,JSON_PRETTIER,JSON_NPM_PACKAGE_JSON_LINT,MARKDOWN_MARKDOWNLINT,MARKDOWN_MARKDOWN_TABLE_FORMATTER,REPOSITORY_CHECKOV,REPOSITORY_GIT_DIFF,REPOSITORY_BETTERLEAKS,REPOSITORY_GRYPE,REPOSITORY_OSV_SCANNER,REPOSITORY_SECRETLINT,REPOSITORY_SYFT,REPOSITORY_TRIVY,REPOSITORY_TRIVY_SBOM,REPOSITORY_TRUFFLEHOG,SPELL_LYCHEE,YAML_PRETTIER,YAML_YAMLLINT,YAML_V8R`
[](https://www.ox.security/?ref=megalinter)
Show us your support by [**starring ⭐ the repository**](https://github.com/oxsecurity/megalinter)
<!-- megalinter: github-comment-reporter workflow='Linting & Formatting' jobid='linter' -->
📦 Container Size AnalysisNote Comparing 📈 Size Comparison Table
|
📦 Container Size AnalysisNote Comparing 📈 Size Comparison Table
|
📦 Container Size AnalysisNote Comparing 📈 Size Comparison Table
|
📦 Container Size AnalysisNote Comparing 📈 Size Comparison Table
|
📦 Container Size AnalysisNote Comparing 📈 Size Comparison Table
|
Bumps the npm group with 1 update: @types/node.
Updates
@types/nodefrom 26.6.3 to 26.6.4Commits
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditions