<?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://vulnerability.circl.lu</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>Mon, 28 Sep 2026 15:47:11 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-82333</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-82333</link>
      <description>&lt;p&gt;multer is a middleware for handling multipart/form-data in Node.js. A small multipart request with two specially crafted text field names can make multer&amp;#39;s field parser synchronously iterate a maximum-length sparse array, blocking the event loop so the process cannot handle other requests. A large numeric array index in the first field allocates a maximum-length sparse array, and a second field with a non-numeric key then triggers a full-length iteration inside the append-field dependency. All versions before 2.3.0 are affected, and this is a remotely triggerable denial of service. multer 2.3.0 adds an opt-in fieldArrayIndexLimit option that rejects oversized array indexes. Upgrade to multer 2.3.0 and set limits.fieldArrayIndexLimit to the largest array index your application needs to remediate.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;multer is a middleware for handling multipart/form-data in Node.js. A small multipart request with two specially crafted text field names can make multer&amp;#39;s field parser synchronously iterate a maximum-length sparse array, blocking the event loop so the process cannot handle other requests. A large numeric array index in the first field allocates a maximum-length sparse array, and a second field with a non-numeric key then triggers a full-length iteration inside the append-field dependency. All versions before 2.3.0 are affected, and this is a remotely triggerable denial of service. multer 2.3.0 adds an opt-in fieldArrayIndexLimit option that rejects oversized array indexes. Upgrade to multer 2.3.0 and set limits.fieldArrayIndexLimit to the largest array index your application needs to remediate.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-82333</guid>
    </item>
    <item>
      <title>GHSA-535w-7cp7-47q4 — multer vulnerable to Denial of Service via oversized array index in field names</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-535w-7cp7-47q4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: multer&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;multer is vulnerable to a Denial of Service (DoS) via a crafted array index in multipart field names. The `append-field` dependency parses bracket notation in field names, and a large numeric index such as `items[4294967294]` forces allocation of a maximum-length sparse array. A following field with a non-numeric key on the same base then converts that array to an object by iterating its full length, which consumes CPU synchronously and leaves the process unable to handle other requests. A single HTTP request with a crafted multipart body is sufficient to exploit this, and it affects multer 1.x and 2.x.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Users should upgrade to `2.3.0` and configure `limits.fieldArrayIndexLimit` to the minimum array index their application requires.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;None.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: multer&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;multer is vulnerable to a Denial of Service (DoS) via a crafted array index in multipart field names. The `append-field` dependency parses bracket notation in field names, and a large numeric index such as `items[4294967294]` forces allocation of a maximum-length sparse array. A following field with a non-numeric key on the same base then converts that array to an object by iterating its full length, which consumes CPU synchronously and leaves the process unable to handle other requests. A single HTTP request with a crafted multipart body is sufficient to exploit this, and it affects multer 1.x and 2.x.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;Users should upgrade to `2.3.0` and configure `limits.fieldArrayIndexLimit` to the minimum array index their application requires.&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;None.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-535w-7cp7-47q4</guid>
    </item>
  </channel>
</rss>
