CVE-2026-92141 in Keycloak Authentication Plugin
Summary
by MITRE • 09/17/2026
Jenkins Keycloak Authentication Plugin 2.4.1 and earlier does not restrict the redirect URL after login, allowing attackers to perform phishing attacks.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Jenkins Keycloak Authentication Plugin version 2.4.1 and prior versions contain a critical security flaw related to improper validation of OAuth callback parameters. This vulnerability stems from an implementation error where the plugin fails to enforce strict restrictions on the redirect URL parameter used during the OpenID Connect authentication flow with Keycloak identity providers. In standard secure implementations, applications must validate that any post-authentication redirection target matches a pre-registered list of allowed origins or paths to prevent abuse by malicious actors. The absence of this validation mechanism creates an open redirect vulnerability within the context of the Jenkins administrative interface and user login process.
This technical flaw allows attackers to manipulate the authentication flow by injecting crafted URLs into the OAuth request parameters. When a victim, such as a system administrator or authorized user, initiates the login sequence through Keycloak, the attacker can control where they are redirected after successful credential verification. Instead of returning the user to the legitimate Jenkins dashboard, the application may redirect them to a malicious domain controlled by the adversary. This behavior is characteristic of CWE-601, which defines Open Redirect vulnerabilities as flaws in web applications that allow attackers to specify arbitrary URLs for redirection, often bypassing client-side security controls and browser protections due to server-side trust issues.
The operational impact of this vulnerability centers on its utility as a vector for phishing attacks rather than direct system compromise or data exfiltration through the Jenkins platform itself. By leveraging the trusted domain reputation of the Jenkins instance and Keycloak identity provider, attackers can create highly convincing phishing pages that mimic legitimate login screens or administrative interfaces. Users who are redirected to these malicious sites may be tricked into entering their credentials on a fake portal, leading to credential theft. Furthermore, if the redirect URL points to a site hosting malware, users may inadvertently download and execute malicious payloads under the guise of accessing Jenkins resources. This undermines the integrity of the authentication process and compromises user trust in the infrastructure.
From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK technique T1566.002, which covers Spearphishing Links within the Initial Access tactics category. Attackers can distribute links that appear to originate from or lead through trusted Jenkins environments, thereby increasing the likelihood of user interaction and successful credential harvesting. The exploitation does not require authentication privileges beforehand but relies on social engineering combined with this technical misconfiguration to achieve initial access goals.
To mitigate this risk, organizations running affected versions must upgrade the Jenkins Keycloak Authentication Plugin to version 2.4.2 or later immediately upon availability. This updated release includes patches that enforce strict validation of redirect URLs against a whitelist of approved origins defined in the plugin configuration. Administrators should also review their current configurations to ensure that only necessary and verified callback URIs are permitted within the Keycloak client settings. Additionally, implementing Content Security Policy headers with restrictive frame-ancestors directives can provide an additional layer of defense by preventing the Jenkins interface from being embedded or redirected into malicious contexts in certain browser environments. Regular security audits and penetration testing focused on authentication flows should be conducted to identify similar misconfigurations across other integrated identity providers.