Skip to content

chore(deps): update dependency brace-expansion@2 to v5 [security] - #176

Open
cachekit-renovate-bot[bot] wants to merge 1 commit into
mainfrom
renovate/npm-brace-expansion2-vulnerability
Open

cachekit-renovate-bot[bot] wants to merge 1 commit into
mainfrom
renovate/npm-brace-expansion2-vulnerability

Conversation

@cachekit-renovate-bot

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
brace-expansion@2 >=2.1.3 <3 → >=2.1.3 <6 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.


brace-expansion: DoS via unbounded intermediate arrays, bypassing the CVE-2026-14257 mitigation

CVE-2026-69152 / GHSA-rgw5-rvv9-x895

More information

Details

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:

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:

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:

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.

The sequence-generation issue was found while verifying that report.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


brace-expansion: DoS via uncontrolled recursion in parseCommaParts causing stack exhaustion

CVE-2026-102276 / GHSA-6j4f-fj2g-mc7p

More information

Details

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:

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 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:

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 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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


brace-expansion: DoS via uncontrolled recursion on nested brace groups causing stack exhaustion

CVE-2026-102278 / GHSA-qhr7-859c-m2p7

More information

Details

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 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:

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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


brace-expansion: Quadratic-time expansion of the {a},b} rewrite causes CPU denial of service

CVE-2026-102277 / GHSA-q2hr-2g5m-vwhr

More information

Details

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.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Release Notes

juliangruber/brace-expansion (brace-expansion@2)

v5.0.12

Compare Source

v5.0.11

Compare Source

v5.0.10

Compare Source

v5.0.9

Compare Source

v5.0.8

Compare Source

v5.0.7

Compare Source

v5.0.6

Compare Source

v5.0.5

Compare Source

v5.0.4

Compare Source

v5.0.3

Compare Source

v5.0.2

Compare Source

v4.0.1

Compare Source


v4.0.0

Compare Source

As a precaution to not risk breaking anything with 278132b, this is a new semver major release

v3.0.9

Compare Source

v3.0.8

Compare Source

v3.0.7

Compare Source

v3.0.6

Compare Source

v3.0.5

Compare Source

v3.0.4

Compare Source

v3.0.3

Compare Source

v3.0.2

Compare Source

v3.0.1

Compare Source


v3.0.0

Compare Source


Configuration

📅 Schedule: (in timezone Australia/Sydney)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate.

@cachekit-renovate-bot cachekit-renovate-bot Bot added dependencies Pull requests that update a dependency file security labels Oct 2, 2026
@kodus-27b

kodus-27b Bot commented Oct 2, 2026 •

Copy link
Copy Markdown

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration
Interacting with Kody
  • Request a Review: Ask Kody to review your PR manually by adding a comment with the `@kody start-review` command at the root of your PR.

  • Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Providing Context (Files & MCPs)

Add these hints in your PR description (or a comment) to unlock deeper checks:

  • Ticket / Acceptance Criteria: `Refs: ABC-123` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
  • Bugfix Validation: a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
  • Endpoint Risk: mention the route (e.g., `POST /api/payments`) or controller/action name.
  • Attach a repo file as context: use an explicit marker like `@file:docs/guide.mdx#L10-L50` (replace with your real path).
  • API Contract Docs: include `@file:openapi.yaml` or `@file:swagger.json` when changing routes/schemas.
  • Definition of Done / Standards: include `@file:DOD.md` or `@file:CONTRIBUTING.md` if your repo has them.
  • Design System Source of Truth: include `@file:ui/index.ts` (replace with your DS entrypoint path).
  • Feature Flags: include the flag key/name and `@file:flags.ts` / `@file:config.json` (and optionally the PostHog flag name).
  • Edge/CDN Rules: link the Cloudflare rule/zone or describe the intended redirect/header behavior.
  • Attach an MCP tool output: use `@mcp<provider|tool>` (replace with an installed MCP provider + tool, e.g., `@mcp<sentry|events.search>`).
