CVE-2018-3774

What it actually does

url-parse versions before 1.4.3 can incorrectly parse specially crafted URLs and return an incorrect hostname. Applications that rely on this parsed hostname for security decisions can be tricked into approving a URL that is interpreted differently by browsers, HTTP clients, proxies, or downstream services. Depending on how the library is used, this can enable server-side request forgery, open redirect, hostname allowlist bypass, authentication or OAuth redirect validation bypass, and routing of requests to attacker-controlled or internal destinations. The flaw is remotely triggerable where untrusted URLs are accepted and parsed without additional canonicalization or strict allowlisting.

Why it matters to the business

Systems using vulnerable url-parse versions in URL validation paths may expose internal services, cloud metadata endpoints, user credentials, session tokens, or trusted redirect flows. Even though this issue is old, not listed in CISA KEV, and has a relatively low EPSS score, it has a critical CVSS rating because exploitation can be unauthenticated and can cross trust boundaries when the affected library protects redirects, webhooks, fetch/proxy features, SSO callbacks, or URL allowlists. Long-lived JavaScript dependencies are commonly embedded transitively, so exposure may persist in applications that have not refreshed dependency locks since 2018.

How an attack unfolds

An attacker identifies an application feature that accepts a user-controlled URL, such as a redirect parameter, webhook target, callback URL, image fetcher, proxy endpoint, import-by-URL function, or OAuth redirect URI. The attacker crafts a URL containing parser-confusion characters such as backslashes, embedded credentials, encoded separators, or mixed slash forms so that vulnerable url-parse reports a benign or allowlisted hostname while the actual consumer of the URL resolves or navigates to a different destination. If the affected feature is a redirect, the victim can be sent to an attacker-controlled site that appears to pass server-side validation. If the feature causes server-side fetching, the application server may be induced to connect to internal IP ranges, localhost, cloud metadata services, or attacker infrastructure. If the parser is used in authentication or callback validation, the attacker may bypass hostname checks and capture tokens, authorization codes, or trusted application flows.

How to fix it

Upgrade url-parse to version 1.4.3 or later. For Git-based consumers of unshiftio/url-parse, update to commit 53b1794e54d0711ceb52505e0f74145270570d5a or a later release containing that fix. Rebuild and redeploy applications after updating dependency lockfiles so the fixed package is actually present in production artifacts. Because url-parse is often pulled in transitively, audit package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, vendored node_modules directories, and container images for vulnerable versions. As defense in depth, avoid making security decisions from a single non-canonical URL parse; normalize and validate URLs using a consistent parser, reject backslashes and encoded control/separator characters in security-sensitive URLs, enforce explicit scheme allowlists, compare canonical hostnames after IDNA/punycode normalization, block userinfo in URLs where not required, and enforce egress restrictions for server-side fetch functionality.

How to confirm the fix worked

Confirm that all runtime and build artifacts use url-parse 1.4.3 or later, or include commit 53b1794e54d0711ceb52505e0f74145270570d5a or later for Git-sourced dependencies. Use dependency tooling such as npm ls url-parse, npm audit, yarn why url-parse, pnpm why url-parse, SCA scanners, and container image scans to verify no vulnerable transitive copy remains. Review lockfiles and deployed node_modules contents rather than relying only on package.json ranges. Functionally test any URL validation logic with malformed URLs containing backslashes, percent-encoded slashes or backslashes, embedded @ userinfo, mixed slash forms, localhost/private IP targets, and cloud metadata IPs; the application should reject ambiguous inputs and should not redirect or fetch a destination different from the validated canonical host. Validate SSRF controls by confirming that server-side URL-fetching features cannot reach loopback, private address ranges, link-local metadata addresses, or unauthorized domains.

Typical attack path

1. Find an externally reachable feature that accepts a URL or hostname as input.
2. Determine whether the application validates the URL using vulnerable url-parse behavior by testing edge-case URL forms with backslashes, encoded separators, userinfo, or mixed slash syntax.
3. Craft a URL that vulnerable validation interprets as an approved hostname while the browser, HTTP client, proxy, or downstream service interprets as an attacker-selected hostname.
4. Submit the crafted URL through redirect, callback, webhook, proxy, fetch, or import functionality.
5. Use the resulting redirect or server-side request to reach attacker infrastructure, internal network services, localhost endpoints, or cloud metadata endpoints.
6. Exploit the trust boundary impact, such as stealing tokens, bypassing redirect validation, accessing internal data, or pivoting through SSRF-capable services.

How to detect it

To determine whether exploitation already occurred, review application access logs, WAF logs, reverse proxy logs, API gateway logs, redirect-service logs, authentication and OAuth logs, webhook delivery logs, server-side fetch/proxy logs, DNS resolver logs, and outbound proxy/firewall logs. Focus on parameters commonly named url, uri, target, redirect, redirect_uri, return, returnUrl, next, callback, callback_url, webhook, endpoint, image, fetch, import, or proxy. Look for crafted URLs containing backslashes, percent-encoded backslashes or slashes, embedded @ signs, userinfo before the hostname, mixed slash syntax, excessive URL encoding, localhost/private IP destinations, link-local metadata IPs, or suspicious redirects to newly registered or unrelated domains. For SSRF scenarios, correlate inbound requests carrying suspicious URL parameters with subsequent outbound connections from application servers to 127.0.0.0/8, ::1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254, internal DNS names, or unexpected external hosts. For open redirect or authentication bypass scenarios, review 3xx responses and identity-provider logs for redirect_uri/callback values that differ from approved domains after canonical parsing. Also inspect dependency and deployment artifacts for vulnerable url-parse versions to scope periods of exposure.

• url-parse@1.0.0
• url-parse@1.1.0
• url-parse@1.2.0
• url-parse@1.3.0
• url-parse@1.4.0
• url-parse@1.4.1
• url-parse@1.4.2
• "url-parse": "<1.4.3"
• "url-parse": "1.4.2"
• node_modules/url-parse/
• %5c@
• %5C@
• \\@
• http://localhost
• http://127.0.0.1
• http://[::1]
• http://169.254.169.254
• http://0.0.0.0
• redirect_uri=
• callback_url=
• returnUrl=
• webhook=
• target=
• url=

What your security team should do

• Prioritize upgrading url-parse to 1.4.3 or later everywhere it appears, including transitive dependencies and containerized builds.
• Inventory application features that accept URLs, especially redirects, OAuth/SAML callbacks, webhooks, server-side fetchers, URL previews, file importers, and proxy endpoints.
• Search dependency manifests and lockfiles for url-parse versions below 1.4.3 and block vulnerable versions in CI/CD dependency policy.
• Add regression tests for URL parser confusion cases so future dependency changes do not reintroduce hostname validation bypasses.
• Harden URL validation centrally: reject ambiguous syntax, require http or https only where appropriate, forbid userinfo unless explicitly needed, and compare canonical hostnames against exact allowlists.
• Implement outbound network controls for server-side fetchers to prevent access to localhost, RFC1918 ranges, link-local addresses, and cloud metadata services.
• Review historical logs for suspicious redirect or fetch parameters containing parser-confusion characters and for unexpected outbound requests to internal or metadata destinations.
• Monitor SSO, OAuth, and authentication logs for redirect_uri or callback values that include encoded separators, backslashes, embedded credentials, or unexpected destination domains.