fix(security): update vulnerability-updates [security]#422
Open
renovate[bot] wants to merge 1 commit into
Open
fix(security): update vulnerability-updates [security]#422renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
Contributor
Author
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
2.7.1→2.8.04.1.1→4.2.09.0.3→9.0.75.2.4→5.2.5OpenTelemetry Core: Unbounded memory allocation in W3C Baggage propagation
CVE-2026-54285 / GHSA-8988-4f7v-96qf
More information
Details
Overview
W3CBaggagePropagator.extract()in@opentelemetry/coredoes not enforce size limits when parsing inboundbaggageHTTP headers. The W3C Baggage specification recommends a maximum of 8,192 bytes and 180 entries; these limits were only enforced on the outbound (inject()) path, not on the inbound (extract()) path. Parsing oversized baggage causes memory allocation proportional to the header size without any cap.Impact
The practical availability impact for most Node.js deployments is limited. Node.js enforces a default
--max-http-header-sizeof 16,384 bytes on the total combined size of all HTTP headers, constraining what an external attacker can deliver before the propagator is reached. Additionally, the header is already in memory (parsed by the HTTP layer) by the time it reaches the propagator - the additional allocation is the overhead of splitting into entry objects, not an unbounded read.The risk is higher when transport-layer limits are absent - e.g., non-HTTP transports (messaging systems, custom
TextMapGetterimplementations) or deployments that have raised--max-http-header-size.Remediation
Update
@opentelemetry/coreto version 2.8.0 or later. The fix enforces limits consistent with the W3C Baggage specification at the propagator level:Headers that exceed these limits are truncated at the point the limit is reached.
Workarounds
Ensure header size limits are configured at the server or gateway level. The default Node.js HTTP header limit (16 KB) mitigates external attack vectors independently of this fix. For non-HTTP transports receiving baggage from untrusted sources, validate input size before passing it to the propagator.
References
Credit
Reported by tonghuaroot.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
JS-YAML: Quadratic-complexity DoS in merge key handling via repeated aliases
CVE-2026-53550 / GHSA-h67p-54hq-rp68
More information
Details
Summary
A crafted YAML document can trigger algorithmic CPU exhaustion in
js-yamlmerge-key processing (<<) by repeating the same alias many times in a merge sequence.This causes quadratic parse-time behavior relative to input size and can block a Node.js worker/event loop for seconds with a relatively small payload (tens of KB), resulting in denial of service.
Details
The issue is in merge handling inside
lib/loader.js:storeMappingPair(...)iterates every element of a merge sequence when key tag istag:yaml.org,2002:merge.mergeMappings(...).mergeMappings(...)computesObject.keys(source)and performs_hasOwnProperty.call(destination, key)checks for each key.When input is of the form:
a: &a {k0:0, k1:0, ..., kK:0}
b: {<<: [*a, *a, *a, ... repeated M times ...]}
all *a entries refer to the same anchored object. After the first merge, subsequent merges are semantically no-ops, but the parser still reprocesses all keys each time.
Resulting work is O(K * M), while input size is O(K + M), giving quadratic scaling as payload grows.
Relevant code path:
lib/loader.js in storeMappingPair(...) merge branch (keyTag === 'tag:yaml.org,2002:merge')
lib/loader.js mergeMappings(...)
Root cause
File: lib/loader.js
Function: storeMappingPair(state, _result, overridableKeys, keyTag, keyNode,
valueNode, startLine, startLineStart, startPos)
Lines: ~359-366
When the merge value is a sequence (YAML 1.1 <<: [ *a, *a, ... ]), each element
is handed to mergeMappings() without deduplication. mergeMappings() then does
Every alias reference in the sequence resolves (by design) to the SAME object
via state.anchorMap. After the first merge, every subsequent merge of that same
reference is a pure no-op semantically, but still performs:
Total: M * K hasOwnProperty checks + M Object.keys allocations, while the final
object and all observable side effects are identical to a single merge.
YAML semantics for
<<:are idempotent and commutative over duplicate sources,so collapsing duplicates preserves behavior exactly; this isn't a spec trade-off.
PoC
Environment:
js-yaml version: 4.1.1
Node.js: v24.5.0
Platform: arm64 macOS (reproduced consistently)
Reproduction script:
Create many keys in one anchored map (&a).
Merge that same alias repeatedly via <<: [*a, *a, ...].
Measure parse time and compare with control payload using single merge (<<: *a).
Observed repeated runs (same machine):
K=M=1000, input 9,909 bytes: ~33–36 ms
K=M=2000, input 20,909 bytes: ~121–123 ms
K=M=4000, input 42,909 bytes: ~524–537 ms
K=M=6000, input 64,909 bytes: ~1,608–1,829 ms
K=M=8000, input 86,909 bytes: ~3,395–3,565 ms
Control (single merge, similar key counts):
K=2000: ~1–2 ms
K=4000: ~3 ms
K=8000: ~5 ms
Also verified: repeated-merge output equals single-merge output (same key count and same JSON), confirming excess time is redundant computation.
Impact
This is a denial-of-service vulnerability (CPU exhaustion / algorithmic complexity).
Any service parsing untrusted YAML with js-yaml can be impacted, including API backends, CI tools, config processors, and automation services. An attacker can submit crafted YAML to significantly increase CPU time and reduce availability.
Suggested fix:
Dedupe the merge source list by reference before invoking mergeMappings. Any of
the following are minimal and preserve YAML 1.1 merge semantics:
dedupe in storeMappingPair:
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
minimatch has ReDoS: matchOne() combinatorial backtracking via multiple non-adjacent GLOBSTAR segments
CVE-2026-27903 / GHSA-7r86-cg39-jmmj
More information
Details
Summary
matchOne()performs unbounded recursive backtracking when a glob pattern contains multiple non-adjacent**(GLOBSTAR) segments and the input path does not match. The time complexity is O(C(n, k)) -- binomial -- wherenis the number of path segments andkis the number of globstars. With k=11 and n=30, a call to the defaultminimatch()API stalls for roughly 5 seconds. With k=13, it exceeds 15 seconds. No memoization or call budget exists to bound this behavior.Details
The vulnerable loop is in
matchOne()atsrc/index.ts#L960:When a GLOBSTAR is encountered, the function tries to match the remaining pattern against every suffix of the remaining file segments. Each
**multiplies the number of recursive calls by the number of remaining segments. With k non-adjacent globstars and n file segments, the total number of calls is C(n, k).There is no depth counter, visited-state cache, or budget limit applied to this recursion. The call tree is fully explored before returning
falseon a non-matching input.Measured timing with n=30 path segments:
PoC
Tested on minimatch@10.2.2, Node.js 20.
Step 1 -- inline script
To scale the effect, increase k:
No special options are required. This reproduces with the default
minimatch()call.Step 2 -- HTTP server (event loop starvation proof)
The following server demonstrates the event loop starvation effect. It is a minimal harness, not a claim that this exact deployment pattern is common:
Terminal 1 -- start the server:
Terminal 2 -- send the attack request (k=11, ~5s stall) and immediately return to shell:
Terminal 3 -- while the attack is in-flight, send a benign request:
Observed output (Terminal 3):
The server reports
"ms":"0"-- the legitimate request itself takes zero processing time. The 4+ secondtime_totalis entirely time spent waiting for the event loop to be released by the attack request. Every concurrent user is blocked for the full duration of each attack call. Repeating the benign request while no attack is in-flight confirms the baseline:Impact
Any application where an attacker can influence the glob pattern passed to
minimatch()is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments (ESLint, Webpack, Rollup config), multi-tenant systems where one tenant configures glob-based rules that run in a shared process, admin or developer interfaces that accept ignore-rule or filter configuration as globs, and CI/CD pipelines that evaluate user-submitted config files containing glob patterns. An attacker who can place a crafted pattern into any of these paths can stall the Node.js event loop for tens of seconds per invocation. The pattern is 56 bytes for a 5-second stall and does not require authentication in contexts where pattern input is part of the feature.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).
webpack-dev-server vulnerable to HMR WebSocket interception via permissive user proxies
CVE-2026-9595 / GHSA-mx8g-39q3-5c79
More information
Details
Impact
When a user-configured proxy on
webpack-dev-serverhas a broad context (e.g./) andws: true, it also intercepts the dev server's own HMR WebSocket and forwards it to the proxy target. This leaks the browser's cookies andOriginheader to the backend, bypasses the dev server's Host/Origin validation, and corrupts the HMR socket (both HMR and the proxy end up writing to the same socket).Patches
Fixed in
webpack-dev-server5.2.5.Workarounds
Scope user-defined proxy
contextto specific paths instead of/, or omitws: truefrom the proxy entry when WebSocket forwarding is not required.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
open-telemetry/opentelemetry-js (@opentelemetry/core)
v2.8.0Compare Source
🚀 Features
SpanImpl,Tracer, andBasicTracerProviderviautil.inspectso they render throughdiagandconsole.log#6690 @mcollinahrTimeToSeconds#6449 @anuraaga🐛 Bug Fixes
nodeca/js-yaml (js-yaml)
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).
isaacs/minimatch (minimatch)
v9.0.7Compare Source
v9.0.6Compare Source
v9.0.5Compare Source
v9.0.4Compare Source
webpack/webpack-dev-server (webpack-dev-server)
v5.2.5Compare Source
Patch Changes
All notable changes to this project will be documented in this file. See standard-version for commit guidelines.
5.2.4 (2026-05-11)
Bug Fixes
5.2.3 (2026-01-12)
Bug Fixes
causeforerrorObject(#5518) (37b033d)5.2.2 (2025-06-03)
Bug Fixes
X_TEST(#5451) (64a6124)allowedHostsoption for cross-origin header check (#5510) (03d1214)Configuration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR was generated by Mend Renovate. View the repository job log.