CVE-2025-12758

What it actually does

The validator.js package's isLength() function before version 13.15.22 incorrectly calculates string length when Unicode variation selectors U+FE0F and U+FE0E are embedded in input. Because those special characters are not fully accounted for during length validation, an input may pass an application-defined maximum-length check while containing more effective characters or bytes than the application expects. Downstream impact depends on how the validated value is used: oversized values may be stored into fixed-length database fields, passed into components with stricter limits, used in serialization/parsing paths, or processed repeatedly in ways that can cause truncation, inconsistent authorization or business-rule decisions, application errors, memory pressure, or denial-of-service conditions.

Why it matters to the business

Applications that rely on affected validator.js versions for length limits may accept inputs larger than intended, which can lead to failed transactions, corrupted or truncated records, degraded service availability, and unexpected behavior in dependent systems. The current public exploitation signal is low: EPSS is 0.00506, it is not listed in CISA KEV, there is no reported ransomware association, and exploit maturity is listed as none. However, validator.js is commonly used in web application input validation, so organizations should still prioritize remediation where it protects externally reachable forms, APIs, account creation, profile fields, messaging, comments, filenames, or any workflow that stores user-controlled strings.

How an attack unfolds

An attacker identifies an application field or API parameter whose maximum length is enforced using the vulnerable isLength() function. The attacker submits a crafted string containing repeated Unicode variation selectors, especially U+FE0F or U+FE0E, in positions that cause the library's length calculation to undercount the true size or downstream impact of the input. The application accepts the value because validation appears to succeed. The oversized value is then stored, transformed, rendered, passed to another service, or written to a database or queue. Depending on downstream constraints, this can produce truncation, data inconsistencies, exceptions, excessive processing, or service disruption. Exploitation is application-dependent and generally requires a reachable input path that trusts validator.js length checks as the primary boundary control.

How to fix it

Upgrade validator.js / the npm validator package to version 13.15.22 or later. If consuming validatorjs/validator.js directly from Git, update to a revision that includes commit f2b5c17dbe03f2ca9ad9122c597f81e86ce1a9a1 or later. Rebuild and redeploy applications after updating lockfiles and container images so the fixed dependency is actually present at runtime. If immediate upgrade is not possible, add compensating validation that measures the same unit enforced by downstream systems, such as normalized Unicode code points, grapheme clusters, UTF-8 byte length, and database column byte/character limits. Consider normalizing or rejecting unexpected Unicode variation selectors in fields that do not require emoji or presentation selector behavior. Do not rely on client-side validation; enforce server-side limits before storage and before calls to downstream services.

How to confirm the fix worked

Confirm the deployed dependency version is fixed by checking package manifests and lockfiles with commands such as npm ls validator, yarn why validator, pnpm why validator, or software composition analysis tooling, and verify no runtime artifact still contains validator versions below 13.15.22. For source-based consumption, verify the deployed code includes commit f2b5c17dbe03f2ca9ad9122c597f81e86ce1a9a1 or later. Add regression tests that pass strings containing repeated \uFE0F and \uFE0E characters into every application validation path that depends on isLength(), and assert that values exceeding the intended downstream limit are rejected. Confirm database schemas, ORM models, API contracts, and queue/message size limits align with application validation rules. Review built containers, serverless bundles, and vendored dependencies because package-lock or source updates alone do not prove production remediation.

Typical attack path

1. Find a public or authenticated application endpoint that accepts user-controlled string input.
2. Infer or test that the endpoint enforces a maximum length using validator.js isLength() or a framework/library wrapper around it.
3. Craft input containing repeated Unicode variation selectors such as U+FE0F or U+FE0E to bypass the intended length boundary.
4. Submit the crafted value through a form, API request, upload metadata field, profile field, message body, or similar input channel.
5. Trigger downstream handling such as database insert/update, queueing, rendering, logging, serialization, or inter-service forwarding.
6. Observe impact such as accepted oversized values, truncation, validation inconsistencies, 4xx/5xx spikes, database errors, application exceptions, memory pressure, or denial-of-service behavior.

How to detect it

To assess prior exploitation, review web access logs, API gateway logs, WAF logs, application request logs, structured validation failure logs, database error logs, and APM traces for requests containing Unicode variation selectors U+FE0F or U+FE0E in fields subject to length limits. Look for repeated raw UTF-8 bytes EF B8 8F or EF B8 8E, URL-encoded forms %EF%B8%8F or %EF%B8%8E, JSON escaped forms \uFE0F or \uFE0E, and unusually long strings that nevertheless passed application validation. Correlate those requests with downstream symptoms: HTTP 500 responses, database truncation or value-too-long errors, queue/message rejection, serialization exceptions, increased latency, process memory growth, restarts, or denial-of-service alerts. Because these Unicode characters can appear legitimately in emoji-related input, treat isolated occurrences as weak signals and prioritize high repetition, placement in fields with strict length limits, association with errors, or repeated probing across many endpoints. There are no known threat actors or KEV-driven exploitation campaigns reported for this vulnerability in the provided data.

• \uFE0F
• \uFE0E
• %EF%B8%8F
• %EF%B8%8E
• EF B8 8F
• EF B8 8E
• \xEF\xB8\x8F
• \xEF\xB8\x8E
• node_modules/validator
• validator/lib/isLength
• validator/es/lib/isLength
• Data too long for column
• value too long for type character varying
• String or binary data would be truncated
• ORA-12899

What your security team should do

• Inventory applications and services using validator.js / npm validator, especially externally reachable web forms and APIs.
• Prioritize upgrades to validator 13.15.22 or later for internet-facing, multi-tenant, authentication, registration, messaging, profile, content submission, and file metadata workflows.
• Search lockfiles, SBOMs, container images, and vendored JavaScript bundles for validator versions below 13.15.22.
• Add targeted tests for Unicode variation selectors in input length validation and include them in CI/CD security regression suites.
• Where business logic does not require variation selectors, normalize or reject U+FE0F and U+FE0E at input boundaries.
• Review database and downstream service errors for signs of oversized accepted values, truncation, or validation bypass since the vulnerability was published.
• Tune monitoring for spikes in 400/413/422/500 responses, database truncation errors, and requests containing URL-encoded or raw UTF-8 variation selector bytes.
• Treat this as lower urgency than known-exploited vulnerabilities, but remediate in normal patch cycles and sooner where affected validation protects availability or data integrity boundaries.