CVE-2026-59952

What it actually does

Valibot versions prior to 1.4.2 can throw an unhandled TypeError in the documented flatten() helper when validation issues include attacker-controlled record keys that collide with inherited Object.prototype properties, such as toString, valueOf, or hasOwnProperty. The flaw is reachable through normal record() validation: if the key schema or value schema rejects an entry with one of those keys, Valibot builds an issue path containing that key; flatten() then resolves flatErrors.nested[dotPath] to an inherited function instead of an own error array and attempts to call .push(...) on it. This is an application-level availability and error-handling flaw, not global prototype pollution and not direct code execution.

Why it matters to the business

Applications that accept user-controlled JSON or object-like input, validate it with Valibot record(), and call flatten() to format validation errors may have request handlers crash or return 500 errors instead of clean validation responses. The practical consequence is targeted denial of service against affected API endpoints, degraded reliability, noisy error rates, and potential disruption of workflows that depend on form submission, API ingestion, or configuration validation. The issue is recently published, has low EPSS, is not in CISA KEV, and has no known exploit maturity in the supplied data, so urgency is primarily driven by whether internet-facing endpoints use the vulnerable validation pattern.

How an attack unfolds

An unauthenticated remote attacker identifies an endpoint that accepts a user-controlled object and validates it using Valibot record(). The attacker submits a payload containing an own property whose name collides with Object.prototype, such as toString, valueOf, or hasOwnProperty. If that key or its value violates the schema, Valibot records a validation issue with the attacker-controlled key in the issue path. When the application uses Valibot's flatten() helper to convert validation issues into a response structure, flatten() treats the inherited Object.prototype method as if it were an existing nested error array and calls .push(...) on it. This raises a TypeError, causing the request path to fail and potentially producing repeated 500 responses when the payload is replayed. Exploitation does not require authentication, user interaction, or special network positioning when the vulnerable validation path is exposed over the network.

How to fix it

Upgrade Valibot to version 1.4.2 or later wherever it is used. If immediate upgrade is not possible, avoid passing validation issues containing user-controlled record keys directly to the vulnerable flatten() helper; implement a local safe error-flattening routine that stores nested errors only on objects with null prototypes or verifies that the target property is an own array before calling push(). As defense in depth, reject or normalize dangerous record keys such as toString, valueOf, hasOwnProperty, __defineGetter__, __defineSetter__, propertyIsEnumerable, isPrototypeOf, __lookupGetter__, and __lookupSetter__ before validation when those keys are not legitimate business inputs. Ensure request handlers catch validation-formatting exceptions and return controlled 4xx responses rather than uncaught 500 errors.

How to confirm the fix worked

Confirm dependency resolution shows Valibot 1.4.2 or later in package lockfiles, SBOMs, container images, and deployed artifacts. Review code for flows that combine record() validation with flatten() on validation failures, especially on internet-facing routes that process JSON objects. Add a regression test that submits an invalid record containing keys such as toString, valueOf, and hasOwnProperty and verifies the application returns a structured validation response rather than throwing TypeError or returning HTTP 500. In running environments, test representative endpoints safely with non-production data and verify that malformed inputs with those keys no longer crash the request path.

Typical attack path

1. Find an API endpoint, form handler, webhook, or ingestion route that accepts object/record-style user input.
2. Send test payloads containing suspicious own keys such as toString, valueOf, or hasOwnProperty.
3. Trigger a validation failure for that key or its value so Valibot creates an issue path containing the key.
4. Rely on the application calling Valibot flatten() to format validation errors.
5. Observe a TypeError or HTTP 500 response instead of a structured validation error.
6. Repeat requests to degrade availability of the affected request path.

How to detect it

Review application, API gateway, WAF, APM, and error-tracking logs for validation requests containing object keys named toString, valueOf, or hasOwnProperty followed by TypeError exceptions or HTTP 500 responses. Focus on endpoints that accept JSON bodies, webhook payloads, form submissions, or arbitrary key/value records. In Node.js application logs and stack traces, look for errors thrown during Valibot validation-error formatting, especially references to flatten(), nested errors, or .push not being a function. Correlate repeated requests from the same source IP, user agent, API token, or session that contain Object.prototype-colliding keys with increased 5xx rates. Because this issue does not create a persistent backdoor or global prototype pollution, evidence is most likely to appear as transient request logs, exception traces, crash reports, process restarts, and APM error events rather than durable filesystem artifacts.

• "toString"
• "valueOf"
• "hasOwnProperty"
• "TypeError" "push is not a function"
• "TypeError: flatErrors.nested"
• "flatten" "push is not a function"
• "valibot" "flatten" "TypeError"
• "Object.prototype" "toString"
• "Object.prototype" "hasOwnProperty"
• "HTTP/1.1 500" "toString"
• "HTTP/1.1 500" "valueOf"
• "HTTP/1.1 500" "hasOwnProperty"

What your security team should do

• Inventory services and applications that depend on Valibot and prioritize those exposing unauthenticated or internet-facing validation endpoints.
• Upgrade Valibot to 1.4.2 or later and rebuild/redeploy affected applications, containers, and serverless functions.
• Search source code for Valibot record() plus flatten() usage and add targeted regression tests for Object.prototype-colliding keys.
• Add temporary input filtering or exception handling on exposed endpoints if upgrade cannot be completed immediately.
• Monitor application logs and APM traces for spikes in TypeError exceptions, HTTP 500 responses, and request bodies containing toString, valueOf, or hasOwnProperty as submitted object keys.
• Treat repeated requests containing these keys followed by validation-related TypeError crashes as probable denial-of-service probing or exploitation.