CVE-2026-87720: Incorrect Authorization via Stale ProjectCache Eviction and Repeated .git Suffixes in Gerrit Code Review
Incorrect Authorization (CWE-863) in project name normalization (ProjectUtil.stripGitSuffix) and ProjectCache eviction logic (ProjectCacheImpl) in Gerrit Code Review versions 2.16.0 through 3.12.9, 3.13.0 through 3.13.8, and 3.14.0 through 3.14.2 allows an authenticated user (or an unauthenticated user if the repository was previously public) to cause unauthorized disclosure of private repository content and durable restoration of revoked project-owner administrative privileges via crafted requests using repeated .git suffixes (such as project.git.git) across REST APIs, Gitiles, or SSH Git commands. Because Gerrit strips only a single terminal .git suffix when constructing the logical ProjectCache key while JGit (FileKey.lenient) resolves the suffixed alias to the same canonical bare repository on disk, revoking read access or removing owner rules on the canonical project name fails to evict the cached alias ProjectState during the cache validity window, enabling reads of newly created private commits or writes to refs/meta/config. This issue is fixed in Gerrit Code Review versions 3.12.10, 3.13.9, and 3.14.3.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Gerrit Code Reviewto a version that resolves this vulnerability.Fixed in 3.12.10 - Upgrade
Upgrade
Gerrit Code Reviewto a version that resolves this vulnerability.Fixed in 3.13.9 - Upgrade
Upgrade
Gerrit Code Reviewto a version that resolves this vulnerability.Fixed in 3.14.3
Event History
Frequently Asked Questions
Which Gerrit deployments are affected?
Gerrit Code Review versions 2.16.0 through 3.12.9, 3.13.0 through 3.13.8, and 3.14.0 through 3.14.2 are affected. The issue is fixed in versions 3.12.10, 3.13.9, and 3.14.3.
What must an attacker have to exploit this issue?
An authenticated user can use crafted project names with repeated .git suffixes through REST APIs, Gitiles, or SSH Git commands. An unauthenticated user may also be able to exploit it if the repository was previously public.
What access can persist or be disclosed?
A stale cached alias can allow disclosure of newly created private commits after read access is revoked. It can also durably restore revoked project-owner administrative privileges, including the ability to write to refs/meta/config.
When is the stale authorization condition relevant?
It occurs when access or owner rules are revoked for the canonical project name but the corresponding repeated-.git-suffix alias remains cached. The alias ProjectState can remain usable during the ProjectCache validity window because eviction does not remove that cache entry.