<?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://db.gcve.eu</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>Sat, 03 Oct 2026 06:48:06 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-71314</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-71314</link>
      <description>&lt;p&gt;Nuxt is an open-source web development framework for Vue.js. From 3.1.0 until 3.21.10 and 4.5.1, an unauthenticated attacker can use a server island v-for prop, including vforToArray and , to trigger unbounded SSR memory allocation until MAX_VFOR_LENGTH = 100000 and crash the Nuxt process. This issue is fixed in 3.21.10 and 4.5.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Nuxt is an open-source web development framework for Vue.js. From 3.1.0 until 3.21.10 and 4.5.1, an unauthenticated attacker can use a server island v-for prop, including vforToArray and , to trigger unbounded SSR memory allocation until MAX_VFOR_LENGTH = 100000 and crash the Nuxt process. This issue is fixed in 3.21.10 and 4.5.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-71314</guid>
    </item>
    <item>
      <title>GHSA-hxcr-hm88-mpq6 — Nuxt: Unauthenticated out-of-memory crash via unbounded v-for expansion in island rendering</title>
      <link>https://db.gcve.eu/vuln/ghsa-hxcr-hm88-mpq6</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: nuxt&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;An unauthenticated attacker can crash a Nuxt server that renders any island / server component containing a `v-for` over a prop (for example `v-for=&amp;#34;n in count&amp;#34;` or a `&amp;lt;slot v-for&amp;gt;`). Because the island URL hash is a non-secret digest of the request, the attacker can compute a valid hash for arbitrary props and send the iterated prop as a large integer. The server then expands the `v-for` to that many nodes during SSR, allocating memory proportional to the attacker&amp;#39;s number. Reporter figures: `count=8000000` produced a 142.9 MB response; `count=40000000` (and `items=4000000` on a slot list) produced an out-of-memory crash of the worker from a single ~130-byte request. Both the plain `v-for` path (Vue&amp;#39;s `ssrRenderList`) and the slot path (`vforToArray`) are affected.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Fixed in `nuxt@4.5.1` and `nuxt@3.21.10`. Island/server-component `v-for` sources are now clamped to a maximum iteration count (`MAX_VFOR_LENGTH = 100000`) at the render boundary, covering the plain path, the `&amp;lt;slot v-for&amp;gt;` element, and the `vforToArray` slot-props helper. Combined with the body-size cap (GHSA-9pgf-384g-p7mv), a single island render can no longer allocate without bound regardless of which `v-for` path is used or whether the prop arrives as an integer or an array.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Avoid `v-for` directly over an unclamped prop in server components, or clamp the count in the component (`v-for=&amp;#34;n in Math.min(count, 1000)&amp;#34;`). A body-size limit in front of `/__nuxt_island/` o…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: nuxt&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;An unauthenticated attacker can crash a Nuxt server that renders any island / server component containing a `v-for` over a prop (for example `v-for=&amp;#34;n in count&amp;#34;` or a `&amp;lt;slot v-for&amp;gt;`). Because the island URL hash is a non-secret digest of the request, the attacker can compute a valid hash for arbitrary props and send the iterated prop as a large integer. The server then expands the `v-for` to that many nodes during SSR, allocating memory proportional to the attacker&amp;#39;s number. Reporter figures: `count=8000000` produced a 142.9 MB response; `count=40000000` (and `items=4000000` on a slot list) produced an out-of-memory crash of the worker from a single ~130-byte request. Both the plain `v-for` path (Vue&amp;#39;s `ssrRenderList`) and the slot path (`vforToArray`) are affected.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Fixed in `nuxt@4.5.1` and `nuxt@3.21.10`. Island/server-component `v-for` sources are now clamped to a maximum iteration count (`MAX_VFOR_LENGTH = 100000`) at the render boundary, covering the plain path, the `&amp;lt;slot v-for&amp;gt;` element, and the `vforToArray` slot-props helper. Combined with the body-size cap (GHSA-9pgf-384g-p7mv), a single island render can no longer allocate without bound regardless of which `v-for` path is used or whether the prop arrives as an integer or an array.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Avoid `v-for` directly over an unclamped prop in server components, or clamp the count in the component (`v-for=&amp;#34;n in Math.min(count, 1000)&amp;#34;`). A body-size limit in front of `/__nuxt_island/` o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-hxcr-hm88-mpq6</guid>
    </item>
  </channel>
</rss>
