GHSA-gf8q-jrpm-jvxq

What it actually does

node-forge contained URL parsing behavior that could incorrectly interpret or normalize certain crafted URLs. In applications that rely on node-forge URL parsing results for trust decisions, redirects, allowlists, identity-provider endpoints, certificate-related workflows, or outbound request destinations, this can cause the application to treat an attacker-controlled URL as safe or different from what is ultimately used. The primary risk class is open redirect or URL confusion; impact depends heavily on how the consuming application uses the parsed URL.

Why it matters to the business

Applications using vulnerable node-forge versions may unintentionally redirect users to attacker-controlled sites or make incorrect security decisions based on malformed URLs. This can support phishing, credential theft, authentication-flow abuse, token leakage, and brand impersonation. Because node-forge is a common npm dependency and may be present transitively, organizations should verify dependency trees even if they do not import it directly. This issue is not listed in CISA KEV and no public exploit maturity is indicated, so urgency is lower than actively exploited vulnerabilities, but remediation is still recommended because URL parsing flaws are commonly chained into broader attacks.

How an attack unfolds

An attacker first identifies an application feature that accepts, stores, validates, redirects to, or otherwise processes a user-supplied URL through a vulnerable node-forge version. They then craft a URL that is parsed differently by node-forge than by a browser, proxy, identity provider, HTTP client, or downstream component. If the application trusts the vulnerable parsing result, it may approve a destination that appears to match an allowed host or scheme while the user or backend is ultimately sent somewhere attacker-controlled. In a typical phishing scenario, the attacker embeds the crafted URL in a trusted application link; the application processes it and redirects the victim to a malicious site that imitates a login or authorization page. In backend use cases, the same parsing confusion could influence outbound destinations or policy checks, depending on application logic.

How to fix it

Upgrade node-forge to version 1.0.0 or later. For npm-based projects, update direct dependencies in package.json and regenerate the lockfile using the organization’s standard package manager workflow. Also inspect transitive dependency paths with tools such as npm ls node-forge, yarn why node-forge, pnpm why node-forge, or software composition analysis tooling, and update parent packages where node-forge is pulled indirectly. After upgrading, review application code that accepts redirect URLs, callback URLs, webhook URLs, or outbound destinations: enforce strict allowlists using a single well-tested parser, reject ambiguous URLs, require expected schemes such as https, normalize before validation, and avoid trusting user-controlled redirect destinations unless explicitly allowed.

How to confirm the fix worked

Confirm that all deployed builds resolve node-forge to version 1.0.0 or later. Validate package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, container images, serverless bundles, and built artifacts because vulnerable JavaScript dependencies can remain embedded after source-level updates. Run software composition analysis against production artifacts where possible. Functionally test any URL-handling code with malformed URLs, encoded delimiters, mixed schemes, embedded credentials, backslashes, excessive slashes, punycode/IDN hostnames, and hostnames containing trusted-domain substrings to verify that invalid or unapproved destinations are rejected. Confirm redirects only target explicitly allowed destinations and that backend outbound requests cannot be steered to arbitrary hosts.

Typical attack path

1. Find an application endpoint or workflow that accepts a user-controlled URL, callback URL, redirect target, webhook URL, or external resource locator.
2. Determine that the application or one of its dependencies uses a vulnerable version of node-forge for URL parsing or validation.
3. Craft a malformed or ambiguous URL that node-forge interprets as acceptable while another component interprets it as an attacker-controlled destination.
4. Send the crafted URL to victims, submit it to the application, or use it in an authentication or integration flow.
5. Abuse the resulting redirect or URL confusion to route users or requests to attacker infrastructure.
6. Use the attacker-controlled destination for phishing, credential capture, token theft, traffic interception, or as part of a larger exploit chain.

How to detect it

This vulnerability does not have a single universal host indicator because exploitation depends on how an application uses node-forge to parse URLs. To check for prior abuse, review web access logs, application logs, reverse proxy logs, WAF logs, authentication logs, email security telemetry, and redirect/callback handling logs for unusual URL parameters that contain external domains, encoded delimiters, embedded credentials, backslashes, repeated slashes, mixed schemes, or trusted-domain substrings inside attacker-controlled hostnames. Focus on endpoints with parameters commonly named url, redirect, redirect_uri, returnUrl, return_url, next, target, destination, callback, callback_url, continue, relayState, webhook, or link. Look for successful HTTP 3xx responses to unfamiliar domains, spikes in redirect activity, user complaints of phishing after clicking legitimate-domain links, and authentication events where authorization codes, tokens, or sessions may have been sent to unexpected redirect destinations. Correlate suspicious redirect requests with subsequent logins, password resets, OAuth consent events, token issuance, session creation, and anomalous user-agent/IP changes.

• node-forge@0.
• node-forge@1.0.0-rc
• node_modules/node-forge/package.json
• package-lock.json
• yarn.lock
• pnpm-lock.yaml
• redirect_uri=
• redirect_url=
• returnUrl=
• return_url=
• callback_url=
• callback=
• next=
• target=
• destination=
• continue=
• RelayState=
• %2f%2f
• %5c
• \\
• @
• http://
• https://

What your security team should do

• Inventory all applications and packages using node-forge, including transitive dependencies.
• Prioritize upgrades to node-forge 1.0.0 or later in internet-facing applications, authentication flows, SSO/OAuth/OIDC integrations, payment flows, email-link workflows, and systems that process webhooks or user-supplied URLs.
• Review redirect and callback URL validation logic for parser inconsistencies and overly broad allowlists.
• Add automated dependency scanning to CI/CD to detect vulnerable node-forge versions in source, lockfiles, containers, and deployable artifacts.
• Create regression tests for URL parsing and redirect validation edge cases.
• Monitor for suspicious redirects from trusted application domains to unfamiliar external domains, especially links delivered by email, chat, or support workflows.
• Treat any evidence of phishing or token leakage through trusted redirect links as a potential compromise requiring credential/session/token review.