chore(deps): update dependency js-yaml@<3.15.0 to v4 [security] - #2271
chore(deps): update dependency js-yaml@<3.15.0 to v4 [security]#2271renovate[bot] wants to merge 1 commit into
Conversation
|
4bfb5da to
ec1b8ed
Compare
| @@ -35,7 +37,7 @@ overrides: | |||
| 'lodash@<4.18.0': ^4.18.0 | |||
| 'protobufjs@<7.6.5': ^7.6.5 | |||
| 'ws@>=8.0.0 <8.21.0': ^8.21.0 | |||
There was a problem hiding this comment.
🔴 Release/versioning tooling crashes because an old dependency is forced onto an incompatible YAML library major version
Every dependency that asked for the old 3.x YAML library is now forced onto version 4 ('js-yaml@<3.15.0': ^4.3.1 at pnpm-workspace.yaml:41), but one of those dependencies calls a function that version 4 removed, so the workspace's changeset/versioning commands fail with a runtime error.
Impact: Running the repo's release tooling (changesets version/status) breaks in CI and locally.
Mechanism: read-yaml-file@1.1.0 uses the removed yaml.safeLoad API
pnpm-lock.yaml resolves read-yaml-file@1.1.0 (a dependency of @manypkg/get-packages@1.1.3, itself used by @changesets/*) with js-yaml: 4.3.1 (pnpm-lock.yaml:9014-9019). read-yaml-file@1.1.0/index.js is:
const yaml = require('js-yaml')
const parse = data => yaml.safeLoad(stripBom(data))safeLoad was removed in js-yaml 4.0.0 (see the 4.0.0 breaking-change notes in the PR body: "removed safe* functions"). So any code path that reads pnpm-workspace.yaml through @manypkg/get-packages throws TypeError: yaml.safeLoad is not a function. Previously the override pinned ^3.15.0, which kept safeLoad available.
Before this change the same override range resolved to js-yaml 3.15.0, which still exposes safeLoad, so the breakage is introduced by widening the override to ^4.3.1.
Was this helpful? React with 👍 or 👎 to provide feedback.
ec1b8ed to
c13f51e
Compare
c13f51e to
8ce9ee3
Compare
8ce9ee3 to
c071304
Compare
c071304 to
b9242e8
Compare
b9242e8 to
62962f3
Compare
62962f3 to
a9487ea
Compare
a9487ea to
30a97cd
Compare
30a97cd to
7aaf1b7
Compare
7aaf1b7 to
b1b41e8
Compare
18aa444 to
321e1e4
Compare
321e1e4 to
df542e9
Compare
df542e9 to
fadffcb
Compare
fadffcb to
7cb7f40
Compare
7cb7f40 to
76d0dd7
Compare
76d0dd7 to
5fe9fb1
Compare
5fe9fb1 to
a8cd4cd
Compare
a8cd4cd to
306c81c
Compare
306c81c to
f5459b8
Compare
f5459b8 to
04cedab
Compare
| 'protobufjs@<7.6.5': ^7.6.5 | ||
| 'ws@>=8.0.0 <8.21.0': ^8.21.0 | ||
| 'js-yaml@<3.15.0': ^3.15.0 | ||
| 'js-yaml@<3.15.0': ^4.3.1 |
There was a problem hiding this comment.
🟨 Advisory being patched remains unfixed for most YAML library consumers pinned to 4.3.0
The PR bumps only the <3.15.0 override to ^4.3.1, while the sibling override 'js-yaml@>=4.0.0 <4.3.0': ^4.3.0 (pnpm-workspace.yaml:43) still resolves to js-yaml 4.3.0 in pnpm-lock.yaml:8457-8459, which is the version the referenced advisory (GHSA-5p4m-2wfm-xmqj, quadratic !!omap resolution) explicitly lists as affected. ESLint and the changesets tooling continue to load js-yaml 4.3.0 (pnpm-lock.yaml:5768, 5978, 7893), so the intended security update is only partially applied.
Was this helpful? React with 👍 or 👎 to provide feedback.
This PR contains the following updates:
^3.15.0→^4.3.1JS-YAML: Quadratic CPU consumption in !!omap resolution (3.x and 4.x) — CVE-2026-59870 fix not backported
GHSA-5p4m-2wfm-xmqj
More information
Details
Quadratic CPU consumption in
!!omapresolution (js-yaml 3.x and 4.x)Summary
resolveYamlOmap()enforces key uniqueness for!!omapsequences with a linearscan (
objectKeys.indexOf(...)) inside the per-element loop, making resolutionO(n²) in the number of entries. A modestly sized YAML document therefore
consumes disproportionate CPU inside
yaml.load(), giving a denial of serviceagainst any consumer that parses untrusted YAML.
!!omapis registered in the default schema(
lib/schema/default.js→require('../type/omap')), so a plainyaml.load(untrustedInput)with no options is affected — no custom schema ornon-default configuration is required.
This is the same weakness as CVE-2026-59870 / GHSA-724g-mxrg-4qvm, which was
fixed in the 5.x line in 5.2.1. That fix was never backported: both currently
maintained legacy lines still carry the original implementation.
Affected versions
objectKeys.indexOf(pairKey)atlib/type/omap.js:29objectKeys.indexOf(pairKey)atlib/type/omap.js:30Set)Both figures are the newest release of each line at the time of writing, so
this is not a "you are on an old version" issue.
Details
lib/type/omap.js(js-yaml 4.3.0):objectKeysgrows by one element per entry, andArray.prototype.indexOfis alinear scan, so resolving an
n-entry!!omapperforms roughly1 + 2 + … + ncomparisons — quadratic inn. The work happens synchronouslyinside
yaml.load(), blocking the event loop for its whole duration.The 5.x line already solves exactly this by tracking seen keys in a
Set(
src/tag/sequence/omap.ts):Proof of concept
Measured (node v20.20.2, default heap, no flags)
js-yaml 4.3.0
js-yaml 3.15.0
Runtime grows by a factor of ~4 for each doubling of
n, which is thesignature of O(n²) (linear growth would be ~2×).
Scaling further: a 2.48 MB document with 150,000 entries blocked
yaml.load()for 10.8 seconds.Impact
Any service that parses attacker-influenced YAML with js-yaml 3.x or 4.x can be
stalled with a small input. Because the loop is synchronous, a single request
blocks the Node.js event loop and stalls every other request in the process —
so the amplification is per-process, not just per-request.
Suggested severity: consistent with CVE-2026-59870 (the same weakness in
5.x), i.e. Availability-only impact, network attack vector, no privileges or
user interaction required.
Suggested fix
Mirror the 5.x fix — replace the linear scan with a
Set:This preserves the existing duplicate-key rejection semantics exactly while
making resolution O(n). A
maxOmapLength-style cap would also work, but theSetmatches what 5.x already ships and requires no new option.References
lib/type/omap.js(3.x, 4.x) — the affected resolverlib/schema/default.js— registers!!omapin the default schemaDiscovery
Found by an automated static-analysis and executed-proof-of-concept scanner run
against js-yaml 4.2.0, then manually verified against 3.15.0 and 4.3.0 by
executing the proof of concept above. All timings in this report were measured
on the current releases of each line, not on the version originally scanned.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
nodeca/js-yaml (js-yaml@<3.15.0)
v4.3.1Compare Source
v4.3.0Compare Source
v4.2.0Compare Source
Added
docs/safety.mdwith notes about processing untrusted YAML.maxDepth(100) loader option. Not a problem, but gives a betterexception instead of RangeError on stack overflow.
maxMergeSeqLength(20) loader option. Not a problem aftermergefix,but an additional restriction for safety.
dist/builds.Changed
dist/files are no longer kept in the repository.Fixed
Security
elements (makes sense for malformed files > 10K).
v4.1.1Compare Source
Security
v4.1.0Compare Source
Added
yaml.types.XXX.optionsproperty with original arguments kept as they were(see
yaml.types.int.optionsas an example).Changed
Schema.extend()now keeps old type order in case of conflicts(e.g. Schema.extend([ a, b, c ]).extend([ b, a, d ]) is now ordered as
abcdinstead ofcbad).v4.0.0Compare Source
Changed
!!js/function,!!js/regexp,!!js/undefinedaremoved to js-yaml-js-types package.
safe*functions. Useload,loadAll,dumpinstead which are all now safe by default.
yaml.DEFAULT_SAFE_SCHEMAandyaml.DEFAULT_FULL_SCHEMAare removed, useyaml.DEFAULT_SCHEMAinstead.yaml.Schema.create(schema, tags)is removed, useschema.extend(tags)instead.!!binarynow always mapped toUint8Arrayon load./libfolder.01234is now decimal,0o1234is octal,1:23is parsed as string instead of base60).dump()no longer quotes:,[,],(,)except when necessary, #470, #557.(X:Y)instead ofat line X, column Y(also present in compact format), #332.dump()now serializesundefinedasnullin collections and removes keys withundefinedin mappings, #571.dump()withskipInvalid=truenow serializes invalid items in collections as null.!are now dumped as!taginstead of!<!tag>, #576.tag:yaml.org,2002:are now shorthanded using!!, #258.Added
.mjs(es modules) support.quotingTypeandforceQuotesoptions for dumper to configurestring literal style, #290, #529.
styles: { '!!null': 'empty' }option for dumper(serializes
{ foo: null }as "foo:"), #570.replaceroption (similar to option in JSON.stringify), #339.Tagcan now handle all tags or multiple tags with the same prefix, #385.Fixed
dump(), #587.[foo,,bar]) now throw an exceptioninstead of producing null, #321.
__proto__key no longer overrides object prototype, #164.bower.json.load()and url-encoded indump()(previously usage of custom non-ascii tags may have led to invalid YAML that can't be parsed).
v3.15.1Compare Source
Configuration
📅 Schedule: (UTC)
🚦 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.
This PR was generated by Mend Renovate. View the repository job log.