Current Kody Configuration
Review Options

The following review options are enabled or disabled:

Options Enabled
Bug ✅
Performance ✅
Security ✅
Business Logic ✅

Access your configuration settings here.

Kody Code Review — 2 suggested fixes.
Paste the prompt below to your agent and all review fixed at once!

🛠️ Open Agent Prompt
A code review identified the following issues in this pull request.
Each section describes what was found and includes a reference implementation where available.

Files involved:
- pnpm-workspace.yaml:76
- pnpm-workspace.yaml:76

---

### [1/2] pnpm-workspace.yaml:76
Issue identified during code review:
Contract violation in the pnpm-workspace.yaml overrides 'brace-expansion@2' entry: widening the bound from '<3' to '<6' moves 2.x consumers up to brace-expansion 5.x. The comment at pnpm-workspace.yaml:58-67 forbids this exact Renovate widening (PR #94). When the lockfile is next re-resolved, minimatch@5.1.9 and minimatch@9.0.9 (pnpm-lock.yaml:4518-4524) pull in 5.x. Its ESM named `expand` export does not match the 2.x CommonJS default export they import, so glob expansion breaks at runtime. The CI step 'Verify bounded floor-pins stay in-major' (ci.yml:140, 158-166) also expects 'brace-expansion@2 3', finds '6', and fails the security job. Fix: keep the bound at '<3', revert the minimumReleaseAgeExclude entry to 'brace-expansion@2.1.3', and close this Renovate PR; 'brace-expansion@5': '>=5.0.8' already floor-pins the 5.x line.
Reference implementation (from code review):

// pnpm-workspace.yaml:76
'brace-expansion@2': '>=2.1.3 <3' # GHSA-3jxr-9vmj-r5cp + GHSA-mh99-v99m-4gvg 2.x backport

---

### [2/2] pnpm-workspace.yaml:76
Issue identified during code review:
Unexpected transitive major-version jump in the pnpm-workspace.yaml `brace-expansion@2` override: the `>=2.1.3 <6` range force-resolves packages that declared a 2.x dependency to 3.x, 4.x, or 5.x. This contradicts the trailing '2.x backport' comment and violates Rule 87. A 2.x consumer resolved to brace-expansion 3+ hits its breaking API and ESM changes at runtime. Fix: bound the override to `'>=2.1.3 <3'`, cover 5.x through the existing `brace-expansion@5` override, and update the lockfile. If the widening is intentional, attach OSV/audit output and verify each 2.x consumer against 5.x.

---

Review each issue in context, use the reference implementations as guidance, and apply fixes that are consistent with the surrounding codebase.

@coderabbitai

coderabbitai Bot commented Oct 2, 2026

Copy link
Copy Markdown

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository: cachekit-io/cachekit-ts/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: a5ae277c-741a-4719-b5fa-e4d6e57ac059

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
  • Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Comment thread pnpm-workspace.yaml
yaml: '>=2.8.3'
postcss: '>=8.5.18' # GHSA-r28c-9q8g-f849
'brace-expansion@2': '>=2.1.3 <3' # GHSA-3jxr-9vmj-r5cp + GHSA-mh99-v99m-4gvg 2.x backport
'brace-expansion@2': '>=2.1.3 <6' # GHSA-3jxr-9vmj-r5cp + GHSA-mh99-v99m-4gvg 2.x backport

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kody code-review Bug high

Contract violation in the pnpm-workspace.yaml overrides 'brace-expansion@2' entry: widening the bound from '<3' to '<6' moves 2.x consumers up to brace-expansion 5.x. The comment at pnpm-workspace.yaml:58-67 forbids this exact Renovate widening (PR #94). When the lockfile is next re-resolved, minimatch@5.1.9 and minimatch@9.0.9 (pnpm-lock.yaml:4518-4524) pull in 5.x. Its ESM named expand export does not match the 2.x CommonJS default export they import, so glob expansion breaks at runtime. The CI step 'Verify bounded floor-pins stay in-major' (ci.yml:140, 158-166) also expects 'brace-expansion@2 3', finds '6', and fails the security job. Fix: keep the bound at '<3', revert the minimumReleaseAgeExclude entry to 'brace-expansion@2.1.3', and close this Renovate PR; 'brace-expansion@5': '>=5.0.8' already floor-pins the 5.x line.

'brace-expansion@2': '>=2.1.3 <3' # GHSA-3jxr-9vmj-r5cp + GHSA-mh99-v99m-4gvg 2.x backport
Prompt for LLM

File pnpm-workspace.yaml:

Line 76:

Contract violation in the pnpm-workspace.yaml overrides 'brace-expansion@2' entry: widening the bound from '<3' to '<6' moves 2.x consumers up to brace-expansion 5.x. The comment at pnpm-workspace.yaml:58-67 forbids this exact Renovate widening (PR #94). When the lockfile is next re-resolved, minimatch@5.1.9 and minimatch@9.0.9 (pnpm-lock.yaml:4518-4524) pull in 5.x. Its ESM named `expand` export does not match the 2.x CommonJS default export they import, so glob expansion breaks at runtime. The CI step 'Verify bounded floor-pins stay in-major' (ci.yml:140, 158-166) also expects 'brace-expansion@2 3', finds '6', and fails the security job. Fix: keep the bound at '<3', revert the minimumReleaseAgeExclude entry to 'brace-expansion@2.1.3', and close this Renovate PR; 'brace-expansion@5': '>=5.0.8' already floor-pins the 5.x line.

Suggested Code:

  'brace-expansion@2': '>=2.1.3 <3' # GHSA-3jxr-9vmj-r5cp + GHSA-mh99-v99m-4gvg 2.x backport

Talk to Kody by mentioning @kody

Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.

​

​

@codecov

codecov Bot commented Oct 2, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Comment thread pnpm-workspace.yaml
yaml: '>=2.8.3'
postcss: '>=8.5.18' # GHSA-r28c-9q8g-f849
'brace-expansion@2': '>=2.1.3 <3' # GHSA-3jxr-9vmj-r5cp + GHSA-mh99-v99m-4gvg 2.x backport
'brace-expansion@2': '>=2.1.3 <6' # GHSA-3jxr-9vmj-r5cp + GHSA-mh99-v99m-4gvg 2.x backport

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kody code-review Kody Rules high

Unexpected transitive major-version jump in the pnpm-workspace.yaml brace-expansion@2 override: the >=2.1.3 <6 range force-resolves packages that declared a 2.x dependency to 3.x, 4.x, or 5.x. This contradicts the trailing '2.x backport' comment and violates Rule 87. A 2.x consumer resolved to brace-expansion 3+ hits its breaking API and ESM changes at runtime. Fix: bound the override to '>=2.1.3 <3', cover 5.x through the existing brace-expansion@5 override, and update the lockfile. If the widening is intentional, attach OSV/audit output and verify each 2.x consumer against 5.x.

Kody rule violation: Validate new/updated dependencies for CVEs and supply-chain risk

Prompt for LLM

File pnpm-workspace.yaml:

Line 76:

Unexpected transitive major-version jump in the pnpm-workspace.yaml `brace-expansion@2` override: the `>=2.1.3 <6` range force-resolves packages that declared a 2.x dependency to 3.x, 4.x, or 5.x. This contradicts the trailing '2.x backport' comment and violates Rule 87. A 2.x consumer resolved to brace-expansion 3+ hits its breaking API and ESM changes at runtime. Fix: bound the override to `'>=2.1.3 <3'`, cover 5.x through the existing `brace-expansion@5` override, and update the lockfile. If the widening is intentional, attach OSV/audit output and verify each 2.x consumer against 5.x.

Talk to Kody by mentioning @kody

Was this suggestion helpful? React with 👍 or 👎 to help Kody learn from this interaction.

​

​

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file security

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant