CVE-2025-56200

What it actually does

validator.js versions through 13.15.15 incorrectly validate URLs in the isURL() function because the library parses schemes using the delimiter '://', while web browsers interpret the scheme using ':' alone. This mismatch can allow a string that passes server-side or client-side validation as an apparently acceptable URL to be interpreted by the browser as a different scheme or destination. In applications that rely on isURL() to allow-list protocols or domains before rendering links, redirects, iframe sources, OAuth callback targets, return URLs, or user-controlled navigation targets, the flaw can enable cross-site scripting through dangerous browser schemes and open redirects to attacker-controlled sites.

Why it matters to the business

Applications using affected validator.js versions may incorrectly trust attacker-supplied URLs, allowing users to be redirected to phishing pages or exposed to script execution in the context of the vulnerable application. The direct risk depends on how the application uses isURL(): impact is highest where validated URLs are later placed into clickable links, redirects, HTML attributes, embedded content, or authentication flows. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no reported exploit maturity in the supplied data, but validator.js is a common dependency, so exposure may exist indirectly through many JavaScript applications and packages.

How an attack unfolds

An attacker identifies application functionality that accepts a URL and validates it with validator.js isURL(), such as redirect parameters, profile links, callback URLs, CMS content, marketing links, or user-generated HTML attributes. The attacker crafts a URL whose syntax is interpreted one way by validator.js and another way by the browser, taking advantage of the library’s use of '://' for protocol parsing while the browser treats ':' as the scheme delimiter. If the application allows the value after validation and later sends a redirect, renders an anchor, or injects it into a browser-interpreted URL context, the browser may navigate to an attacker-controlled destination or execute a dangerous scheme. This can result in credential phishing, session theft if script execution is possible, abuse of trusted domains in social engineering, or chaining with authentication and authorization flows that trust validated redirect destinations.

How to fix it

Upgrade validator.js to a version that fixes this URL parsing discrepancy once a patched version is available; the supplied data identifies versions through 13.15.15 as affected but does not provide exact fixed versions. Where immediate upgrade is not possible, do not rely solely on isURL() for security decisions. Normalize and parse URLs with the platform URL parser, compare the parsed protocol using the browser-equivalent ':' semantics, and enforce explicit allow-lists such as only 'https:' and required trusted hostnames after canonicalization. Reject dangerous schemes including javascript:, data:, vbscript:, file:, and other non-HTTP schemes unless there is a specific business need. For redirects, prefer server-side route identifiers or relative paths over arbitrary URLs, and require exact host allow-lists for external redirects. Ensure all user-supplied URLs rendered into HTML are contextually encoded and protected by a restrictive Content Security Policy that blocks inline script execution and disallows unsafe navigation or embedding patterns where feasible.

How to confirm the fix worked

Inventory direct and transitive use of validator.js and identify packages resolving to versions 13.15.15 or earlier. Review all calls to isURL() and determine whether the validated value is used in redirects, links, HTML attributes, iframe/embed sources, OAuth/SAML/OIDC callback handling, return parameters, webhooks, or user-generated content. Add regression tests with scheme-confusion payloads and verify that only explicitly allowed schemes and canonical hostnames are accepted after parsing with the runtime URL parser. Confirm package lockfiles, build artifacts, containers, and deployed bundles no longer contain affected validator.js versions after remediation. For web applications, manually test exposed URL parameters and forms using crafted non-HTTP or scheme-confusion inputs and confirm they are rejected, sanitized, or rendered inert rather than navigated to or executed by the browser.

Typical attack path

1. Find an input that accepts a URL, such as a redirect target, returnUrl, callback URL, website/profile field, link shortener destination, embedded media URL, or HTML attribute value.
2. Submit crafted URLs designed to pass validator.js isURL() checks while being interpreted differently by browsers because ':' and '://' parsing differ.
3. Confirm whether the application stores, reflects, redirects to, or renders the accepted URL in a browser-reachable context.
4. Use an accepted malicious URL to trigger an open redirect to attacker infrastructure or a browser-executed script scheme where the surrounding application context permits it.
5. Deliver the crafted link to victims through phishing, user-generated content, invitation flows, comments, messages, or links that appear to originate from the legitimate application.
6. Abuse the resulting redirect or script execution to steal credentials, tokens, or sensitive data, or to pivot into further application-specific attacks.

How to detect it

To assess prior exploitation, review web access logs, application logs, WAF logs, CDN logs, reverse proxy logs, and redirect/audit logs for URL-bearing parameters containing dangerous schemes, unusual scheme delimiters, or encoded newline/control characters. Focus on endpoints that perform redirects, accept callback or return parameters, store user profile links, render user-generated content, or process OAuth/OIDC/SAML redirect destinations. Search for parameters such as url, uri, link, href, target, redirect, redirect_uri, return, returnUrl, next, continue, destination, callback, and callbackUrl containing javascript:, data:, vbscript:, file:, or scheme-confusion forms using :// and encoded CR/LF sequences. For possible XSS, correlate suspicious requests with subsequent CSP violation reports, browser error telemetry, anomalous session activity, credential resets, or reports of unexpected pop-ups or navigation. For possible open redirect abuse, correlate inbound requests that include suspicious redirect values with outbound navigation to newly registered domains, lookalike domains, credential-harvesting pages, or high-volume 302 responses to external hosts. Because exploitation artifacts are application-specific and may not leave server-side evidence after a user clicks a rendered link, also review stored content fields and cached pages for malicious URL values that may still be present.

• javascript:
• javascript://
• data:
• data://
• vbscript:
• vbscript://
• file:
• file://
• %0a
• %0A
• %0d
• %0D
• \u000a
• \u000d
• redirect_uri=javascript
• redirect=javascript
• returnUrl=javascript
• return=javascript
• next=javascript
• url=javascript
• target=javascript
• href=javascript
• callback=javascript
• callbackUrl=javascript
• redirect_uri=data
• redirect=data
• returnUrl=data
• next=data
• url=data
• target=data
• href=data

What your security team should do

• Prioritize applications that accept user-controlled URLs and then redirect, render, embed, or store those URLs for other users.
• Inventory validator.js usage across source repositories, package lockfiles, container images, and frontend bundles; flag versions through 13.15.15 for remediation review.
• Patch by upgrading validator.js when a fixed release is available, and redeploy all affected services and static frontend bundles.
• Add centralized URL validation utilities that parse with the native URL parser, enforce 'https:' by default, and compare canonical hostnames against explicit allow-lists.
• Harden redirect handling by replacing arbitrary redirect URLs with relative paths, signed redirect targets, or server-side destination identifiers.
• Search logs for suspicious URL parameters containing dangerous schemes or encoded control characters, especially in redirect, callback, return, next, url, target, and link parameters.
• Add automated tests and SAST rules to identify security-sensitive use of isURL() without additional scheme and hostname enforcement.
• Deploy or tune CSP, output encoding, and phishing-resistant authentication controls to reduce the impact of any missed URL-validation bypass.