GHSA-hxcm-v35h-mg2x

What it actually does

querystringify is affected by a prototype pollution weakness caused by unsafe handling of attacker-controlled query string keys. If an application parses untrusted query parameters with a vulnerable version, specially crafted property names such as prototype-related keys can modify Object.prototype or other inherited properties in the JavaScript runtime. The direct impact depends on how the consuming application uses parsed objects: in many cases this causes unexpected application behavior or denial of service; in more dangerous cases, polluted properties can influence authorization checks, configuration flags, templating behavior, or object-merging logic elsewhere in the application.

Why it matters to the business

Applications that depend on vulnerable versions of querystringify may be exposed to reliability and integrity risks from malicious query strings. Because this is a widely reusable npm component, the vulnerability can be inherited indirectly through downstream packages even when the application does not import it directly. There is no indication that this advisory is in CISA KEV or known ransomware campaigns, and no public exploit maturity is reported in the provided data, but the issue has been public for years and should be remediated as part of dependency hygiene and software supply-chain risk reduction.

How an attack unfolds

An attacker first identifies a web application endpoint that accepts URL query strings and uses a vulnerable version of querystringify to parse them. The attacker sends a crafted request containing prototype-pollution keys, for example keys that attempt to assign values under __proto__, constructor, or prototype-like paths. When the vulnerable parser processes the query string, those attacker-supplied keys may be applied to an object in a way that contaminates inherited JavaScript object properties. The attacker then triggers application code paths that read object properties, merge parsed input into configuration objects, perform security decisions using truthy or default values, or render content based on polluted properties. The final outcome depends on the application: it may range from crashes and logic corruption to bypass of application controls if sensitive decisions trust polluted object properties.

How to fix it

Upgrade querystringify to version 2.0.0 or later. If querystringify is present transitively, update the parent dependency that brings it in, regenerate the lockfile, and verify the resolved dependency tree no longer contains vulnerable versions. Where immediate upgrade is not possible, reduce exposure by rejecting query parameter keys containing prototype-pollution primitives such as __proto__, prototype, and constructor; avoid recursively merging untrusted parsed objects into application configuration or security-sensitive objects; create dictionaries with null prototypes where appropriate; and validate all query parameters against an allowlist schema before use. These mitigations should be treated as temporary controls, not substitutes for upgrading.

How to confirm the fix worked

Confirm that package manifests and lockfiles resolve querystringify to 2.0.0 or later using package-manager tooling such as npm ls querystringify, yarn why querystringify, pnpm why querystringify, or software composition analysis scans. Rebuild and redeploy affected applications after dependency updates. Add regression tests that parse query strings containing __proto__, constructor, and prototype keys and verify that Object.prototype and application default objects are not modified. Dynamic validation can include sending benign test requests with prototype-pollution payloads in a non-production environment and confirming that no inherited properties are created and no application behavior changes.

Typical attack path

1. Find a web endpoint or API route that accepts attacker-controlled query parameters.
2. Determine or infer that the application or one of its dependencies uses a vulnerable version of querystringify.
3. Send a crafted URL containing prototype-pollution property names such as __proto__, constructor, or prototype in query parameter keys.
4. Cause the vulnerable parser to process the malicious query string and alter inherited JavaScript object behavior.
5. Trigger downstream application functionality that relies on object defaults, configuration properties, authorization flags, or merge behavior affected by the polluted prototype.
6. Leverage the resulting behavior for denial of service, application logic manipulation, or potential security-control bypass depending on the application implementation.

How to detect it

To assess possible prior exploitation, review HTTP access logs, WAF logs, API gateway logs, reverse proxy logs, and application request logs for query strings containing prototype-pollution keys. Focus on externally reachable endpoints that accept arbitrary query parameters and services known to include vulnerable querystringify versions. Look for URL-encoded and nested variants of __proto__, constructor, and prototype in parameter names, repeated probing across many endpoints, and follow-on errors after such requests, including JavaScript TypeErrors, unexpected configuration values, authorization anomalies, or crashes. In application telemetry, correlate suspicious requests with spikes in 4xx/5xx responses, process restarts, unhandled exceptions, and unusual changes in request handling. Because prototype pollution often leaves no persistent file artifact, detection is primarily log- and behavior-based unless the polluted state was serialized into caches, sessions, or stored objects by application logic.

• __proto__
• %5F%5Fproto%5F%5F
• %5f%5fproto%5f%5f
• constructor.prototype
• constructor%5Bprototype%5D
• constructor[prototype]
• prototype.polluted
• prototype%5Bpolluted%5D
• __proto__[polluted]
• __proto__.polluted
• %5F%5Fproto%5F%5F%5Bpolluted%5D
• ?__proto__=
• &__proto__=
• ?constructor[prototype]
• &constructor[prototype]
• ?constructor.prototype
• &constructor.prototype

What your security team should do

• Inventory applications and services that include querystringify directly or transitively.
• Prioritize upgrading querystringify to 2.0.0 or later in all maintained codebases and container images.
• Use software composition analysis in CI/CD to block vulnerable querystringify versions from being introduced again.
• Search application code for unsafe merges of parsed query parameters into configuration, session, authorization, template, or options objects.
• Add input validation that rejects prototype-pollution keys in query strings, request bodies, and other user-controlled object paths.
• Add regression tests for prototype-pollution payloads across web request parsing and object-merge code paths.
• Review logs for historical requests containing prototype-pollution key names, especially on externally exposed endpoints.