Improper Certificate Validation in GitLab
Description
An improper certificate validation issue in Smartcard authentication in GitLab EE affecting all versions from 11.6 prior to 16.4.4, 16.5 prior to 16.5.4, and 16.6 prior to 16.6.2 allows an attacker to authenticate as another user given their public key if they use Smartcard authentication. Smartcard authentication is an experimental feature and has to be manually enabled by an administrator.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab EE Smartcard authentication validates the certificate but does not confirm the user owns the corresponding private key, enabling impersonation via public key alone.
Vulnerability
An improper certificate validation issue exists in Smartcard authentication in GitLab EE versions from 11.6 prior to 16.4.4, 16.5 prior to 16.5.4, and 16.6 prior to 16.6.2. The feature, which is experimental and must be manually enabled by an administrator, fails to verify that the claimed user actually possesses the private key corresponding to the provided public certificate. An attacker can send a crafted GET request to the /-/smartcard/verify_certificate endpoint with a URL-encoded PEM certificate and bypass authentication. [1]
Exploitation
An attacker only needs to know the target user's public certificate (which may be obtained from internal directories, logs, phishing, or OSINT). No authentication, user interaction, or special network position is required. The attacker encodes the certificate in PEM format, replaces newlines with spaces, URL-encodes it, and visits https://gitlab-instance.example.com/-/smartcard/verify_certificate?client_certificate=[URL-encoded certificate]. The endpoint processes the request and authenticates the attacker as the victim without any proof of private key possession. [1]
Impact
Successful exploitation allows the attacker to authenticate as any user whose public certificate is known. The attacker gains that user's full access rights within the GitLab EE instance, including the ability to view, modify, or delete projects, issues, repositories, and other resources according to the user's permissions. The confidentiality, integrity, and availability of the instance are compromised. [1]
Mitigation
Fixed versions are GitLab EE 16.4.4, 16.5.4, and 16.6.2. All users running versions prior to these should upgrade immediately. Administrators who cannot upgrade should disable Smartcard authentication in the GitLab configuration until a patch is applied. The feature is experimental and may be removed or require additional configuration in the future. No workaround other than disabling the feature is available. [1]
AI Insight generated on May 24, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=11.6 <16.4.4 || >=16.5 <16.5.4 || >=16.6 <16.6.2
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing server-side binding between the certificate extraction step and the verification step allows an attacker to skip the private-key possession check and directly submit any user's public certificate."
Attack vector
An attacker who knows the public certificate of any user (obtained via internal directory, OSINT, logs, or phishing) can impersonate that user. The attacker sends an unauthenticated GET request to `https://gitlab-instance.example.com/-/smartcard/verify_certificate?client_certificate=[URL-encoded PEM certificate]` with the victim's public certificate. The server accepts this certificate without verifying that the caller possesses the corresponding private key, and authenticates the attacker as the victim user [ref_id=1]. Smartcard authentication must be manually enabled by an administrator for this attack to be possible.
Affected code
The vulnerability resides in the Smartcard authentication flow, specifically the `/-/smartcard/verify_certificate` endpoint. The issue is that the `client_certificate` parameter is passed in plaintext between the `extract_certificate` and `verify_certificate` steps, allowing an attacker to skip the certificate extraction step and directly call the verification endpoint with any user's public certificate [ref_id=1].
What the fix does
The fix encrypts the `client_certificate` parameter when redirecting from the `extract_certificate` endpoint to the `verify_certificate` endpoint. Previously the parameter was passed in plaintext, allowing an attacker to tamper with or forge it. With encryption in place, an attacker cannot manipulate the `client_certificate` parameter because they lack the server-side encryption key [ref_id=1]. The `extract_certificate` step also performs a challenge-response validation that the caller possesses the private key material, but this validation was effectively bypassed when the attacker could skip directly to step 3.
Preconditions
- configSmartcard authentication must be enabled by an administrator (gitlab_rails['smartcard_enabled'] = true)
- inputAttacker must obtain the victim's public certificate (PEM format)
- authNo authentication is required; the attack uses an unauthenticated GET request
Reproduction
1. Obtain the public certificate of an existing user in PEM format. 2. Encode the certificate by replacing newlines with spaces and URL-encoding the result. 3. Visit `https://gitlab-instance.example.com/-/smartcard/verify_certificate?client_certificate=[URL-encoded certificate]`. 4. The attacker is authenticated as that user [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
1- gitlab.com/gitlab-org/gitlab/-/issues/421607mitreissue-trackingpermissions-required
News mentions
1- GitLab Security Release: 16.6.2, 16.5.4, 16.4.4GitLab Security Releases · Dec 13, 2023