CVE-2025-27625

What it actually does

Jenkins 2.499 and earlier, and Jenkins LTS 2.492.1 and earlier, incorrectly treat redirect targets beginning with backslash characters as safe internal destinations. Browsers can interpret leading backslashes as a scheme-relative or network-path redirect, causing a Jenkins-generated URL to send the user to an attacker-controlled external site. The flaw does not directly provide code execution or authentication bypass, but it enables abuse of trusted Jenkins URLs for phishing, credential harvesting, session-token theft attempts, or user redirection into follow-on attacks.

Why it matters to the business

The primary risk is trust abuse: users may click a legitimate-looking Jenkins link and be silently redirected to a malicious site. For organizations where Jenkins is part of the software delivery pipeline, successful phishing can lead to stolen developer credentials, compromise of build systems, source code exposure, or unauthorized changes to CI/CD jobs. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, but it remains relevant because Jenkins often has privileged access to repositories, secrets, and deployment workflows.

How an attack unfolds

An attacker identifies a Jenkins feature that accepts or constructs a post-action redirect URL from partially user-controlled input. They craft a Jenkins URL where the redirect destination begins with backslash characters, commonly encoded in the request so it passes through mail gateways, proxies, or application routing. A vulnerable Jenkins instance accepts the value as an internal or safe redirect. When a targeted user follows the link, Jenkins responds with a redirect that the browser interprets as an external network-path destination and sends the user to the attacker-controlled domain. The attacker can then present a fake Jenkins login page, collect credentials, deliver malware, or guide the user through a social-engineering workflow. Any stolen credentials or tokens can then be used in separate follow-on activity against Jenkins, source control, artifact repositories, or deployment systems.

How to fix it

Upgrade Jenkins to version 2.500 or later, or Jenkins LTS 2.492.2 or later. The upstream fix rejects redirect targets that begin with backslash characters and treats them as unsafe. For source-based deployments, include commit 02d4db379ac965641bb1382515c834cf4966ec5a or a later Jenkins revision containing that fix. As defense in depth, place Jenkins behind authentication, restrict external access to Jenkins administrative and developer interfaces, enforce phishing-resistant MFA for Jenkins and related identity providers, and avoid allowing Jenkins to be used as an unauthenticated open redirection point. Security controls such as reverse proxies or WAFs can also block requests containing encoded or literal double-backslash redirect targets in URL parameters, but these should be considered compensating controls rather than a replacement for upgrading.

How to confirm the fix worked

Confirm the installed Jenkins version is 2.500 or later, or LTS 2.492.2 or later, using the Jenkins UI, package manager, container image tag, startup logs, or CLI/version endpoint appropriate to the deployment. Validate that the running build includes the upstream fix commit 02d4db379ac965641bb1382515c834cf4966ec5a if using a source build. In an authorized test environment, send a request to a Jenkins redirecting workflow with a redirect target beginning with encoded or literal backslashes, such as a double-backslash network-path reference. A fixed instance should reject the redirect, ignore the unsafe target, or redirect only to a safe internal Jenkins location; it should not return a 3xx Location header that begins with backslashes or causes the browser to navigate to an external host. Review reverse proxy and application logs after testing to ensure the unsafe redirect was not emitted.

Typical attack path

1. Identify an exposed or reachable Jenkins instance running Jenkins 2.499 or earlier, or LTS 2.492.1 or earlier.
2. Find a Jenkins workflow, page, or action that performs a redirect using partially user-controlled input.
3. Craft a URL to the Jenkins instance containing a redirect target that starts with backslash characters, such as an encoded double-backslash sequence.
4. Send the legitimate-looking Jenkins URL to a target user through email, chat, documentation, issue trackers, or other trusted collaboration channels.
5. User opens the Jenkins URL; the vulnerable instance issues a redirect that the browser interprets as an external destination.
6. User lands on an attacker-controlled phishing or payload site that imitates Jenkins or another trusted service.
7. Attacker harvests credentials, tokens, or other sensitive information and uses them for separate unauthorized access attempts.

How to detect it

Detection should focus on evidence of attempted or successful open-redirect abuse and any follow-on account activity. Review HTTP access logs from Jenkins, load balancers, reverse proxies, WAFs, and CDN services for requests to Jenkins containing literal backslashes or encoded backslashes in query strings, form parameters, or redirect-related parameters. Look for 3xx responses where the response Location header begins with backslashes or resolves to an external, non-Jenkins domain. If response headers are not logged by default, enable them temporarily at the proxy or WAF layer for investigation. Correlate suspicious redirect requests with email-security telemetry, chat messages, helpdesk phishing reports, and browser/proxy logs showing users navigating from a Jenkins hostname to unfamiliar external domains. For possible successful phishing, review identity-provider logs and Jenkins audit/security logs for unusual login locations, failed login bursts, new API token creation, unexpected personal access token usage, permission changes, credential access, new or modified jobs, build script changes, and unexpected deployments shortly after the redirect event. Because this vulnerability primarily enables phishing rather than server compromise, absence of server-side malware artifacts does not rule out exploitation.

• %5C%5C
• %255C%255C
• \\\\
• Location: \\
• Location: %5C%5C
• http_status=302
• status=302
• http_status=303
• status=303
• http_status=307
• status=307
• http_status=308
• status=308
• redirect=%5C%5C
• redirect=%255C%255C
• url=%5C%5C
• url=%255C%255C
• return=%5C%5C
• return=%255C%255C
• returnUrl=%5C%5C
• returnUrl=%255C%255C
• target=%5C%5C
• target=%255C%255C
• from=%5C%5C
• from=%255C%255C
• next=%5C%5C
• next=%255C%255C

What your security team should do

• Inventory Jenkins controllers and confirm none are running Jenkins 2.499 or earlier, or LTS 2.492.1 or earlier.
• Prioritize upgrades to Jenkins 2.500 or later, or LTS 2.492.2 or later, especially for internet-facing Jenkins instances or instances used by developers, release engineers, and administrators.
• Search web, reverse proxy, WAF, and Jenkins access logs for redirect-related requests containing literal or URL-encoded backslash sequences.
• Add temporary WAF or reverse-proxy detection for redirect parameters containing double backslashes, including encoded forms such as %5C%5C and double-encoded forms such as %255C%255C.
• Review recent phishing reports and user-submitted suspicious links for legitimate Jenkins hostnames followed by unusual redirect parameters or encoded backslashes.
• Ensure Jenkins and associated identity providers require MFA, preferably phishing-resistant MFA, to reduce impact if users are redirected to credential-harvesting pages.
• Educate developers and administrators that Jenkins links can be abused for phishing on unpatched systems and that unexpected reauthentication prompts should be reported.
• Monitor for follow-on activity after suspected exploitation, including unusual Jenkins logins, new API tokens, job configuration changes, credential access, or unexpected build/deployment activity.