GHSA-g64q-3vg8-8f93

What it actually does

The vulnerability is a prototype pollution flaw in the pez package caused by insufficient validation of attacker-controlled object keys. If untrusted input is parsed or merged into JavaScript objects without blocking special properties such as __proto__, constructor, or prototype, an attacker may be able to modify Object.prototype or other shared prototypes. This can cause unexpected properties to appear across objects in the same Node.js process, potentially altering application logic, bypassing checks, corrupting data handling, or creating conditions for denial of service or further exploitation depending on how the application uses polluted properties.

Why it matters to the business

Applications that process untrusted input through vulnerable versions of pez may behave unpredictably, including incorrect authorization decisions, broken request processing, service instability, or data integrity issues. Because this issue was published several years ago and no active exploitation or KEV listing is indicated, urgency is lower than for actively exploited vulnerabilities, but vulnerable dependency use should still be remediated as part of routine software supply chain maintenance.

How an attack unfolds

An attacker first identifies an application feature that accepts structured input processed by pez, such as multipart form data or request payloads. They then submit crafted input containing prototype-related property names, commonly __proto__, constructor, or prototype, arranged so the vulnerable parsing or object construction logic assigns attacker-controlled values into a shared JavaScript prototype. Once the prototype is polluted, later application code may read inherited properties as though they were legitimate object fields. The resulting impact depends on application-specific logic: the attacker may influence conditional checks, change default values, trigger exceptions, disrupt parsing behavior, or cause denial of service. Exploitation generally requires a reachable code path where untrusted input is handled by the vulnerable package and where downstream application logic is sensitive to inherited properties.

How to fix it

Upgrade pez to a non-vulnerable version if one is available through the package manager or upstream project. Because no fixed version information was provided, verify the currently installed package version against the latest upstream advisory and dependency metadata. If upgrading is not immediately possible, mitigate by preventing untrusted input from creating or merging object keys named __proto__, prototype, or constructor; use safe object creation patterns such as Object.create(null) for dictionaries; avoid unsafe recursive merge behavior; and ensure security-sensitive checks use Object.hasOwn(), hasOwnProperty.call(), or equivalent own-property validation rather than trusting inherited properties. Rebuild and redeploy applications after dependency updates so the patched package is present in runtime artifacts.

How to confirm the fix worked

Confirm exposure by reviewing package manifests and lockfiles for pez and determining whether the installed version is affected according to the upstream advisory. Validate remediation by reinstalling dependencies, rebuilding artifacts, and checking the resolved dependency tree to ensure the vulnerable version is no longer present. Functional validation should include sending benign test payloads containing __proto__, constructor, and prototype keys to affected parsing paths and confirming they are rejected, sanitized, or treated only as ordinary data without modifying Object.prototype. In Node.js, controlled test cases can check that properties injected via test payloads do not appear on newly created empty objects after request processing.

Typical attack path

1. Identify a web application or Node.js service that uses the vulnerable pez package in a request-processing path.
2. Find an input vector that accepts structured or multipart data processed by the affected parser.
3. Send a crafted request containing prototype pollution keys such as __proto__, constructor, or prototype.
4. Cause the parser or merge logic to assign attacker-controlled values onto a shared JavaScript prototype.
5. Trigger application functionality that reads polluted inherited properties.
6. Leverage the altered application behavior for logic manipulation, service disruption, or other application-specific impact.

How to detect it

Look for evidence of attempted prototype pollution in HTTP access logs, API gateway logs, WAF logs, application request logs, and Node.js error logs. Search request bodies, query strings, multipart field names, JSON keys, and URL-encoded parameters for prototype-related keys such as __proto__, constructor, and prototype, especially when nested or encoded. Review application exceptions occurring shortly after suspicious requests, including TypeError messages, unexpected authorization or validation failures, parser crashes, or abnormal process restarts. If request body logging is not available, correlate spikes in 4xx/5xx responses, Node.js process crashes, or malformed multipart parsing errors with external requests containing encoded prototype pollution strings in URLs or headers. Because no specific exploitation campaign or malware behavior is provided, detection should focus on exploit attempts and application anomalies rather than fixed file or host indicators.

• __proto__
• constructor.prototype
• prototype.constructor
• %5F%5Fproto%5F%5F
• %255F%255Fproto%255F%255F
• [__proto__]
• __proto__[
• constructor[prototype]
• prototype[polluted]
• polluted=true

What your security team should do

• Inventory all applications and build artifacts for use of the pez package, including transitive dependencies in package-lock.json, yarn.lock, pnpm-lock.yaml, and software composition analysis results.
• Upgrade to a safe upstream version or remove the dependency if it is unused or replaceable.
• Add input validation or request filtering for prototype pollution keys in externally reachable parsing paths.
• Prioritize remediation for internet-facing Node.js services, APIs that process multipart or structured user input, and applications with authorization or routing logic based on object properties.
• Add regression tests that verify prototype pollution payloads cannot modify global prototypes.
• Monitor dependency advisories for pez and related parser libraries, since no active exploitation or KEV status is currently indicated but stale JavaScript dependencies remain a common supply chain risk.