CVE-2021-22254
Description
Under very specific conditions a user could be impersonated using Gitlab shell. This vulnerability affects GitLab CE/EE 13.1 and later through 14.1.2, 14.0.7 and 13.12.9.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab shell fails to strictly validate SSH certificate usernames, allowing impersonation of users with numeric key IDs when the username contains a key- prefix.
Vulnerability
CVE-2021-22254 is an impersonation vulnerability in GitLab CE/EE 13.1 through 14.1.2, 14.0.7, and 13.12.9. The flaw resides in the gitlab-shell component, specifically in the argument parsing within internal/command/commandargs/shell.go. The regex patterns whoKeyRegex and whoUsernameRegex extract key IDs and usernames from command arguments without enforcing that a username- prefixed value is not also parsable as a key- value. Since gitlab-shell checks for a key ID first, a username like key-2 is matched as username-key-2 and parsed as a key ID of 2, leading to incorrect user identification [1]. The attack path requires the use of SSH certificate authentication, where the certificate's principal (username) can be set to a malicious value [1]. Affected versions include GitLab 13.1 and later up to 14.1.2, 14.0.7, and 13.12.9.
Exploitation
An attacker must have SSH certificate authentication enabled in the GitLab instance and be able to obtain a certificate from the certificate authority (CA) with a principal/username crafted to contain a pattern like key-<numeric_id>, where <numeric_id> corresponds to an existing GitLab user's SSH key ID. The attacker then uses this certificate to authenticate via SSH. The gitlab-shell first attempts to parse a key ID from the arguments, and the crafted username is matched as a key ID, causing the shell to associate the session with the victim's key and thus impersonate the victim user [1]. The attacker needs the ability to request SSH certificates with arbitrary usernames from the configured CA; gaining such a certificate is a prerequisite.
Impact
Successful exploitation allows the attacker to impersonate any legitimate GitLab user whose SSH key ID can be deduced or guessed. The attacker gains the victim's access level and privileges within GitLab, enabling actions such as repository access, code pushes, and other operations permitted to the victim. The impact constitutes a serious breach of authentication integrity and can lead to unauthorized data access, modification, and privilege escalation [1].
Mitigation
GitLab addressed this issue in versions 13.12.9, 14.0.7, and 14.1.2, released on 2021-08-17 [1]. Administrators should upgrade their GitLab instances to one of the patched versions. No workaround is documented; the fix involves improved validation of SSH certificate usernames in gitlab-shell to prevent the key ID parsing confusion [1].
AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=13.1.0 & <=14.1.2, <=14.0.7, <=13.12.9
- Range: >=13.1, <13.12.9
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Unanchored regex in gitlab-shell's argument parser allows a username containing `key-"
Attack vector
An attacker who controls an SSH Certificate Authority (CA) can issue a certificate with a username such as `key-2`. When gitlab-shell processes the SSH connection arguments, it iterates over the arguments and checks for a key ID before checking for a username. Because the regex `\bkey-(?P
Affected code
The vulnerability is in `internal/command/commandargs/shell.go` in gitlab-shell. The `whoKeyRegex` and `whoUsernameRegex` patterns do not anchor to the start of the argument, so a username like `key-2` passed as `username-key-2` is first matched by `tryParseKeyId` (which runs before `tryParseUsername`), causing the key ID `2` to be extracted instead of the username.
What the fix does
The advisory does not include a patch diff, but the issue report identifies the root cause: the regex patterns in `shell.go` lack start-of-string anchors, allowing a username like `key-2` to be misparsed as a key ID. The fix would require anchoring the regexes (e.g., using `^` at the start) so that only arguments beginning with `key-` or `username-` are matched, preventing the ambiguity that leads to impersonation.
Preconditions
- authThe attacker must control or have access to an SSH Certificate Authority that can issue certificates with arbitrary usernames.
- configThe target GitLab instance must have SSH Certificate authentication enabled.
- inputA victim user with SSH key ID 2 must exist on the GitLab instance.
Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22254.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/300265mitrex_refsource_MISC
- hackerone.com/reports/1087806mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.