CVE-2026-110910

LOWPre-NVD 3.73.7
EchelonGraph scoreMEDIUM confidence

“—” beside the score: it is equal to the CVSS score beside it.

This low-severity CVE scores 3.7 under a secondary CVSS source (NVD's own analysis pending). EPSS exploit probability: 0.3% (21st percentile of EPSS-scored CVEs). No GitHub Security Advisory CVSS is on record for this CVE.

Triggered by: Headline CVSS from a secondary CVSS source
Sources: EPSS, a secondary CVSS source

Also known asEUVD-2026-110630 (ENISA EUVD)Source: ENISA EUVD

3.7EG
EchelonGraph verdictMonitorRemediate within your standard update timelines (the SSVC decision on this page).
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS PROB: 0.3%CVSS: 3.7Exploit: None knownExposed services: Not assessed

Upgrade to qs 6.17.0 or later (from the CVE record's solution, Harborist) — apply it.

Summary

qs.stringify with allowEmptyArrays: true writes the key of an empty array without encoding it, even though keys are encoded by default. A key that contains & (or the configured delimiter), =, or # therefore becomes query string syntax instead of data, so a caller-supplied key name can add parameters to the serialized query string, or cut it short.

Details

In lib/stringify.js, the allowEmptyArrays branch returns adjustedPrefix + '[]' early, before the code that passes every other key through encoder and formatter. So { "x&k=v": ["1"] } serializes as x%26k%3Dv%5B0%5D=1, but { "x&k=v": [] } serializes as x&k=v[]. The early return applies at any depth ({ "a": { "b&k=v": [] } } gives a[b&k=v][]), under every arrayFormat, with allowDots, and with a custom encoder, which is never called for that key. With encode: false or encodeValuesOnly: true, keys are intentionally left unencoded on every path; those configurations are not affected.

PoC

var qs = require("qs");

var query = qs.stringify({ q: "hi", "x&apiKey=evil&y": [] }, { allowEmptyArrays: true });

// "q=hi&x&apiKey=evil&y[]"

qs.parse(query);

// { q: "hi", x: "", apiKey: "evil", y: [""] }

qs.stringify({ "x#": [], z: "1" }, { allowEmptyArrays: true });

// "x#[]&z=1": in a URL, everything after "#" becomes the fragment

Fix

Applied in 234d505 on main and released as v6.17.0, and backported to v6.16.2, v6.15.4, v6.14.3, v6.13.4, and v6.12.6: the key of an empty array goes through encoder and formatter exactly as the key of any other value does, so { "x&apiKey=evil&y": [] } now serializes as x%26apiKey%3Devil%26y[]. Keys that need no encoding serialize as before, with two exceptions that match every other path: the brackets of a nested key are now encoded (a[b][] becomes a%5Bb%5D[], which qs.parse reads identically), and with encodeDotInKeys, a dot in the key becomes %252E instead of %2E (which decodeDotInKeys previously misread as nesting).

Affected versions

  • >=6.12.0 <6.12.6, fixed in v6.12.6
  • >=6.13.0 <6.13.4, fixed in v6.13.4
  • >=6.14.0 <6.14.3, fixed in v6.14.3
  • >=6.15.0 <6.15.4, fixed in v6.15.4
  • >=6.16.0 <6.16.2, fixed in v6.16.2

v6.17.0 and later are not affected.

allowEmptyArrays was introduced in f22b2bc and first shipped in v6.12.0, with this early return. Earlier versions have no allowEmptyArrays option and are not affected.

Impact

An application that passes an object whose key names come from untrusted input to qs.stringify with allowEmptyArrays: true (for example, to forward a parsed JSON body or user-selected fields to an upstream service) can have parameters injected into the resulting query string. The injected parameters are not keys of the object, so deleting or overwriting a key on the object (such as setting a trusted apiKey after copying the user's fields) does not remove them; whether the attacker's value or the application's wins depends on how the receiving side handles a duplicate parameter. A # in such a key ends the query string early when the result is placed in a URL. allowEmptyArrays is off by default, and only keys whose value (after any filter) is an empty array are affected.

CVSS v3
3.7
EG Score
3.7LOWmedium confidence
EG Risk
17
EG Risk 17/100

EG Risk is EchelonGraph's 0–100 priority score. It fuses impact severity (EG Severity, the CVSS base score, never the KEV-floored or EPSS-lifted EG Score) with real-world exploitation and automatability, under weights EchelonGraph set by hand, so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner.

How it’s computed (value × EchelonGraph’s weight)
Severity37% × 45%
Impact severity (EG Severity): CVSS 3.7 of 10. Never the KEV-floored or EPSS-lifted EG Score.
Exploitation0.2% × 40%
FIRST EPSS: the 30-day exploitation probability when EchelonGraph scored this CVE.
Automatability0% × 15%
CISA's BOD 26-04 default: no one has published Automatable for this CVE, and CISA treats it as “no” for a CVE not in KEV.
SSVC (CISA's decision table, applied by EchelonGraph): Track at every mission impact level.
Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact partial (CVSS v4.0 confidentiality and integrity impact neither High). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE.
Action: Upgrade to qs 6.17.0 or later (from the CVE record's solution, Harborist). Apply it within your standard update timelines.
EPSS PROB
0.3%
EPSS %ILE
21st
KEV
Not listed

What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)

The EG score (3.7): severity, escalated by confirmed exploitation. This CVE's 3.7 is its impact severity (EG Severity), not escalated.

EG Severity
3.7 LOWCVSS-B, impact only: no KEV listing, EPSS or EG-KEV tier raises it.a secondary CVSS source · CVSS v3.0 or v3.1
EG Likelihood
0.3% within 30 daysSource: FIRST EPSS. FIRST's exploitation probability, not an EchelonGraph model.
Confirmed exploitation
None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
EG Priority
SSVC Track at medium mission impactTrack at every mission impact level.CISA BOD 26-04: 60 days if the affected system is publicly exposed; Fix on system upgrade if it is not.Each input and its source, and whom BOD 26-04 binds: the SSVC and BOD 26-04 blocks below.

SSVC (CISA's decision table, applied by EchelonGraph)Track at every mission impact level.

Upgrade to qs 6.17.0 or later (from the CVE record's solution, Harborist). Apply it within your standard update timelines.

Exploitation none (no CISA value, KEV listing or exploit code on record) · Automatable no (CISA's BOD 26-04 default) · Technical impact partial (CVSS v4.0 confidentiality and integrity impact neither High). EchelonGraph holds no SSVC assessment of this CVE from CISA: none of these inputs is from Vulnrichment. EchelonGraph applied CISA's decision table to them; CISA publishes SSVC inputs and the table, not a decision for each CVE. Mission impact is CISA's Mission & Well-being decision point, and only you can judge it. CISA's table makes it high when Mission Prevalence is Essential — the vulnerable component "directly provides capabilities that constitute at least one MEF for at least one entity" (MEF: mission essential function) — or when Public Well-Being Impact is Irreversible: "multiple fatalities are likely", the cyber-physical system "is likely lost or destroyed", "extreme or serious externalities" are imposed on other parties, or social systems such as elections or the financial grid "are destabilized and potentially collapse". CISA's decision table

BOD 26-04 (CISA's remediation timeline, Table 1)60 days if the affected system is publicly exposed; Fix on system upgrade if it is not.

The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact partial (CVSS v4.0 confidentiality and integrity impact neither High). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

October 27, 2026

Last Modified

October 27, 2026

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

Data Freshness Timeline

(refreshed 8× in last 7d / 12× in last 30d)

Each row is a time one of our pipelines fetched, updated or re-scored this CVE. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. An arrow marks a change the record states ("CVSS v3 → 9.1"); EPSS and GHSA rows show the values recorded at that time, not what changed (EPSS values are rounded; hover one for the exact figures). Most recent first.

  1. 2026-11-02 16:43 UTCEPSS rescoreEPSS 0.3% · 21st percentile
  2. 2026-11-01 16:33 UTCEPSS rescoreEPSS 0.3% · 21st percentile
  3. 2026-10-31 16:31 UTCEPSS rescoreEPSS 0.3% · 21st percentile
  4. 2026-10-30 16:33 UTCEPSS rescoreEPSS 0.3% · 21st percentile
  5. 2026-10-29 16:32 UTCEPSS rescoreEPSS 0.3% · 21st percentile
  6. 2026-10-28 16:31 UTCEPSS rescoreEPSS 0.3% · 21st percentile
  7. 2026-10-27 20:26 UTCEG score recompute
  8. 2026-10-27 16:31 UTCEPSS rescoreEPSS 0.2% · 13th percentile
  9. 2026-10-27 08:01 UTCENISA EUVD ID recordedEUVD-2026-110630 · Source: ENISA EUVD
  10. 2026-10-27 07:26 UTCEG score recompute
  11. 2026-10-27 07:06 UTCEG score recomputeFirst assessed: 3.7 LOW
  12. 2026-10-27 07:05 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-110910?
CVE-2026-110910 is a low-severity vulnerability; its CVE record was published on October 27, 2026. Summary qs.stringify with allowEmptyArrays: true writes the key of an empty array without encoding it, even though keys are encoded by default. A key that contains & (or the configured delimiter), =, or # therefore becomes query string syntax instead of data, so a caller-supplied key name can add…
When was the CVE record for CVE-2026-110910 published?
The CVE record for CVE-2026-110910 was published on October 27, 2026. That is the record's publication date; the vulnerability itself may have been made public earlier. EchelonGraph's copy of the record carries a last-modified date of October 27, 2026; the record at its source may have been updated since.
Is CVE-2026-110910 actively exploited?
CVE-2026-110910 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0.3% probability of exploitation in the next 30 days (21st percentile of EPSS-scored CVEs).
What is the CVSS score of CVE-2026-110910?
CVE-2026-110910 has a CVSS base score of 3.7 (a secondary CVSS source that NVD displays; NVD's own analysis pending).
How do I remediate CVE-2026-110910?
The CVE record's solution for CVE-2026-110910, written by its CNA Harborist, names the fix: "Upgrade to qs 6.17.0 or later."

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-110910

Explore →

Is Your Infrastructure Affected by CVE-2026-110910?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.