Vulnerable Library - pulumi-tools-0.22.171.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/tmp@0.2.5/node_modules/tmp/package.json
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Vulnerabilities
*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.
**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation
Details
Partial details (15 vulnerabilities) are displayed below due to a content size limitation in GitHub. To view information on the remaining vulnerabilities, navigate to the Mend Application.
CVE-2026-9496
Vulnerable Library - pacote-21.5.0.tgz
JavaScript package downloader
Library home page: https://registry.npmjs.org/pacote/-/pacote-21.5.0.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json,/node_modules/.pnpm/pacote@21.5.0/node_modules/pacote/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- arborist-9.4.3.tgz
- ❌ pacote-21.5.0.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Versions of the package pacote from 11.2.7 are vulnerable to Denial of Service (DoS) via the addGitSha function. An attacker can exploit this vulnerability by supplying a specially crafted spec.rawSpec value that triggers the function’s regex replacement and string-manipulation logic, causing excessive CPU consumption and potentially stalling or crashing the process.
Publish Date: 2026-05-26
URL: CVE-2026-9496
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.
Step up your Open Source Security Game with Mend here
CVE-2026-48712
Vulnerable Library - protobufjs-7.5.6.tgz
Protocol Buffers for JavaScript (& TypeScript).
Library home page: https://registry.npmjs.org/protobufjs/-/protobufjs-7.5.6.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/protobufjs@7.5.6/node_modules/protobufjs/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- exporter-trace-otlp-grpc-0.57.2.tgz
- otlp-transformer-0.57.2.tgz
- ❌ protobufjs-7.5.6.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Summary protobufjs could recurse without a depth limit while converting decoded messages to plain objects or JSON. This affected generated "toObject()" conversion and the custom "google.protobuf.Any" JSON conversion path. A crafted protobuf binary payload containing deeply nested "Any" values could cause the JavaScript call stack to be exhausted during conversion to JSON. Impact An attacker who can provide protobuf binary data decoded by an application may be able to crash the process or otherwise cause message conversion to fail with a stack overflow. This affects applications that decode untrusted protobuf input containing "google.protobuf.Any" values and then convert decoded messages to JSON or plain objects with JSON conversion enabled, for example through "JSON.stringify(message)", "Message#toJSON()", or "Type.toObject(message, { json: true })". Applications that only decode and re-encode protobuf binary data without converting decoded messages to JSON are not directly affected by this issue. Preconditions * The application must decode protobuf binary data influenced by an attacker. * The application schema must include "google.protobuf.Any", and the referenced "type_url" must resolve to a message type in the loaded protobuf root. * The application must convert the decoded message to JSON or a plain object through an affected conversion path. * The crafted input must contain deeply nested "Any" values that are expanded during conversion. Workarounds Avoid converting untrusted protobuf messages containing "google.protobuf.Any" values to JSON with affected versions. If immediate upgrade is not possible, reject or limit messages with deeply nested "Any" payloads at an outer protocol boundary where feasible, avoid JSON conversion of untrusted "Any" values, or isolate message conversion in a process that can be safely restarted.
Publish Date: 2026-06-15
URL: CVE-2026-48712
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-wcpc-wj8m-hjx6
Release Date: 2026-06-15
Fix Resolution: protobufjs - 8.4.1,protobufjs - 7.6.1
Step up your Open Source Security Game with Mend here
CVE-2026-48069
Vulnerable Library - grpc-js-1.14.3.tgz
gRPC Library for Node - pure JS implementation
Library home page: https://registry.npmjs.org/@grpc/grpc-js/-/grpc-js-1.14.3.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json,/node_modules/.pnpm/@grpc+grpc-js@1.14.3/node_modules/@grpc/grpc-js/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- ❌ grpc-js-1.14.3.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Impact An invalid incoming compressed message can cause a client or server process to crash. This affects all clients and servers that use @grpc/grpc-js Patches The following version have fixes for this vulnerability: - 1.9.16 - 1.10.12 - 1.11.4 - 1.12.7 - 1.13.5 - 1.14.4 Workarounds There is no workaround.
Publish Date: 2026-06-12
URL: CVE-2026-48069
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-99f4-grh7-6pcq
Release Date: 2026-06-11
Fix Resolution: @grpc/grpc-js - 1.12.7,@grpc/grpc-js - 1.14.4,@grpc/grpc-js - 1.13.5,@grpc/grpc-js - 1.9.16,@grpc/grpc-js - 1.10.12,@grpc/grpc-js - 1.11.4
Step up your Open Source Security Game with Mend here
CVE-2026-48068
Vulnerable Library - grpc-js-1.14.3.tgz
gRPC Library for Node - pure JS implementation
Library home page: https://registry.npmjs.org/@grpc/grpc-js/-/grpc-js-1.14.3.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json,/node_modules/.pnpm/@grpc+grpc-js@1.14.3/node_modules/@grpc/grpc-js/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- ❌ grpc-js-1.14.3.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Impact An invalid incoming HTTP/2 stream initiation can cause a server process to crash. This affects all servers created using @grpc/grpc-js. Patches The following version have fixes for this vulnerability: - 1.9.16 - 1.10.12 - 1.11.4 - 1.12.7 - 1.13.5 - 1.14.4 Workarounds There is no workaround.
Publish Date: 2026-06-12
URL: CVE-2026-48068
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-5375-pq7m-f5r2
Release Date: 2026-06-11
Fix Resolution: @grpc/grpc-js - 1.14.4,@grpc/grpc-js - 1.10.12,@grpc/grpc-js - 1.11.4,@grpc/grpc-js - 1.13.5,@grpc/grpc-js - 1.12.7,@grpc/grpc-js - 1.9.16
Step up your Open Source Security Game with Mend here
CVE-2026-44705
Vulnerable Library - tmp-0.2.5.tgz
Temporary file and directory creator
Library home page: https://registry.npmjs.org/tmp/-/tmp-0.2.5.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/tmp@0.2.5/node_modules/tmp/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- ❌ tmp-0.2.5.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
tmp is a temporary file and directory creator for node.js. Prior to 0.2.6, the tmp npm package contains a path traversal vulnerability that allows escaping the intended temporary directory when untrusted data flows into the prefix, postfix, or dir options. By embedding traversal sequences (e.g., ../) or path separators in these parameters, attackers can cause files to be created outside the configured temporary base directory at attacker-controlled locations with the privileges of the running process. This vulnerability affects applications that pass user-controlled data to tmp's file/directory creation functions without proper input sanitization. This vulnerability is fixed in 0.2.6.
Publish Date: 2026-06-11
URL: CVE-2026-44705
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: None
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-05-27
Fix Resolution: https://github.com/raszi/node-tmp.git - v0.2.6
Step up your Open Source Security Game with Mend here
CVE-2026-35209
Vulnerable Library - defu-6.1.4.tgz
Library home page: https://registry.npmjs.org/defu/-/defu-6.1.4.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/defu@6.1.4/node_modules/defu/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- ❌ defu-6.1.4.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
defu is software that allows uers to assign default properties recursively. Prior to version 6.1.5, applications that pass unsanitized user input (e.g. parsed JSON request bodies, database records, or config files from untrusted sources) as the first argument to "defu()" are vulnerable to prototype pollution. A crafted payload containing a "proto" key can override intended default values in the merged resul. The internal "_defu" function used "Object.assign({}, defaults)" to copy the defaults object. "Object.assign" invokes the "proto" setter, which replaces the resulting object's "[[Prototype]]" with attacker-controlled values. Properties inherited from the polluted prototype then bypass the existing "proto" key guard in the "for...in" loop and land in the final result. Version 6.1.5 replaces "Object.assign({}, defaults)" with object spread ("{ ...defaults }"), which uses "[[DefineOwnProperty]]" and does not invoke the "proto" setter.
Publish Date: 2026-04-06
URL: CVE-2026-35209
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-737v-mqg7-c878
Release Date: 2026-04-04
Fix Resolution: defu - 6.1.5
Step up your Open Source Security Game with Mend here
CVE-2026-12151
Vulnerable Library - undici-6.25.0.tgz
An HTTP/1.1 client, written from scratch for Node.js
Library home page: https://registry.npmjs.org/undici/-/undici-6.25.0.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/undici@6.25.0/node_modules/undici/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- arborist-9.4.3.tgz
- run-script-10.0.4.tgz
- node-gyp-12.3.0.tgz
- ❌ undici-6.25.0.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Impact:
The undici WebSocket client enforces maxPayloadSize on the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.
Affected applications are those using the undici WebSocket client (new WebSocket(...)) or the WebSocketStream API that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.
All releases starting at undici 6.17.0 are affected.
Patches: Upgrade to undici >= 6.26.0, >= 7.28.0, or >= 8.5.0. Workarounds:
No workaround is available. The fix must be applied through an upgrade.
Publish Date: 2026-06-17
URL: CVE-2026-12151
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-vxpw-j846-p89q
Release Date: 2026-06-17
Fix Resolution: undici - 8.5.0,undici - 7.28.0,undici - 6.27.0,https://github.com/nodejs/undici.git - v7.28.0,https://github.com/nodejs/undici.git - v6.27.0,https://github.com/nodejs/undici.git - v8.5.0
Step up your Open Source Security Game with Mend here
CVE-2026-53655
Vulnerable Library - tar-7.5.13.tgz
tar for node
Library home page: https://registry.npmjs.org/tar/-/tar-7.5.13.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json,/node_modules/.pnpm/tar@7.5.13/node_modules/tar/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- arborist-9.4.3.tgz
- pacote-21.5.0.tgz
- ❌ tar-7.5.13.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Summary "tar" (node-tar) applies a PAX extended header's "size=" record (and other PAX overrides) to the next header entry of any type, including intermediary metadata headers such as a GNU long-name ("L") or long-link ("K") entry. Per POSIX pax, a PAX extended header ("x") describes the next file entry, not the intermediary extension headers that may sit between the "x" header and the file it annotates. Because node-tar lets the PAX "size" override the byte length of an intervening "L"/"K"/"x" header, an attacker can desynchronize node-tar's stream cursor relative to every other mainstream tar implementation (GNU tar, libarchive/bsdtar, Python "tarfile", and the now-fixed "tar-rs" / "astral-tokio-tar"). The result is a tar parser interpretation differential (CWE-436): a single crafted archive yields a different set of members under node-tar than under the reference tar tools. An attacker can use this to hide a member from one parser while it is visible to another, which defeats security tooling whose scanner and extractor disagree on archive contents (e.g. a malware/secret scanner that lists entries with one library while a downstream step extracts with another). node-tar is one of the most widely deployed JavaScript tar libraries (it backs "npm"'s own package-tarball handling and is a transitive dependency of a very large fraction of the npm ecosystem), so the blast radius for "files that extract differently depending on the tool" is broad. This is the same root cause and fix that was just addressed upstream in the Rust tar ecosystem ("tar-rs" / "astral-tokio-tar"); node-tar carries the equivalent defect and has no equivalent guard. Impact - CWE-436 Interpretation Conflict / inconsistent tar parsing (the same class as the prior tar "smuggling" advisories GHSA-j5gw-2vrg-8fgx and GHSA-fp55-jw48-c537). - A crafted archive can present one logical member list to a tool that lists or scans with node-tar and a different member list to GNU tar / libarchive / Python tarfile (and vice versa). This lets a malicious file be hidden from a scanner that uses a different parser than the eventual extractor, or hidden from node-tar-based inspection while still landing on disk via a system "tar". - No authentication is required; the only precondition is that a victim parses an attacker-supplied tar with node-tar. Tar archives are routinely fetched from untrusted sources (package registries, user uploads, CI artifacts, container layers). - Severity: Medium. Impact is integrity-of-archive-interpretation, not direct RCE; it is a building block for supply-chain / scanner-evasion attacks rather than a standalone code-execution primitive. Vulnerable code (file:line) "src/header.ts" (compiled to "dist/esm/header.js:49" and "dist/commonjs/header.js:85" in the published "tar@7.5.15"): // Header.decode(buf, off, ex, gex) this.size = ex?.size ?? gex?.size ?? decNumber(buf, off + 124, 12) "ex" is the currently-accumulated PAX local extended header and "gex" the PAX global header. The "size" override from "ex"/"gex" is applied unconditionally to whatever header is being decoded next — there is no check that the header being decoded is a real file entry rather than an intermediary extension header. "src/parse.ts", "[CONSUMEHEADER]" constructs the next header with the current "EX"/"GEX" applied: const header = new Header(chunk, position, this[EX], this[GEX]) and later branches on whether that header is a metadata entry. "this[EX]" is cleared only in the non-meta (real file) branch: if (entry.meta) { // L / K / x / g metadata entries: this[EX] is left intact here if (entry.size > this.maxMetaEntrySize) { entry.ignore = true this[STATE] = 'ignore' entry.resume() } else if (entry.size > 0) { this[META] = '' entry.on('data', c => (this[META] += c)) this[STATE] = 'meta' } } else { this[EX] = undefined // EX cleared only once a real file entry is reached } When the stream is ordered "x (PAX, size=N) -> L (GNU long-name) -> file", the "L" header is constructed with "this[EX]" still set, so its "size"/"remain" becomes "N" instead of the "L" payload's true length. node-tar then consumes "N" bytes of "metadata" and resumes header parsing at the wrong offset, landing mid-stream. Every other mainstream parser applies the PAX "size" only to the following file entry, so they stay synchronized. The correct behavior (and the fix shipped upstream in the Rust tar ecosystem) is to not apply PAX "size"/overrides when the entry being decoded is itself an extension header ("L" GNU long-name, "K" GNU long-link, "x" PAX local, "g" PAX global). How input reaches the sink "tar.list()", "tar.extract()"/"tar.x()", and "tar.Parse"/"tar.Unpack" all route every 512-byte header block through "Header.decode(...)" with the currently-accumulated "EX"/"GEX". Any consumer that parses an attacker-supplied archive — "tar.list", "tar.extract", or piping into the streaming "Parser" — reaches the sink. No options need to be enabled; the default code path is affected. Proof of concept Archive layout (all standard, GNU-tar-producible blocks): block 0 : x header (PAX local extended, typeflag 'x'), its own size = len(pax body) block 1 : x payload : the single PAX record "...size=2048\n" block 2 : L header (GNU long-name '././@LongLink'), real size = 13 block 3 : L payload : "longname.txt\0" (the long name for the next file) block 4 : file header 'file_a', size = 16 block 5 : file_a body (16 bytes, zero-padded to 512) block 6 : file header 'file_b', size = 16 block 7 : file_b body (16 bytes, zero-padded to 512) Generator ("make_tar.py", pure stdlib, no external deps): def hdr(name, size, typeflag): h = bytearray(512); name = name[:100]; h[0:len(name)] = name h[100:108] = b'0000644\0'; h[108:116] = b'0000000\0'; h[116:124] = b'0000000\0' h[124:136] = ('%011o\0' % size).encode(); h[136:148] = b'00000000000\0' h[156:157] = typeflag; h[257:263] = b'ustar\0'; h[263:265] = b'00' h[148:156] = b' ' * 8 cs = sum(h); h[148:156] = ('%06o\0 ' % cs).encode() return bytes(h) def pad(d): return d + b'\0' * ((512 - len(d) % 512) % 512) def pax_record(key, val): # length-prefixed PAX record "LEN key=val\n" body = b' %s=%s\n' % (key.encode(), str(val).encode()); n = len(body) while True: s = str(n).encode() + body if len(s) == n: break n = len(s) return s pax = pax_record('size', 2048) # malicious: claim size=2048 for the "next" entry out = hdr(b'PaxHeaders/x', len(pax), b'x') + pad(pax) out += hdr(b'././@LongLink', 13, b'L') + pad(b'longname.txt\0') out += hdr(b'file_a', 16, b'0') + pad(b'AAAA_file_a_body') out += hdr(b'file_b', 16, b'0') + pad(b'BBBB_file_b_body') out += b'\0' * 1024 open('pax-desync.tar', 'wb').write(out) A negative-control archive is identical except the PAX record is "pax_record('comment', 'x')" (no "size="), written to "pax-control.tar". End-to-end reproduction (against pinned version "tar@7.5.15", latest release) Install the published package into a clean project and parse both archives: $ npm init -y >/dev/null && npm install tar@7.5.15 $ node -e "console.log(require('tar/package.json').version)" 7.5.15 $ grep -n "ex?.size ?? gex?.size" node_modules/tar/dist/esm/header.js 49: this.size = ex?.size ?? gex?.size ?? decNumber(buf, off + 124, 12); "e2e.mjs": import * as tar from 'tar' async function listEntries(f){ const got=[], warns=[] await tar.list({ file:f, onReadEntry:e=>{ got.push({path:e.path,size:e.size,type:e.type}); e.resume() }, onwarn:(code,_msg)=>warns.push(code) }) return { got, warns } } const mal = await listEntries('pax-desync.tar') console.log('MALICIOUS entries :', JSON.stringify(mal.got), 'warnings:', JSON.stringify(mal.warns)) const ctl = await listEntries('pax-control.tar') console.log('CONTROL entries :', JSON.stringify(ctl.got), 'warnings:', JSON.stringify(ctl.warns)) Verbatim output: === Deployed-consumer E2E: npm tar@7.5.15 (latest release) === [MALICIOUS] archive = x(PAX size=2048) -> L(GNU longname "longname.txt") -> file_a(16B) -> file_b(16B) tar.list() entries : [] tar.list() warnings: ["TAR_ENTRY_INVALID"] [NEGATIVE CONTROL] same archive, PAX record is "comment=x" (no size= override) tar.list() entries : [{"path":"longname.txt","size":16,"type":"File"},{"path":"file_b","size":16,"type":"File"}] tar.list() warnings: [] Reference parsers on the same "pax-desync.tar": $ tar tvf pax-desync.tar -rw-r--r-- 0 0 0 2048 Jan 1 1970 longname.txt # GNU tar $ bsdtar tvf pax-desync.tar -rw-r--r-- 0 0 0 2048 Jan 1 1970 longname.txt # libarchive $ python3 -c "import tarfile; print([m.name for m in tarfile.open('pax-desync.tar').getmembers()])" ['longname.txt'] # Python tarfile Interpretation differential: GNU tar, libarchive (bsdtar), and Python "tarfile" all extract the member "longname.txt" from "pax-desync.tar", whereas node-tar "7.5.15" desynchronizes, raises "TAR_ENTRY_INVALID" (checksum failure from landing mid-stream), and reports zero members. The negative control proves the divergence is caused solely by the PAX "size=" override being applied to the intermediary "L" header — when the same archive carries a PAX record without "size=", node-tar parses it identically to the reference tools ("longname.txt", "file_b"). Suggested fix When decoding a header, do not apply PAX "size" (or other PAX overrides) if the header being decoded is itself an extension header. Concretely, in "src/parse.ts" clear/ignore "this[EX]" (and "this[GEX]" for "size") when the header's type is "ExtendedHeader", "GlobalExtendedHeader", "NextFileHasLongPath" (GNU "L"), or "NextFileHasLongLinkpath" (GNU "K"); equivalently, in "Header.decode", gate the "ex?.size ?? gex?.size" override on the decoded type not being one of those extension types. This mirrors the upstream Rust fix, which guards "pax_size" with "is_gnu_longname || is_gnu_longlink || is_pax_local_extensions || is_pax_global_extensions". A fix PR is being prepared against a private fork and will be linked here. Fix PR To be linked from a private fork of the repository (the fix will not be pushed to any public fork or to upstream during embargo). Credits Reported by tonghuaroot.
Publish Date: 2026-06-15
URL: CVE-2026-53655
CVSS 3 Score Details (6.2)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Local
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-vmf3-w455-68vh
Release Date: 2026-06-15
Fix Resolution: tar - 7.5.16
Step up your Open Source Security Game with Mend here
CVE-2026-9679
Vulnerable Library - undici-6.25.0.tgz
An HTTP/1.1 client, written from scratch for Node.js
Library home page: https://registry.npmjs.org/undici/-/undici-6.25.0.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/undici@6.25.0/node_modules/undici/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- arborist-9.4.3.tgz
- run-script-10.0.4.tgz
- node-gyp-12.3.0.tgz
- ❌ undici-6.25.0.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Impact:
undici's cookie parser in parseSetCookie percent-decodes cookie values via qsUnescape, turning encoded sequences like %0D%0A, %00, %3B, and %3D into their literal byte equivalents. RFC 6265 §5.4 does not specify any decoding and browsers do not decode either.
Applications that parse a Set-Cookie header and then forward the parsed value into a response header (proxies, middleware, SSR frameworks) become vulnerable to HTTP response header injection: an attacker-controlled upstream can inject arbitrary Set-Cookie, Location, or Cache-Control headers into the application's downstream response, enabling session fixation, open redirect, or cache poisoning.
Affected applications are those that use undici's cookie parsing (parseSetCookie, parseCookie, getSetCookies) and forward the parsed cookie value into a response header.
This was introduced in undici 7.0.0 via PR #3789.
Patches:
Upgrade to undici v6.26.0, v7.28.0 or v8.5.0.
Workarounds:
If upgrade is not immediately possible, do not forward values returned by parseSetCookie/parseCookie/getSetCookies directly into response headers; sanitize the value first to strip or reject CR, LF, NUL, ;, and = bytes.
Publish Date: 2026-06-17
URL: CVE-2026-9679
CVSS 3 Score Details (5.9)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-p88m-4jfj-68fv
Release Date: 2026-06-17
Fix Resolution: undici - 7.28.0,undici - 6.27.0,undici - 8.5.0,https://github.com/nodejs/undici.git - v7.28.0,https://github.com/nodejs/undici.git - v6.27.0,https://github.com/nodejs/undici.git - v8.5.0
Step up your Open Source Security Game with Mend here
CVE-2026-54285
Vulnerable Library - core-1.30.1.tgz
OpenTelemetry Core provides constants and utilities shared by all OpenTelemetry SDK packages.
Library home page: https://registry.npmjs.org/@opentelemetry/core/-/core-1.30.1.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json,/node_modules/.pnpm/@opentelemetry+core@1.30.1_@opentelemetry+api@1.9.1/node_modules/@opentelemetry/core/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- exporter-zipkin-1.30.1.tgz
- ❌ core-1.30.1.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Overview "W3CBaggagePropagator.extract()" in "@opentelemetry/core" does not enforce size limits when parsing inbound "baggage" HTTP 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-size" of 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 "TextMapGetter" implementations) or deployments that have raised "--max-http-header-size". Remediation Update "@opentelemetry/core" to version 2.8.0 or later. The fix enforces limits consistent with the W3C Baggage specification at the propagator level: - Maximum total baggage size: 8,192 bytes - Maximum number of entries: 180 - Maximum per-entry size: 4,096 bytes 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 - "W3C Baggage Specification - Limits" (https://www.w3.org/TR/baggage/#limits) - opentelemetry-java: "GHSA-rcgg-9c38-7xpx" (GHSA-rcgg-9c38-7xpx) - opentelemetry-go: "GHSA-mh2q-q3fh-2475" (GHSA-mh2q-q3fh-2475) Credit Reported by tonghuaroot.
Publish Date: 2026-06-15
URL: CVE-2026-54285
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-06-15
Fix Resolution: https://github.com/open-telemetry/opentelemetry-js.git - v2.8.0
Step up your Open Source Security Game with Mend here
CVE-2026-54269
Vulnerable Library - protobufjs-7.5.6.tgz
Protocol Buffers for JavaScript (& TypeScript).
Library home page: https://registry.npmjs.org/protobufjs/-/protobufjs-7.5.6.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/protobufjs@7.5.6/node_modules/protobufjs/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- exporter-trace-otlp-grpc-0.57.2.tgz
- otlp-transformer-0.57.2.tgz
- ❌ protobufjs-7.5.6.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Summary protobufjs accepted certain schema-derived names that could collide with properties used by protobufjs runtime helpers. The known affected names are fields named "hasOwnProperty", field or oneof names such as "$type" when loaded through protobufjs JSON/reflection descriptors, and service methods whose generated helper name is "rpcCall". When affected message or service types were used, protobufjs could read schema-controlled data where it expected an own-property helper, reflected type metadata, or the base RPC helper. This could cause deterministic exceptions or recursive calls in affected decode post-checks, verification, object conversion, reflected JSON serialization, or protobufjs RPC helper invocation. Impact An attacker who can provide or influence protobuf schemas or protobufjs JSON descriptors may be able to make affected message or service types unusable, resulting in denial of service for the affected processing path. Applications using only trusted schemas are affected only if those schemas contain one of the problematic names and the application reaches the affected API path. The issue is not known to allow code execution by itself. Preconditions * The application must use an affected protobufjs version. * The application must load or use a schema or protobufjs JSON descriptor containing one of the problematic names: * a field named "hasOwnProperty", * a field or oneof named "$type" through protobufjs JSON/reflection descriptor input, * or a service method whose generated helper name is "rpcCall". * The application must reach the affected API path for that name: required-field decode post-checks, "verify", or "toObject" for "hasOwnProperty"; reflected message JSON serialization for "$type"; or protobufjs RPC service invocation for "rpcCall". Workarounds Do not load protobuf schemas or protobufjs JSON descriptors from untrusted sources with affected versions. If untrusted schemas or descriptors must be accepted, validate schema-derived field, oneof, and service method names before loading and reject the problematic names described above. Applications using trusted schemas can avoid the issue by renaming affected fields or service methods, or by avoiding the affected API path.
Publish Date: 2026-06-15
URL: CVE-2026-54269
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-f38q-mgvj-vph7
Release Date: 2026-06-15
Fix Resolution: protobufjs-cli - 2.5.1,protobufjs - 7.6.3,protobufjs - 8.6.0,protobufjs-cli - 1.3.3
Step up your Open Source Security Game with Mend here
CVE-2026-53550
Vulnerable Library - js-yaml-3.14.2.tgz
YAML 1.2 parser and serializer
Library home page: https://registry.npmjs.org/js-yaml/-/js-yaml-3.14.2.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/js-yaml@3.14.2/node_modules/js-yaml/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- ❌ js-yaml-3.14.2.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Summary A crafted YAML document can trigger algorithmic CPU exhaustion in "js-yaml" merge-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 is "tag:yaml.org,2002:merge". - For each element, it calls "mergeMappings(...)". - "mergeMappings(...)" computes "Object.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 if (keyTag === 'tag:yaml.org,2002:merge') { if (Array.isArray(valueNode)) { for (index = 0, quantity = valueNode.length; index < quantity; index += 1) { mergeMappings(state, _result, valueNode[index], overridableKeys); } } else { mergeMappings(state, _result, valueNode, overridableKeys); } } When the merge value is a sequence (YAML 1.1 <<: [ *a, *a, ... ]), each element is handed to mergeMappings() without deduplication. mergeMappings() then does sourceKeys = Object.keys(source); for (index = 0; index < sourceKeys.length; index += 1) { key = sourceKeys[index]; if (!_hasOwnProperty.call(destination, key)) { setProperty(destination, key, source[key]); overridableKeys[key] = true; } } 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: * one Object.keys(source) call (O(K)) * K _hasOwnProperty.call checks on the destination 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: if (keyTag === 'tag:yaml.org,2002:merge') { if (Array.isArray(valueNode)) { var seen = new Set(); for (index = 0, quantity = valueNode.length; index < quantity; index += 1) { var src = valueNode[index]; if (seen.has(src)) continue; // idempotent; skip redundant alias seen.add(src); mergeMappings(state, _result, src, overridableKeys); } } else { mergeMappings(state, _result, valueNode, overridableKeys); } }
Publish Date: 2026-06-15
URL: CVE-2026-53550
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Release Date: 2026-06-15
Fix Resolution: https://github.com/nodeca/js-yaml.git - 4.2.0
Step up your Open Source Security Game with Mend here
CVE-2026-45740
Vulnerable Library - protobufjs-7.5.6.tgz
Protocol Buffers for JavaScript (& TypeScript).
Library home page: https://registry.npmjs.org/protobufjs/-/protobufjs-7.5.6.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/protobufjs@7.5.6/node_modules/protobufjs/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- exporter-trace-otlp-grpc-0.57.2.tgz
- otlp-transformer-0.57.2.tgz
- ❌ protobufjs-7.5.6.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
protobufjs compiles protobuf definitions into JavaScript (JS) functions. Prior to 7.5.8 and 8.2.0, protobufjs could recurse without a depth limit while expanding nested JSON descriptors through Root.fromJSON() and Namespace.addJSON(). A crafted JSON descriptor with deeply nested namespace definitions could cause the JavaScript call stack to be exhausted during descriptor loading. This vulnerability is fixed in 7.5.8 and 8.2.0.
Publish Date: 2026-05-13
URL: CVE-2026-45740
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: https://www.mend.io/vulnerability-database/CVE-2026-45740
Release Date: 2026-05-13
Fix Resolution (protobufjs): 7.5.8
Direct dependency fix Resolution (@storm-software/pulumi-tools): 0.22.172
Step up your Open Source Security Game with Mend here
CVE-2026-9358
Vulnerable Library - postcss-selector-parser-7.1.1.tgz
> Selector parser with built in methods for working with selector strings.
Library home page: https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.1.1.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/postcss-selector-parser@7.1.1/node_modules/postcss-selector-parser/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- arborist-9.4.3.tgz
- query-5.0.0.tgz
- ❌ postcss-selector-parser-7.1.1.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
A vulnerability was determined in postcss-selector-parser up to 6.1.2/7.1.2. Affected is the function toString of the file src/selectors/container.js of the component AST Serialization. Executing a manipulation can lead to uncontrolled recursion. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. Upgrading to version 6.1.3 and 7.1.3 is able to address this issue. This patch is called 5bc698cef66f8abd12610dc623e5d67cbc0f869d. It is suggested to upgrade the affected component. The vendor explains, that according to his definition "DoS on server-side on user-generated CSS is low risk for us (since most users compile own CSS with PostCSS)." The commits were backported to 6.x branch, which was the most downloaded version.
Publish Date: 2026-05-24
URL: CVE-2026-9358
CVSS 3 Score Details (4.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low
For more information on CVSS3 Scores, click here.
Step up your Open Source Security Game with Mend here
CVE-2026-6733
Vulnerable Library - undici-6.25.0.tgz
An HTTP/1.1 client, written from scratch for Node.js
Library home page: https://registry.npmjs.org/undici/-/undici-6.25.0.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/undici@6.25.0/node_modules/undici/package.json
Dependency Hierarchy:
- pulumi-tools-0.22.171.tgz (Root Library)
- pulumi-3.232.0.tgz
- arborist-9.4.3.tgz
- run-script-10.0.4.tgz
- node-gyp-12.3.0.tgz
- ❌ undici-6.25.0.tgz (Vulnerable Library)
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Impact:
Undici's HTTP/1.1 client is vulnerable to response queue poisoning on reused keep-alive sockets. An attacker-controlled upstream server can inject an unsolicited HTTP/1.1 response onto an idle socket after a request completes. When the client dispatches the next request on that socket, it associates the injected response with the new request, causing responses to be delivered to the wrong requests.
This requires an attacker-controlled or compromised upstream HTTP/1.1 server and keep-alive connection reuse.
Patches:
Upgrade to undici v6.26.0, v7.28.0 or v8.5.0.
Workarounds:
Disable keep-alive connection reuse by setting keepAliveTimeout: 0 on the Client or Pool.
Publish Date: 2026-06-17
URL: CVE-2026-6733
CVSS 3 Score Details (3.7)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.
Suggested Fix
Type: Upgrade version
Origin: GHSA-35p6-xmwp-9g52
Release Date: 2026-06-17
Fix Resolution: undici - 7.28.0,undici - 8.5.0,undici - 6.27.0
Step up your Open Source Security Game with Mend here
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/tmp@0.2.5/node_modules/tmp/package.json
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Vulnerabilities
*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.
**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation
Details
Vulnerable Library - pacote-21.5.0.tgz
JavaScript package downloader
Library home page: https://registry.npmjs.org/pacote/-/pacote-21.5.0.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json,/node_modules/.pnpm/pacote@21.5.0/node_modules/pacote/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Versions of the package pacote from 11.2.7 are vulnerable to Denial of Service (DoS) via the addGitSha function. An attacker can exploit this vulnerability by supplying a specially crafted spec.rawSpec value that triggers the function’s regex replacement and string-manipulation logic, causing excessive CPU consumption and potentially stalling or crashing the process.
Publish Date: 2026-05-26
URL: CVE-2026-9496
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.Step up your Open Source Security Game with Mend here
Vulnerable Library - protobufjs-7.5.6.tgz
Protocol Buffers for JavaScript (& TypeScript).
Library home page: https://registry.npmjs.org/protobufjs/-/protobufjs-7.5.6.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/protobufjs@7.5.6/node_modules/protobufjs/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Summary protobufjs could recurse without a depth limit while converting decoded messages to plain objects or JSON. This affected generated "toObject()" conversion and the custom "google.protobuf.Any" JSON conversion path. A crafted protobuf binary payload containing deeply nested "Any" values could cause the JavaScript call stack to be exhausted during conversion to JSON. Impact An attacker who can provide protobuf binary data decoded by an application may be able to crash the process or otherwise cause message conversion to fail with a stack overflow. This affects applications that decode untrusted protobuf input containing "google.protobuf.Any" values and then convert decoded messages to JSON or plain objects with JSON conversion enabled, for example through "JSON.stringify(message)", "Message#toJSON()", or "Type.toObject(message, { json: true })". Applications that only decode and re-encode protobuf binary data without converting decoded messages to JSON are not directly affected by this issue. Preconditions * The application must decode protobuf binary data influenced by an attacker. * The application schema must include "google.protobuf.Any", and the referenced "type_url" must resolve to a message type in the loaded protobuf root. * The application must convert the decoded message to JSON or a plain object through an affected conversion path. * The crafted input must contain deeply nested "Any" values that are expanded during conversion. Workarounds Avoid converting untrusted protobuf messages containing "google.protobuf.Any" values to JSON with affected versions. If immediate upgrade is not possible, reject or limit messages with deeply nested "Any" payloads at an outer protocol boundary where feasible, avoid JSON conversion of untrusted "Any" values, or isolate message conversion in a process that can be safely restarted.
Publish Date: 2026-06-15
URL: CVE-2026-48712
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-wcpc-wj8m-hjx6
Release Date: 2026-06-15
Fix Resolution: protobufjs - 8.4.1,protobufjs - 7.6.1
Step up your Open Source Security Game with Mend here
Vulnerable Library - grpc-js-1.14.3.tgz
gRPC Library for Node - pure JS implementation
Library home page: https://registry.npmjs.org/@grpc/grpc-js/-/grpc-js-1.14.3.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json,/node_modules/.pnpm/@grpc+grpc-js@1.14.3/node_modules/@grpc/grpc-js/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Impact An invalid incoming compressed message can cause a client or server process to crash. This affects all clients and servers that use @grpc/grpc-js Patches The following version have fixes for this vulnerability: - 1.9.16 - 1.10.12 - 1.11.4 - 1.12.7 - 1.13.5 - 1.14.4 Workarounds There is no workaround.
Publish Date: 2026-06-12
URL: CVE-2026-48069
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-99f4-grh7-6pcq
Release Date: 2026-06-11
Fix Resolution: @grpc/grpc-js - 1.12.7,@grpc/grpc-js - 1.14.4,@grpc/grpc-js - 1.13.5,@grpc/grpc-js - 1.9.16,@grpc/grpc-js - 1.10.12,@grpc/grpc-js - 1.11.4
Step up your Open Source Security Game with Mend here
Vulnerable Library - grpc-js-1.14.3.tgz
gRPC Library for Node - pure JS implementation
Library home page: https://registry.npmjs.org/@grpc/grpc-js/-/grpc-js-1.14.3.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json,/node_modules/.pnpm/@grpc+grpc-js@1.14.3/node_modules/@grpc/grpc-js/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Impact An invalid incoming HTTP/2 stream initiation can cause a server process to crash. This affects all servers created using @grpc/grpc-js. Patches The following version have fixes for this vulnerability: - 1.9.16 - 1.10.12 - 1.11.4 - 1.12.7 - 1.13.5 - 1.14.4 Workarounds There is no workaround.
Publish Date: 2026-06-12
URL: CVE-2026-48068
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-5375-pq7m-f5r2
Release Date: 2026-06-11
Fix Resolution: @grpc/grpc-js - 1.14.4,@grpc/grpc-js - 1.10.12,@grpc/grpc-js - 1.11.4,@grpc/grpc-js - 1.13.5,@grpc/grpc-js - 1.12.7,@grpc/grpc-js - 1.9.16
Step up your Open Source Security Game with Mend here
Vulnerable Library - tmp-0.2.5.tgz
Temporary file and directory creator
Library home page: https://registry.npmjs.org/tmp/-/tmp-0.2.5.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/tmp@0.2.5/node_modules/tmp/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
tmp is a temporary file and directory creator for node.js. Prior to 0.2.6, the tmp npm package contains a path traversal vulnerability that allows escaping the intended temporary directory when untrusted data flows into the prefix, postfix, or dir options. By embedding traversal sequences (e.g., ../) or path separators in these parameters, attackers can cause files to be created outside the configured temporary base directory at attacker-controlled locations with the privileges of the running process. This vulnerability affects applications that pass user-controlled data to tmp's file/directory creation functions without proper input sanitization. This vulnerability is fixed in 0.2.6.
Publish Date: 2026-06-11
URL: CVE-2026-44705
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: High
- Integrity Impact: None
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-05-27
Fix Resolution: https://github.com/raszi/node-tmp.git - v0.2.6
Step up your Open Source Security Game with Mend here
Vulnerable Library - defu-6.1.4.tgz
Library home page: https://registry.npmjs.org/defu/-/defu-6.1.4.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/defu@6.1.4/node_modules/defu/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
defu is software that allows uers to assign default properties recursively. Prior to version 6.1.5, applications that pass unsanitized user input (e.g. parsed JSON request bodies, database records, or config files from untrusted sources) as the first argument to "defu()" are vulnerable to prototype pollution. A crafted payload containing a "proto" key can override intended default values in the merged resul. The internal "_defu" function used "Object.assign({}, defaults)" to copy the defaults object. "Object.assign" invokes the "proto" setter, which replaces the resulting object's "[[Prototype]]" with attacker-controlled values. Properties inherited from the polluted prototype then bypass the existing "proto" key guard in the "for...in" loop and land in the final result. Version 6.1.5 replaces "Object.assign({}, defaults)" with object spread ("{ ...defaults }"), which uses "[[DefineOwnProperty]]" and does not invoke the "proto" setter.
Publish Date: 2026-04-06
URL: CVE-2026-35209
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-737v-mqg7-c878
Release Date: 2026-04-04
Fix Resolution: defu - 6.1.5
Step up your Open Source Security Game with Mend here
Vulnerable Library - undici-6.25.0.tgz
An HTTP/1.1 client, written from scratch for Node.js
Library home page: https://registry.npmjs.org/undici/-/undici-6.25.0.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/undici@6.25.0/node_modules/undici/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Impact:
The undici WebSocket client enforces maxPayloadSize on the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.
Affected applications are those using the undici WebSocket client (new WebSocket(...)) or the WebSocketStream API that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.
All releases starting at undici 6.17.0 are affected.
Patches: Upgrade to undici >= 6.26.0, >= 7.28.0, or >= 8.5.0. Workarounds:
No workaround is available. The fix must be applied through an upgrade.
Publish Date: 2026-06-17
URL: CVE-2026-12151
CVSS 3 Score Details (7.5)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: High
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-vxpw-j846-p89q
Release Date: 2026-06-17
Fix Resolution: undici - 8.5.0,undici - 7.28.0,undici - 6.27.0,https://github.com/nodejs/undici.git - v7.28.0,https://github.com/nodejs/undici.git - v6.27.0,https://github.com/nodejs/undici.git - v8.5.0
Step up your Open Source Security Game with Mend here
Vulnerable Library - tar-7.5.13.tgz
tar for node
Library home page: https://registry.npmjs.org/tar/-/tar-7.5.13.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json,/node_modules/.pnpm/tar@7.5.13/node_modules/tar/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Summary "tar" (node-tar) applies a PAX extended header's "size=" record (and other PAX overrides) to the next header entry of any type, including intermediary metadata headers such as a GNU long-name ("L") or long-link ("K") entry. Per POSIX pax, a PAX extended header ("x") describes the next file entry, not the intermediary extension headers that may sit between the "x" header and the file it annotates. Because node-tar lets the PAX "size" override the byte length of an intervening "L"/"K"/"x" header, an attacker can desynchronize node-tar's stream cursor relative to every other mainstream tar implementation (GNU tar, libarchive/bsdtar, Python "tarfile", and the now-fixed "tar-rs" / "astral-tokio-tar"). The result is a tar parser interpretation differential (CWE-436): a single crafted archive yields a different set of members under node-tar than under the reference tar tools. An attacker can use this to hide a member from one parser while it is visible to another, which defeats security tooling whose scanner and extractor disagree on archive contents (e.g. a malware/secret scanner that lists entries with one library while a downstream step extracts with another). node-tar is one of the most widely deployed JavaScript tar libraries (it backs "npm"'s own package-tarball handling and is a transitive dependency of a very large fraction of the npm ecosystem), so the blast radius for "files that extract differently depending on the tool" is broad. This is the same root cause and fix that was just addressed upstream in the Rust tar ecosystem ("tar-rs" / "astral-tokio-tar"); node-tar carries the equivalent defect and has no equivalent guard. Impact - CWE-436 Interpretation Conflict / inconsistent tar parsing (the same class as the prior tar "smuggling" advisories GHSA-j5gw-2vrg-8fgx and GHSA-fp55-jw48-c537). - A crafted archive can present one logical member list to a tool that lists or scans with node-tar and a different member list to GNU tar / libarchive / Python tarfile (and vice versa). This lets a malicious file be hidden from a scanner that uses a different parser than the eventual extractor, or hidden from node-tar-based inspection while still landing on disk via a system "tar". - No authentication is required; the only precondition is that a victim parses an attacker-supplied tar with node-tar. Tar archives are routinely fetched from untrusted sources (package registries, user uploads, CI artifacts, container layers). - Severity: Medium. Impact is integrity-of-archive-interpretation, not direct RCE; it is a building block for supply-chain / scanner-evasion attacks rather than a standalone code-execution primitive. Vulnerable code (file:line) "src/header.ts" (compiled to "dist/esm/header.js:49" and "dist/commonjs/header.js:85" in the published "tar@7.5.15"): // Header.decode(buf, off, ex, gex) this.size = ex?.size ?? gex?.size ?? decNumber(buf, off + 124, 12) "ex" is the currently-accumulated PAX local extended header and "gex" the PAX global header. The "size" override from "ex"/"gex" is applied unconditionally to whatever header is being decoded next — there is no check that the header being decoded is a real file entry rather than an intermediary extension header. "src/parse.ts", "[CONSUMEHEADER]" constructs the next header with the current "EX"/"GEX" applied: const header = new Header(chunk, position, this[EX], this[GEX]) and later branches on whether that header is a metadata entry. "this[EX]" is cleared only in the non-meta (real file) branch: if (entry.meta) { // L / K / x / g metadata entries: this[EX] is left intact here if (entry.size > this.maxMetaEntrySize) { entry.ignore = true this[STATE] = 'ignore' entry.resume() } else if (entry.size > 0) { this[META] = '' entry.on('data', c => (this[META] += c)) this[STATE] = 'meta' } } else { this[EX] = undefined // EX cleared only once a real file entry is reached } When the stream is ordered "x (PAX, size=N) -> L (GNU long-name) -> file", the "L" header is constructed with "this[EX]" still set, so its "size"/"remain" becomes "N" instead of the "L" payload's true length. node-tar then consumes "N" bytes of "metadata" and resumes header parsing at the wrong offset, landing mid-stream. Every other mainstream parser applies the PAX "size" only to the following file entry, so they stay synchronized. The correct behavior (and the fix shipped upstream in the Rust tar ecosystem) is to not apply PAX "size"/overrides when the entry being decoded is itself an extension header ("L" GNU long-name, "K" GNU long-link, "x" PAX local, "g" PAX global). How input reaches the sink "tar.list()", "tar.extract()"/"tar.x()", and "tar.Parse"/"tar.Unpack" all route every 512-byte header block through "Header.decode(...)" with the currently-accumulated "EX"/"GEX". Any consumer that parses an attacker-supplied archive — "tar.list", "tar.extract", or piping into the streaming "Parser" — reaches the sink. No options need to be enabled; the default code path is affected. Proof of concept Archive layout (all standard, GNU-tar-producible blocks): block 0 : x header (PAX local extended, typeflag 'x'), its own size = len(pax body) block 1 : x payload : the single PAX record "...size=2048\n" block 2 : L header (GNU long-name '././@LongLink'), real size = 13 block 3 : L payload : "longname.txt\0" (the long name for the next file) block 4 : file header 'file_a', size = 16 block 5 : file_a body (16 bytes, zero-padded to 512) block 6 : file header 'file_b', size = 16 block 7 : file_b body (16 bytes, zero-padded to 512) Generator ("make_tar.py", pure stdlib, no external deps): def hdr(name, size, typeflag): h = bytearray(512); name = name[:100]; h[0:len(name)] = name h[100:108] = b'0000644\0'; h[108:116] = b'0000000\0'; h[116:124] = b'0000000\0' h[124:136] = ('%011o\0' % size).encode(); h[136:148] = b'00000000000\0' h[156:157] = typeflag; h[257:263] = b'ustar\0'; h[263:265] = b'00' h[148:156] = b' ' * 8 cs = sum(h); h[148:156] = ('%06o\0 ' % cs).encode() return bytes(h) def pad(d): return d + b'\0' * ((512 - len(d) % 512) % 512) def pax_record(key, val): # length-prefixed PAX record "LEN key=val\n" body = b' %s=%s\n' % (key.encode(), str(val).encode()); n = len(body) while True: s = str(n).encode() + body if len(s) == n: break n = len(s) return s pax = pax_record('size', 2048) # malicious: claim size=2048 for the "next" entry out = hdr(b'PaxHeaders/x', len(pax), b'x') + pad(pax) out += hdr(b'././@LongLink', 13, b'L') + pad(b'longname.txt\0') out += hdr(b'file_a', 16, b'0') + pad(b'AAAA_file_a_body') out += hdr(b'file_b', 16, b'0') + pad(b'BBBB_file_b_body') out += b'\0' * 1024 open('pax-desync.tar', 'wb').write(out) A negative-control archive is identical except the PAX record is "pax_record('comment', 'x')" (no "size="), written to "pax-control.tar". End-to-end reproduction (against pinned version "tar@7.5.15", latest release) Install the published package into a clean project and parse both archives: $ npm init -y >/dev/null && npm install tar@7.5.15 $ node -e "console.log(require('tar/package.json').version)" 7.5.15 $ grep -n "ex?.size ?? gex?.size" node_modules/tar/dist/esm/header.js 49: this.size = ex?.size ?? gex?.size ?? decNumber(buf, off + 124, 12); "e2e.mjs": import * as tar from 'tar' async function listEntries(f){ const got=[], warns=[] await tar.list({ file:f, onReadEntry:e=>{ got.push({path:e.path,size:e.size,type:e.type}); e.resume() }, onwarn:(code,_msg)=>warns.push(code) }) return { got, warns } } const mal = await listEntries('pax-desync.tar') console.log('MALICIOUS entries :', JSON.stringify(mal.got), 'warnings:', JSON.stringify(mal.warns)) const ctl = await listEntries('pax-control.tar') console.log('CONTROL entries :', JSON.stringify(ctl.got), 'warnings:', JSON.stringify(ctl.warns)) Verbatim output: === Deployed-consumer E2E: npm tar@7.5.15 (latest release) === [MALICIOUS] archive = x(PAX size=2048) -> L(GNU longname "longname.txt") -> file_a(16B) -> file_b(16B) tar.list() entries : [] tar.list() warnings: ["TAR_ENTRY_INVALID"] [NEGATIVE CONTROL] same archive, PAX record is "comment=x" (no size= override) tar.list() entries : [{"path":"longname.txt","size":16,"type":"File"},{"path":"file_b","size":16,"type":"File"}] tar.list() warnings: [] Reference parsers on the same "pax-desync.tar": $ tar tvf pax-desync.tar -rw-r--r-- 0 0 0 2048 Jan 1 1970 longname.txt # GNU tar $ bsdtar tvf pax-desync.tar -rw-r--r-- 0 0 0 2048 Jan 1 1970 longname.txt # libarchive $ python3 -c "import tarfile; print([m.name for m in tarfile.open('pax-desync.tar').getmembers()])" ['longname.txt'] # Python tarfile Interpretation differential: GNU tar, libarchive (bsdtar), and Python "tarfile" all extract the member "longname.txt" from "pax-desync.tar", whereas node-tar "7.5.15" desynchronizes, raises "TAR_ENTRY_INVALID" (checksum failure from landing mid-stream), and reports zero members. The negative control proves the divergence is caused solely by the PAX "size=" override being applied to the intermediary "L" header — when the same archive carries a PAX record without "size=", node-tar parses it identically to the reference tools ("longname.txt", "file_b"). Suggested fix When decoding a header, do not apply PAX "size" (or other PAX overrides) if the header being decoded is itself an extension header. Concretely, in "src/parse.ts" clear/ignore "this[EX]" (and "this[GEX]" for "size") when the header's type is "ExtendedHeader", "GlobalExtendedHeader", "NextFileHasLongPath" (GNU "L"), or "NextFileHasLongLinkpath" (GNU "K"); equivalently, in "Header.decode", gate the "ex?.size ?? gex?.size" override on the decoded type not being one of those extension types. This mirrors the upstream Rust fix, which guards "pax_size" with "is_gnu_longname || is_gnu_longlink || is_pax_local_extensions || is_pax_global_extensions". A fix PR is being prepared against a private fork and will be linked here. Fix PR To be linked from a private fork of the repository (the fix will not be pushed to any public fork or to upstream during embargo). Credits Reported by tonghuaroot.
Publish Date: 2026-06-15
URL: CVE-2026-53655
CVSS 3 Score Details (6.2)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Local
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-vmf3-w455-68vh
Release Date: 2026-06-15
Fix Resolution: tar - 7.5.16
Step up your Open Source Security Game with Mend here
Vulnerable Library - undici-6.25.0.tgz
An HTTP/1.1 client, written from scratch for Node.js
Library home page: https://registry.npmjs.org/undici/-/undici-6.25.0.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/undici@6.25.0/node_modules/undici/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Impact:
undici's cookie parser in parseSetCookie percent-decodes cookie values via qsUnescape, turning encoded sequences like %0D%0A, %00, %3B, and %3D into their literal byte equivalents. RFC 6265 §5.4 does not specify any decoding and browsers do not decode either.
Applications that parse a Set-Cookie header and then forward the parsed value into a response header (proxies, middleware, SSR frameworks) become vulnerable to HTTP response header injection: an attacker-controlled upstream can inject arbitrary Set-Cookie, Location, or Cache-Control headers into the application's downstream response, enabling session fixation, open redirect, or cache poisoning.
Affected applications are those that use undici's cookie parsing (parseSetCookie, parseCookie, getSetCookies) and forward the parsed cookie value into a response header.
This was introduced in undici 7.0.0 via PR #3789.
Patches:
Upgrade to undici v6.26.0, v7.28.0 or v8.5.0.
Workarounds:
If upgrade is not immediately possible, do not forward values returned by parseSetCookie/parseCookie/getSetCookies directly into response headers; sanitize the value first to strip or reject CR, LF, NUL, ;, and = bytes.
Publish Date: 2026-06-17
URL: CVE-2026-9679
CVSS 3 Score Details (5.9)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: High
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-p88m-4jfj-68fv
Release Date: 2026-06-17
Fix Resolution: undici - 7.28.0,undici - 6.27.0,undici - 8.5.0,https://github.com/nodejs/undici.git - v7.28.0,https://github.com/nodejs/undici.git - v6.27.0,https://github.com/nodejs/undici.git - v8.5.0
Step up your Open Source Security Game with Mend here
Vulnerable Library - core-1.30.1.tgz
OpenTelemetry Core provides constants and utilities shared by all OpenTelemetry SDK packages.
Library home page: https://registry.npmjs.org/@opentelemetry/core/-/core-1.30.1.tgz
Path to dependency file: /package.json
Path to vulnerable library: /package.json,/node_modules/.pnpm/@opentelemetry+core@1.30.1_@opentelemetry+api@1.9.1/node_modules/@opentelemetry/core/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Overview "W3CBaggagePropagator.extract()" in "@opentelemetry/core" does not enforce size limits when parsing inbound "baggage" HTTP 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-size" of 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 "TextMapGetter" implementations) or deployments that have raised "--max-http-header-size". Remediation Update "@opentelemetry/core" to version 2.8.0 or later. The fix enforces limits consistent with the W3C Baggage specification at the propagator level: - Maximum total baggage size: 8,192 bytes - Maximum number of entries: 180 - Maximum per-entry size: 4,096 bytes 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 - "W3C Baggage Specification - Limits" (https://www.w3.org/TR/baggage/#limits) - opentelemetry-java: "GHSA-rcgg-9c38-7xpx" (GHSA-rcgg-9c38-7xpx) - opentelemetry-go: "GHSA-mh2q-q3fh-2475" (GHSA-mh2q-q3fh-2475) Credit Reported by tonghuaroot.
Publish Date: 2026-06-15
URL: CVE-2026-54285
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-06-15
Fix Resolution: https://github.com/open-telemetry/opentelemetry-js.git - v2.8.0
Step up your Open Source Security Game with Mend here
Vulnerable Library - protobufjs-7.5.6.tgz
Protocol Buffers for JavaScript (& TypeScript).
Library home page: https://registry.npmjs.org/protobufjs/-/protobufjs-7.5.6.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/protobufjs@7.5.6/node_modules/protobufjs/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Summary protobufjs accepted certain schema-derived names that could collide with properties used by protobufjs runtime helpers. The known affected names are fields named "hasOwnProperty", field or oneof names such as "$type" when loaded through protobufjs JSON/reflection descriptors, and service methods whose generated helper name is "rpcCall". When affected message or service types were used, protobufjs could read schema-controlled data where it expected an own-property helper, reflected type metadata, or the base RPC helper. This could cause deterministic exceptions or recursive calls in affected decode post-checks, verification, object conversion, reflected JSON serialization, or protobufjs RPC helper invocation. Impact An attacker who can provide or influence protobuf schemas or protobufjs JSON descriptors may be able to make affected message or service types unusable, resulting in denial of service for the affected processing path. Applications using only trusted schemas are affected only if those schemas contain one of the problematic names and the application reaches the affected API path. The issue is not known to allow code execution by itself. Preconditions * The application must use an affected protobufjs version. * The application must load or use a schema or protobufjs JSON descriptor containing one of the problematic names: * a field named "hasOwnProperty", * a field or oneof named "$type" through protobufjs JSON/reflection descriptor input, * or a service method whose generated helper name is "rpcCall". * The application must reach the affected API path for that name: required-field decode post-checks, "verify", or "toObject" for "hasOwnProperty"; reflected message JSON serialization for "$type"; or protobufjs RPC service invocation for "rpcCall". Workarounds Do not load protobuf schemas or protobufjs JSON descriptors from untrusted sources with affected versions. If untrusted schemas or descriptors must be accepted, validate schema-derived field, oneof, and service method names before loading and reject the problematic names described above. Applications using trusted schemas can avoid the issue by renaming affected fields or service methods, or by avoiding the affected API path.
Publish Date: 2026-06-15
URL: CVE-2026-54269
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-f38q-mgvj-vph7
Release Date: 2026-06-15
Fix Resolution: protobufjs-cli - 2.5.1,protobufjs - 7.6.3,protobufjs - 8.6.0,protobufjs-cli - 1.3.3
Step up your Open Source Security Game with Mend here
Vulnerable Library - js-yaml-3.14.2.tgz
YAML 1.2 parser and serializer
Library home page: https://registry.npmjs.org/js-yaml/-/js-yaml-3.14.2.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/js-yaml@3.14.2/node_modules/js-yaml/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Summary A crafted YAML document can trigger algorithmic CPU exhaustion in "js-yaml" merge-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 is "tag:yaml.org,2002:merge". - For each element, it calls "mergeMappings(...)". - "mergeMappings(...)" computes "Object.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 if (keyTag === 'tag:yaml.org,2002:merge') { if (Array.isArray(valueNode)) { for (index = 0, quantity = valueNode.length; index < quantity; index += 1) { mergeMappings(state, _result, valueNode[index], overridableKeys); } } else { mergeMappings(state, _result, valueNode, overridableKeys); } } When the merge value is a sequence (YAML 1.1 <<: [ *a, *a, ... ]), each element is handed to mergeMappings() without deduplication. mergeMappings() then does sourceKeys = Object.keys(source); for (index = 0; index < sourceKeys.length; index += 1) { key = sourceKeys[index]; if (!_hasOwnProperty.call(destination, key)) { setProperty(destination, key, source[key]); overridableKeys[key] = true; } } 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: * one Object.keys(source) call (O(K)) * K _hasOwnProperty.call checks on the destination 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: if (keyTag === 'tag:yaml.org,2002:merge') { if (Array.isArray(valueNode)) { var seen = new Set(); for (index = 0, quantity = valueNode.length; index < quantity; index += 1) { var src = valueNode[index]; if (seen.has(src)) continue; // idempotent; skip redundant alias seen.add(src); mergeMappings(state, _result, src, overridableKeys); } } else { mergeMappings(state, _result, valueNode, overridableKeys); } }
Publish Date: 2026-06-15
URL: CVE-2026-53550
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Release Date: 2026-06-15
Fix Resolution: https://github.com/nodeca/js-yaml.git - 4.2.0
Step up your Open Source Security Game with Mend here
Vulnerable Library - protobufjs-7.5.6.tgz
Protocol Buffers for JavaScript (& TypeScript).
Library home page: https://registry.npmjs.org/protobufjs/-/protobufjs-7.5.6.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/protobufjs@7.5.6/node_modules/protobufjs/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
protobufjs compiles protobuf definitions into JavaScript (JS) functions. Prior to 7.5.8 and 8.2.0, protobufjs could recurse without a depth limit while expanding nested JSON descriptors through Root.fromJSON() and Namespace.addJSON(). A crafted JSON descriptor with deeply nested namespace definitions could cause the JavaScript call stack to be exhausted during descriptor loading. This vulnerability is fixed in 7.5.8 and 8.2.0.
Publish Date: 2026-05-13
URL: CVE-2026-45740
CVSS 3 Score Details (5.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: https://www.mend.io/vulnerability-database/CVE-2026-45740
Release Date: 2026-05-13
Fix Resolution (protobufjs): 7.5.8
Direct dependency fix Resolution (@storm-software/pulumi-tools): 0.22.172
Step up your Open Source Security Game with Mend here
Vulnerable Library - postcss-selector-parser-7.1.1.tgz
> Selector parser with built in methods for working with selector strings.
Library home page: https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-7.1.1.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/postcss-selector-parser@7.1.1/node_modules/postcss-selector-parser/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
A vulnerability was determined in postcss-selector-parser up to 6.1.2/7.1.2. Affected is the function toString of the file src/selectors/container.js of the component AST Serialization. Executing a manipulation can lead to uncontrolled recursion. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. Upgrading to version 6.1.3 and 7.1.3 is able to address this issue. This patch is called 5bc698cef66f8abd12610dc623e5d67cbc0f869d. It is suggested to upgrade the affected component. The vendor explains, that according to his definition "DoS on server-side on user-generated CSS is low risk for us (since most users compile own CSS with PostCSS)." The commits were backported to 6.x branch, which was the most downloaded version.
Publish Date: 2026-05-24
URL: CVE-2026-9358
CVSS 3 Score Details (4.3)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: Required
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: None
- Availability Impact: Low
For more information on CVSS3 Scores, click here.Step up your Open Source Security Game with Mend here
Vulnerable Library - undici-6.25.0.tgz
An HTTP/1.1 client, written from scratch for Node.js
Library home page: https://registry.npmjs.org/undici/-/undici-6.25.0.tgz
Path to dependency file: /package.json
Path to vulnerable library: /node_modules/.pnpm/undici@6.25.0/node_modules/undici/package.json
Dependency Hierarchy:
Found in HEAD commit: c335fe6f51a58aa08a2ad009ab7a9f825dba6fe7
Found in base branch: main
Vulnerability Details
Impact:
Undici's HTTP/1.1 client is vulnerable to response queue poisoning on reused keep-alive sockets. An attacker-controlled upstream server can inject an unsolicited HTTP/1.1 response onto an idle socket after a request completes. When the client dispatches the next request on that socket, it associates the injected response with the new request, causing responses to be delivered to the wrong requests.
This requires an attacker-controlled or compromised upstream HTTP/1.1 server and keep-alive connection reuse.
Patches:
Upgrade to undici v6.26.0, v7.28.0 or v8.5.0.
Workarounds:
Disable keep-alive connection reuse by setting keepAliveTimeout: 0 on the Client or Pool.
Publish Date: 2026-06-17
URL: CVE-2026-6733
CVSS 3 Score Details (3.7)
Base Score Metrics:
- Exploitability Metrics:
- Attack Vector: Network
- Attack Complexity: High
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Impact Metrics:
- Confidentiality Impact: None
- Integrity Impact: Low
- Availability Impact: None
For more information on CVSS3 Scores, click here.Suggested Fix
Type: Upgrade version
Origin: GHSA-35p6-xmwp-9g52
Release Date: 2026-06-17
Fix Resolution: undici - 7.28.0,undici - 8.5.0,undici - 6.27.0
Step up your Open Source Security Game with Mend here