Skip to content

fix(security/high/): update dependency js-yaml to v4.3.2 [security] - #193

Merged
domasx2 merged 1 commit into
mainfrom
renovate/security-js-yaml
Sep 22, 2026
Merged

domasx2 merged 1 commit into
mainfrom
renovate/security-js-yaml

Conversation

@renovate-sh-app

@renovate-sh-app renovate-sh-app Bot commented Sep 9, 2026 •

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
js-yaml 4.3.1 → 4.3.2 age confidence

js-yaml: maxTotalMergeKeys does not limit CPU use for empty merge sources

CVE-2026-84375 / GHSA-2883-xcg3-v3hh

More information

Details

Summary

maxTotalMergeKeys does not count empty mappings. An attacker can repeatedly merge a large sequence of them and consume significant CPU without reaching the configured limit.

Example
arr: &arr [{}, {}, {}, ...] # N empty mappings
targets:
  - <<: *arr                # repeated K times

For every target, the loader iterates all N elements of arr. This results in O(N * K) work while totalMergeKeys remains unchanged.

PoC
import { performance } from 'node:perf_hooks'
import { load, YAML11_SCHEMA } from 'js-yaml'

const n = 20000

const src =
  'arr: &arr [' + '{},'.repeat(n).slice(0, -1) + ']\n' +
  'targets:\n' +
  '  - <<: *arr\n'.repeat(n)

const started = performance.now()

load(src, { schema: YAML11_SCHEMA })

console.log(`${(performance.now() - started).toFixed(1)} ms`)

Observed results:

N YAML size Time
800 ~13 KB ~20 ms
3200 ~50 KB ~180 ms
20000 ~500 KB ~13 s
Impact

An attacker can submit a relatively small YAML document that causes prolonged CPU consumption despite the default maxTotalMergeKeys limit.

Fix

Count each merge-source mapping as one budget unit, in addition to counting its keys.

Difference with v5

In v3 & v4, merge is enabled by default. So, the severity score is higher.

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


js-yaml: maxTotalMergeKeys does not limit CPU use for empty merge sources

CVE-2026-84375 / GHSA-2883-xcg3-v3hh

More information

Details

Summary

maxTotalMergeKeys does not count empty mappings. An attacker can repeatedly merge a large sequence of them and consume significant CPU without reaching the configured limit.

Example
arr: &arr [{}, {}, {}, ...] # N empty mappings
targets:
  - <<: *arr                # repeated K times

For every target, the loader iterates all N elements of arr. This results in O(N * K) work while totalMergeKeys remains unchanged.

PoC
import { performance } from 'node:perf_hooks'
import { load, YAML11_SCHEMA } from 'js-yaml'

const n = 20000

const src =
  'arr: &arr [' + '{},'.repeat(n).slice(0, -1) + ']\n' +
  'targets:\n' +
  '  - <<: *arr\n'.repeat(n)

const started = performance.now()

load(src, { schema: YAML11_SCHEMA })

console.log(`${(performance.now() - started).toFixed(1)} ms`)

Observed results:

N YAML size Time
800 ~13 KB ~20 ms
3200 ~50 KB ~180 ms
20000 ~500 KB ~13 s
Impact

An attacker can submit a relatively small YAML document that causes prolonged CPU consumption despite the default maxTotalMergeKeys limit.

Fix

Count each merge-source mapping as one budget unit, in addition to counting its keys.

Difference with v5

In v3 & v4, merge is enabled by default. So, the severity score is higher.

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 OSV and the GitHub Advisory Database (CC-BY 4.0).


Release Notes

nodeca/js-yaml (js-yaml)

v4.3.2

Compare Source


Configuration

📅 Schedule: (UTC)

  • 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

Need help?

You can ask for more help in the following Slack channel: #proj-renovate-self-hosted. In that channel you can also find ADR and FAQ docs in the Resources section.

| datasource | package | from  | to    |
| ---------- | ------- | ----- | ----- |
| npm        | js-yaml | 4.3.1 | 4.3.2 |


Signed-off-by: renovate-sh-app[bot] <219655108+renovate-sh-app[bot]@users.noreply.github.com>
@domasx2
domasx2 merged commit 86b61be into main Sep 22, 2026
18 checks passed
@domasx2
domasx2 deleted the renovate/security-js-yaml branch September 22, 2026 07:41
domasx2 added a commit that referenced this pull request Sep 22, 2026
…y CVEs

The packages are transitive-only, so Renovate cannot open security PRs for
them. Pin them through the existing resolutions block instead.

Three traps this works around:

- Yarn Berry applies a ranged resolution key only when the range matches the
  requested descriptor exactly, so brace-expansion is pinned per descriptor
  rather than per major.
- nx pins brace-expansion and smol-toml to exact vulnerable versions, which
  bypasses the unscoped resolutions, hence the nx/* entries.
- postcss 8.5.18 fixes CVE-2026-73646 but is still hit by CVE-2026-69153, an
  incomplete-fix follow-up, so it goes to 8.5.23.

Also closes the residuals left by #193 and #194: both CVEs also affect an
older major line in the tree (js-yaml 3.x, smol-toml via nx) that those
PRs did not cover.

Every resolved version is verified against the GitHub advisory database.
domasx2 added a commit that referenced this pull request Sep 22, 2026
…y CVEs (#198)

The packages are transitive-only, so Renovate cannot open security PRs for
them. Pin them through the existing resolutions block instead.

Three traps this works around:

- Yarn Berry applies a ranged resolution key only when the range matches the
  requested descriptor exactly, so brace-expansion is pinned per descriptor
  rather than per major.
- nx pins brace-expansion and smol-toml to exact vulnerable versions, which
  bypasses the unscoped resolutions, hence the nx/* entries.
- postcss 8.5.18 fixes CVE-2026-73646 but is still hit by CVE-2026-69153, an
  incomplete-fix follow-up, so it goes to 8.5.23.

Also closes the residuals left by #193 and #194: both CVEs also affect an
older major line in the tree (js-yaml 3.x, smol-toml via nx) that those
PRs did not cover.

Every resolved version is verified against the GitHub advisory database.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants