<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 09:47:40 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-335308</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-335308</link>
      <description>EUVD-2026-335308</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-335308</guid>
    </item>
    <item>
      <title>fkie_cve-2026-55575</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-55575</link>
      <description>&lt;p&gt;LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.27.1, the pop array filter at src/filters/array.ts allocated a full clone of its input array via [...toArray(v)] without calling this.context.memoryLimit.use(...), allowing a template render such as {{ huge_array | pop }} to allocate an O(N) clone of an attacker-influenced array outside the configured memoryLimit budget. This issue is fixed in version 10.27.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.27.1, the pop array filter at src/filters/array.ts allocated a full clone of its input array via [...toArray(v)] without calling this.context.memoryLimit.use(...), allowing a template render such as {{ huge_array | pop }} to allocate an O(N) clone of an attacker-influenced array outside the configured memoryLimit budget. This issue is fixed in version 10.27.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-55575</guid>
    </item>
    <item>
      <title>GHSA-g357-x5c3-c72p — LiquidJS: `pop` filter bypasses `memoryLimit` accounting that its array-filter siblings enforce</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-g357-x5c3-c72p</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: liquidjs&lt;/p&gt;
&lt;p&gt;# `pop` filter bypasses `memoryLimit` accounting that its array-filter siblings enforce&lt;/p&gt;
&lt;p&gt;**CWE**: CWE-770 (Allocation of Resources Without Limits or Throttling) — sibling class of GHSA-8xx9-69p8-7jp3 and GHSA-2546-xv4c-mc8g, applied to `memoryLimit` instead of `renderLimit`&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The `pop` array filter at `src/filters/array.ts:91-95` allocates a full clone of its input array via `[...toArray(v)]` but does **not** call `this.context.memoryLimit.use(...)` the way every other array-clone filter in the same file does (`shift`, `unshift`, `compact`, `concat`, `reverse`, `sample`, `slice`, `map`, `sortBy`, `where`, `group_by`, `uniq`). This silently disables the `memoryLimit` budget for `{{ huge_array | pop }}`, letting a template render allocate an O(N) clone of an attacker-influenced array regardless of how strictly `memoryLimit` is set.&lt;/p&gt;
&lt;p&gt;## Affected&lt;/p&gt;
&lt;p&gt;- liquidjs ≥ all versions that ship the current `pop` filter implementation (verified `10.27.0`, HEAD `a8fd734b5`)
- Deployments where any template uses `{{ arr | pop }}` on an array whose length is influenced by untrusted input (typical multi-tenant context arrays: orders, log lines, catalog entries, user lists, etc.)&lt;/p&gt;
&lt;p&gt;## Vulnerability details&lt;/p&gt;
&lt;p&gt;### Code&lt;/p&gt;
&lt;p&gt;`src/filters/array.ts:91-95`:&lt;/p&gt;
&lt;p&gt;```ts
export function pop&amp;lt;T&amp;gt; (v: T[]): T[] {
  const clone = [...toArray(v)]   // O(N) allocation — not charged to memoryLimit
  clone.pop()
  return clone
}
```&lt;/p&gt;
&lt;p&gt;Note: the function signature does not even declare `this: FilterImpl`, so it has…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: liquidjs&lt;/p&gt;
&lt;p&gt;# `pop` filter bypasses `memoryLimit` accounting that its array-filter siblings enforce&lt;/p&gt;
&lt;p&gt;**CWE**: CWE-770 (Allocation of Resources Without Limits or Throttling) — sibling class of GHSA-8xx9-69p8-7jp3 and GHSA-2546-xv4c-mc8g, applied to `memoryLimit` instead of `renderLimit`&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The `pop` array filter at `src/filters/array.ts:91-95` allocates a full clone of its input array via `[...toArray(v)]` but does **not** call `this.context.memoryLimit.use(...)` the way every other array-clone filter in the same file does (`shift`, `unshift`, `compact`, `concat`, `reverse`, `sample`, `slice`, `map`, `sortBy`, `where`, `group_by`, `uniq`). This silently disables the `memoryLimit` budget for `{{ huge_array | pop }}`, letting a template render allocate an O(N) clone of an attacker-influenced array regardless of how strictly `memoryLimit` is set.&lt;/p&gt;
&lt;p&gt;## Affected&lt;/p&gt;
&lt;p&gt;- liquidjs ≥ all versions that ship the current `pop` filter implementation (verified `10.27.0`, HEAD `a8fd734b5`)
- Deployments where any template uses `{{ arr | pop }}` on an array whose length is influenced by untrusted input (typical multi-tenant context arrays: orders, log lines, catalog entries, user lists, etc.)&lt;/p&gt;
&lt;p&gt;## Vulnerability details&lt;/p&gt;
&lt;p&gt;### Code&lt;/p&gt;
&lt;p&gt;`src/filters/array.ts:91-95`:&lt;/p&gt;
&lt;p&gt;```ts
export function pop&amp;lt;T&amp;gt; (v: T[]): T[] {
  const clone = [...toArray(v)]   // O(N) allocation — not charged to memoryLimit
  clone.pop()
  return clone
}
```&lt;/p&gt;
&lt;p&gt;Note: the function signature does not even declare `this: FilterImpl`, so it has…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-g357-x5c3-c72p</guid>
    </item>
  </channel>
</rss>
