CVE-2025-15284 (GCVE-0-2025-15284)
Vulnerability from cvelistv5
Published
2025-12-29 22:56
Modified
2026-02-10 20:06
Severity ?
6.3 (Medium) - CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L
3.7 (Low) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
CWE
  • CWE-20 - Improper Input Validation
Summary
Improper Input Validation vulnerability in qs (parse modules) allows HTTP DoS.This issue affects qs: < 6.14.1. 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[]=valueconsumes 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.
References
Impacted products
Vendor Product Version
Version: < 6.14.1   ≤
Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-15284",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-12-30T14:55:26.031863Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-12-30T15:57:41.402Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://npmjs.com/qs",
          "defaultStatus": "affected",
          "modules": [
            "parse"
          ],
          "packageName": "qs",
          "repo": "https://github.com/ljharb/qs",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 6.14.1",
              "versionType": "semver"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Improper Input Validation vulnerability in qs (parse modules) allows HTTP DoS.\u003cp\u003eThis issue affects qs: \u0026lt; 6.14.1.\u003c/p\u003e\u003ch3\u003e\u003cbr\u003eSummary\u003c/h3\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eThe \u003ccode\u003earrayLimit\u003c/code\u003e\u0026nbsp;option in qs did not enforce limits for bracket notation (\u003ccode\u003ea[]=1\u0026amp;a[]=2\u003c/code\u003e), only for indexed notation (\u003ccode\u003ea[0]=1\u003c/code\u003e). This is a consistency bug; \u003ccode\u003earrayLimit\u003c/code\u003e\u0026nbsp;should apply uniformly across all array notations.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote:\u003c/strong\u003e\u0026nbsp;The default \u003ccode\u003eparameterLimit\u003c/code\u003e\u0026nbsp;of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than \u003ccode\u003eparameterLimit\u003c/code\u003e\u0026nbsp;regardless of \u003ccode\u003earrayLimit\u003c/code\u003e, because each \u003ccode\u003ea[]=value\u003c/code\u003econsumes one parameter slot. The severity has been reduced accordingly.\u003c/p\u003e\u003ch3\u003eDetails\u003c/h3\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eThe \u003ccode\u003earrayLimit\u003c/code\u003e\u0026nbsp;option only checked limits for indexed notation (\u003ccode\u003ea[0]=1\u0026amp;a[1]=2\u003c/code\u003e) but did not enforce it for bracket notation (\u003ccode\u003ea[]=1\u0026amp;a[]=2\u003c/code\u003e).\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eVulnerable code\u003c/strong\u003e\u0026nbsp;(\u003ccode\u003elib/parse.js:159-162\u003c/code\u003e):\u003c/p\u003e\u003cdiv\u003e\u003cpre\u003eif (root === \u0027[]\u0027 \u0026amp;\u0026amp; options.parseArrays) {\n    obj = utils.combine([], leaf);  // No arrayLimit check\n}\u003c/pre\u003e\u003cdiv\u003e\u003c/div\u003e\u003c/div\u003e\u003cp\u003e\u003cstrong\u003eWorking code\u003c/strong\u003e\u0026nbsp;(\u003ccode\u003elib/parse.js:175\u003c/code\u003e):\u003c/p\u003e\u003cdiv\u003e\u003cpre\u003eelse if (index \u0026lt;= options.arrayLimit) {  // Limit checked here\n    obj = [];\n    obj[index] = leaf;\n}\u003c/pre\u003e\u003cdiv\u003e\u003c/div\u003e\u003c/div\u003e\u003cp\u003eThe bracket notation handler at line 159 uses \u003ccode\u003eutils.combine([], leaf)\u003c/code\u003e\u0026nbsp;without validating against \u003ccode\u003eoptions.arrayLimit\u003c/code\u003e, while indexed notation at line 175 checks \u003ccode\u003eindex \u0026lt;= options.arrayLimit\u003c/code\u003e\u0026nbsp;before creating arrays.\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003ch3\u003ePoC\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003e\u003c/strong\u003e\u003c/p\u003e\u003cdiv\u003e\u003cpre\u003econst qs = require(\u0027qs\u0027);\nconst result = qs.parse(\u0027a[]=1\u0026amp;a[]=2\u0026amp;a[]=3\u0026amp;a[]=4\u0026amp;a[]=5\u0026amp;a[]=6\u0027, { arrayLimit: 5 });\nconsole.log(result.a.length);  // Output: 6 (should be max 5)\u003c/pre\u003e\u003cdiv\u003e\u003c/div\u003e\u003c/div\u003e\u003cp\u003e\u003cstrong\u003eNote on parameterLimit interaction:\u003c/strong\u003e\u0026nbsp;The original advisory\u0027s \"DoS demonstration\" claimed a length of 10,000, but \u003ccode\u003eparameterLimit\u003c/code\u003e\u0026nbsp;(default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000.\u003c/p\u003e\u003ch3\u003eImpact\u003c/h3\u003e\u003cp\u003e\u003c/p\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003eConsistency bug in \u003c/span\u003e\u003ccode\u003earrayLimit\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;enforcement. With default \u003c/span\u003e\u003ccode\u003eparameterLimit\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e, the practical DoS risk is negligible since \u003c/span\u003e\u003ccode\u003eparameterLimit\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when \u003c/span\u003e\u003ccode\u003eparameterLimit\u003c/code\u003e\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003e\u0026nbsp;is explicitly set to a very high value.\u003c/span\u003e"
            }
          ],
          "value": "Improper Input Validation vulnerability in qs (parse modules) allows HTTP DoS.This issue affects qs: \u003c 6.14.1.\n\n\nSummary\n\nThe arrayLimit\u00a0option in qs did not enforce limits for bracket notation (a[]=1\u0026a[]=2), only for indexed notation (a[0]=1). This is a consistency bug; arrayLimit\u00a0should apply uniformly across all array notations.\n\nNote:\u00a0The default parameterLimit\u00a0of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than parameterLimit\u00a0regardless of arrayLimit, because each a[]=valueconsumes one parameter slot. The severity has been reduced accordingly.\n\nDetails\n\nThe arrayLimit\u00a0option only checked limits for indexed notation (a[0]=1\u0026a[1]=2) but did not enforce it for bracket notation (a[]=1\u0026a[]=2).\n\nVulnerable code\u00a0(lib/parse.js:159-162):\n\nif (root === \u0027[]\u0027 \u0026\u0026 options.parseArrays) {\n    obj = utils.combine([], leaf);  // No arrayLimit check\n}\n\n\n\n\n\nWorking code\u00a0(lib/parse.js:175):\n\nelse if (index \u003c= options.arrayLimit) {  // Limit checked here\n    obj = [];\n    obj[index] = leaf;\n}\n\n\n\n\n\nThe bracket notation handler at line 159 uses utils.combine([], leaf)\u00a0without validating against options.arrayLimit, while indexed notation at line 175 checks index \u003c= options.arrayLimit\u00a0before creating arrays.\n\n\n\nPoC\n\nconst qs = require(\u0027qs\u0027);\nconst result = qs.parse(\u0027a[]=1\u0026a[]=2\u0026a[]=3\u0026a[]=4\u0026a[]=5\u0026a[]=6\u0027, { arrayLimit: 5 });\nconsole.log(result.a.length);  // Output: 6 (should be max 5)\n\n\n\n\n\nNote on parameterLimit interaction:\u00a0The original advisory\u0027s \"DoS demonstration\" claimed a length of 10,000, but parameterLimit\u00a0(default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000.\n\nImpact\n\nConsistency bug in arrayLimit\u00a0enforcement. With default parameterLimit, the practical DoS risk is negligible since parameterLimit\u00a0already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when parameterLimit\u00a0is explicitly set to a very high value."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-469",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-469 HTTP DoS"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "LOW",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L",
            "version": "4.0",
            "vulnAvailabilityImpact": "LOW",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        },
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 3.7,
            "baseSeverity": "LOW",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-20",
              "description": "CWE-20 Improper Input Validation",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-02-10T20:06:42.111Z",
        "orgId": "7ffcee3d-2c14-4c3e-b844-86c6a321a158",
        "shortName": "harborist"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/ljharb/qs/security/advisories/GHSA-6rw7-vpxm-498p"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/ljharb/qs/commit/3086902ecf7f088d0d1803887643ac6c03d415b9"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "arrayLimit bypass in bracket notation allows DoS via memory exhaustion",
      "x_generator": {
        "engine": "Vulnogram 0.5.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "7ffcee3d-2c14-4c3e-b844-86c6a321a158",
    "assignerShortName": "harborist",
    "cveId": "CVE-2025-15284",
    "datePublished": "2025-12-29T22:56:45.240Z",
    "dateReserved": "2025-12-29T21:36:51.399Z",
    "dateUpdated": "2026-02-10T20:06:42.111Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2025-15284\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2025-12-30T14:55:26.031863Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2025-12-30T15:55:05.860Z\"}}], \"cna\": {\"title\": \"arrayLimit bypass in bracket notation allows DoS via memory exhaustion\", \"source\": {\"discovery\": \"UNKNOWN\"}, \"impacts\": [{\"capecId\": \"CAPEC-469\", \"descriptions\": [{\"lang\": \"en\", \"value\": \"CAPEC-469 HTTP DoS\"}]}], \"metrics\": [{\"format\": \"CVSS\", \"cvssV4_0\": {\"Safety\": \"NOT_DEFINED\", \"version\": \"4.0\", \"Recovery\": \"NOT_DEFINED\", \"baseScore\": 6.3, \"Automatable\": \"NOT_DEFINED\", \"attackVector\": \"NETWORK\", \"baseSeverity\": \"MEDIUM\", \"valueDensity\": \"NOT_DEFINED\", \"vectorString\": \"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L\", \"exploitMaturity\": \"NOT_DEFINED\", \"providerUrgency\": \"NOT_DEFINED\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"attackRequirements\": \"PRESENT\", \"privilegesRequired\": \"NONE\", \"subIntegrityImpact\": \"NONE\", \"vulnIntegrityImpact\": \"NONE\", \"subAvailabilityImpact\": \"LOW\", \"vulnAvailabilityImpact\": \"LOW\", \"subConfidentialityImpact\": \"NONE\", \"vulnConfidentialityImpact\": \"NONE\", \"vulnerabilityResponseEffort\": \"NOT_DEFINED\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}, {\"format\": \"CVSS\", \"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 3.7, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"LOW\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"HIGH\", \"availabilityImpact\": \"LOW\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"NONE\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"repo\": \"https://github.com/ljharb/qs\", \"modules\": [\"parse\"], \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 6.14.1\", \"versionType\": \"semver\"}], \"packageName\": \"qs\", \"collectionURL\": \"https://npmjs.com/qs\", \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://github.com/ljharb/qs/security/advisories/GHSA-6rw7-vpxm-498p\", \"tags\": [\"vendor-advisory\"]}, {\"url\": \"https://github.com/ljharb/qs/commit/3086902ecf7f088d0d1803887643ac6c03d415b9\", \"tags\": [\"patch\"]}], \"x_generator\": {\"engine\": \"Vulnogram 0.5.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"Improper Input Validation vulnerability in qs (parse modules) allows HTTP DoS.This issue affects qs: \u003c 6.14.1.\\n\\n\\nSummary\\n\\nThe arrayLimit\\u00a0option in qs did not enforce limits for bracket notation (a[]=1\u0026a[]=2), only for indexed notation (a[0]=1). This is a consistency bug; arrayLimit\\u00a0should apply uniformly across all array notations.\\n\\nNote:\\u00a0The default parameterLimit\\u00a0of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than parameterLimit\\u00a0regardless of arrayLimit, because each a[]=valueconsumes one parameter slot. The severity has been reduced accordingly.\\n\\nDetails\\n\\nThe arrayLimit\\u00a0option only checked limits for indexed notation (a[0]=1\u0026a[1]=2) but did not enforce it for bracket notation (a[]=1\u0026a[]=2).\\n\\nVulnerable code\\u00a0(lib/parse.js:159-162):\\n\\nif (root === \u0027[]\u0027 \u0026\u0026 options.parseArrays) {\\n    obj = utils.combine([], leaf);  // No arrayLimit check\\n}\\n\\n\\n\\n\\n\\nWorking code\\u00a0(lib/parse.js:175):\\n\\nelse if (index \u003c= options.arrayLimit) {  // Limit checked here\\n    obj = [];\\n    obj[index] = leaf;\\n}\\n\\n\\n\\n\\n\\nThe bracket notation handler at line 159 uses utils.combine([], leaf)\\u00a0without validating against options.arrayLimit, while indexed notation at line 175 checks index \u003c= options.arrayLimit\\u00a0before creating arrays.\\n\\n\\n\\nPoC\\n\\nconst qs = require(\u0027qs\u0027);\\nconst result = qs.parse(\u0027a[]=1\u0026a[]=2\u0026a[]=3\u0026a[]=4\u0026a[]=5\u0026a[]=6\u0027, { arrayLimit: 5 });\\nconsole.log(result.a.length);  // Output: 6 (should be max 5)\\n\\n\\n\\n\\n\\nNote on parameterLimit interaction:\\u00a0The original advisory\u0027s \\\"DoS demonstration\\\" claimed a length of 10,000, but parameterLimit\\u00a0(default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000.\\n\\nImpact\\n\\nConsistency bug in arrayLimit\\u00a0enforcement. With default parameterLimit, the practical DoS risk is negligible since parameterLimit\\u00a0already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when parameterLimit\\u00a0is explicitly set to a very high value.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"Improper Input Validation vulnerability in qs (parse modules) allows HTTP DoS.\u003cp\u003eThis issue affects qs: \u0026lt; 6.14.1.\u003c/p\u003e\u003ch3\u003e\u003cbr\u003eSummary\u003c/h3\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eThe \u003ccode\u003earrayLimit\u003c/code\u003e\u0026nbsp;option in qs did not enforce limits for bracket notation (\u003ccode\u003ea[]=1\u0026amp;a[]=2\u003c/code\u003e), only for indexed notation (\u003ccode\u003ea[0]=1\u003c/code\u003e). This is a consistency bug; \u003ccode\u003earrayLimit\u003c/code\u003e\u0026nbsp;should apply uniformly across all array notations.\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote:\u003c/strong\u003e\u0026nbsp;The default \u003ccode\u003eparameterLimit\u003c/code\u003e\u0026nbsp;of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than \u003ccode\u003eparameterLimit\u003c/code\u003e\u0026nbsp;regardless of \u003ccode\u003earrayLimit\u003c/code\u003e, because each \u003ccode\u003ea[]=value\u003c/code\u003econsumes one parameter slot. The severity has been reduced accordingly.\u003c/p\u003e\u003ch3\u003eDetails\u003c/h3\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003eThe \u003ccode\u003earrayLimit\u003c/code\u003e\u0026nbsp;option only checked limits for indexed notation (\u003ccode\u003ea[0]=1\u0026amp;a[1]=2\u003c/code\u003e) but did not enforce it for bracket notation (\u003ccode\u003ea[]=1\u0026amp;a[]=2\u003c/code\u003e).\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eVulnerable code\u003c/strong\u003e\u0026nbsp;(\u003ccode\u003elib/parse.js:159-162\u003c/code\u003e):\u003c/p\u003e\u003cdiv\u003e\u003cpre\u003eif (root === \u0027[]\u0027 \u0026amp;\u0026amp; options.parseArrays) {\\n    obj = utils.combine([], leaf);  // No arrayLimit check\\n}\u003c/pre\u003e\u003cdiv\u003e\u003c/div\u003e\u003c/div\u003e\u003cp\u003e\u003cstrong\u003eWorking code\u003c/strong\u003e\u0026nbsp;(\u003ccode\u003elib/parse.js:175\u003c/code\u003e):\u003c/p\u003e\u003cdiv\u003e\u003cpre\u003eelse if (index \u0026lt;= options.arrayLimit) {  // Limit checked here\\n    obj = [];\\n    obj[index] = leaf;\\n}\u003c/pre\u003e\u003cdiv\u003e\u003c/div\u003e\u003c/div\u003e\u003cp\u003eThe bracket notation handler at line 159 uses \u003ccode\u003eutils.combine([], leaf)\u003c/code\u003e\u0026nbsp;without validating against \u003ccode\u003eoptions.arrayLimit\u003c/code\u003e, while indexed notation at line 175 checks \u003ccode\u003eindex \u0026lt;= options.arrayLimit\u003c/code\u003e\u0026nbsp;before creating arrays.\u003c/p\u003e\u003cp\u003e\u003c/p\u003e\u003ch3\u003ePoC\u003c/h3\u003e\u003cp\u003e\u003cstrong\u003e\u003c/strong\u003e\u003c/p\u003e\u003cdiv\u003e\u003cpre\u003econst qs = require(\u0027qs\u0027);\\nconst result = qs.parse(\u0027a[]=1\u0026amp;a[]=2\u0026amp;a[]=3\u0026amp;a[]=4\u0026amp;a[]=5\u0026amp;a[]=6\u0027, { arrayLimit: 5 });\\nconsole.log(result.a.length);  // Output: 6 (should be max 5)\u003c/pre\u003e\u003cdiv\u003e\u003c/div\u003e\u003c/div\u003e\u003cp\u003e\u003cstrong\u003eNote on parameterLimit interaction:\u003c/strong\u003e\u0026nbsp;The original advisory\u0027s \\\"DoS demonstration\\\" claimed a length of 10,000, but \u003ccode\u003eparameterLimit\u003c/code\u003e\u0026nbsp;(default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000.\u003c/p\u003e\u003ch3\u003eImpact\u003c/h3\u003e\u003cp\u003e\u003c/p\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003eConsistency bug in \u003c/span\u003e\u003ccode\u003earrayLimit\u003c/code\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003e\u0026nbsp;enforcement. With default \u003c/span\u003e\u003ccode\u003eparameterLimit\u003c/code\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003e, the practical DoS risk is negligible since \u003c/span\u003e\u003ccode\u003eparameterLimit\u003c/code\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003e\u0026nbsp;already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when \u003c/span\u003e\u003ccode\u003eparameterLimit\u003c/code\u003e\u003cspan style=\\\"background-color: rgb(255, 255, 255);\\\"\u003e\u0026nbsp;is explicitly set to a very high value.\u003c/span\u003e\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-20\", \"description\": \"CWE-20 Improper Input Validation\"}]}], \"providerMetadata\": {\"orgId\": \"7ffcee3d-2c14-4c3e-b844-86c6a321a158\", \"shortName\": \"harborist\", \"dateUpdated\": \"2026-02-10T20:06:42.111Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2025-15284\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-02-10T20:06:42.111Z\", \"dateReserved\": \"2025-12-29T21:36:51.399Z\", \"assignerOrgId\": \"7ffcee3d-2c14-4c3e-b844-86c6a321a158\", \"datePublished\": \"2025-12-29T22:56:45.240Z\", \"assignerShortName\": \"harborist\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.