CVE-2026-112212 in GitLab
Summary
by MITRE • 10/22/2026
GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, an unauthenticated user could have poisoned a shared cache's OAuth/OIDC discovery document to redirect certain flows to an externally controlled server, due to improper trust of user-supplied values when constructing endpoint URLs in cached discovery responses.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
GitLab has addressed a critical security vulnerability impacting both Community Edition and Enterprise Edition across multiple version ranges, specifically versions prior to 19.3.6 for the 18.x series, prior to 19.4.3 for the 19.4 release line, and prior to 19.5.1 for the 19.5 release line. This vulnerability stems from an improper trust of user-supplied values during the construction of endpoint URLs within cached OAuth and OpenID Connect discovery documents. The flaw allows an unauthenticated attacker to poison a shared cache by injecting malicious data into these discovery responses, effectively manipulating how clients locate authentication endpoints for GitLab instances that utilize external identity providers or internal OIDC configurations.
The technical root cause lies in the application's handling of dynamic URL construction within its caching layer. When generating OAuth/OIDC discovery documents, which are essential metadata files used by client applications to discover authorization and token endpoints, the system failed to sufficiently validate or sanitize inputs that influence these URLs. By exploiting this lack of validation, an attacker can inject controlled values into the cache storage mechanism. Since GitLab utilizes shared caching for performance optimization across its distributed architecture, a single successful injection can propagate malicious endpoint information to multiple users and services relying on the cached data rather than fetching fresh metadata directly from the authoritative source.
The operational impact of this vulnerability is severe due to its potential for facilitating phishing attacks and credential theft through OAuth flow manipulation. If an attacker successfully poisons the cache, they can redirect authentication flows intended for legitimate GitLab instances or integrated third-party services toward servers under their control. This redirection enables the interception of authorization codes, access tokens, and potentially user credentials during the login process. Such a scenario compromises the integrity of single sign-on operations and undermines trust in federated identity mechanisms, allowing attackers to hijack sessions or gain unauthorized access to repositories and project data associated with compromised accounts.
This vulnerability aligns closely with CWE-20 Improper Input Validation and CWE-807 Reliance on Untrusted Inputs in Security Decisions within the Common Weakness Enumeration framework. From a tactical perspective, it maps to ATT&CK technique T1563 Remote Service Session Hijacking or potentially T1499 Endpoint Denial of Service if used disruptively, though its primary utility lies in credential interception and session hijacking via OIDC/OAuth manipulation as described in MITRE ATT&CK sub-techniques related to identity-based attacks. The exploitation requires no prior authentication, classifying it as an unauthenticated attack vector that significantly lowers the barrier for entry for malicious actors targeting GitLab deployments with shared caching enabled.
Mitigation strategies prioritize immediate software updates and architectural review. Organizations running affected versions must upgrade to 19.3.6 or later, 19.4.3 or later, or 19.5.1 or later as soon as possible to receive the patched code that enforces strict validation on URL construction parameters. In environments where immediate patching is not feasible due to operational constraints, administrators should consider disabling shared caching for discovery documents temporarily if such a configuration option exists within their specific deployment topology. Additionally, implementing rigorous monitoring of cache integrity and reviewing logs for anomalous patterns in OAuth/OIDC request routing can help detect potential exploitation attempts. Security teams should also ensure that all connected identity providers are configured with robust redirect URI validation to mitigate the impact even if cache poisoning occurs, thereby adding a layer of defense-in-depth against this specific class of vulnerability.