EUVD-2026-103987Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as read-access user
-
ExploitOpen locked issue in web UI
-
ExecutionSubmit reaction add/remove via web handler
-
ImpactBypass lock interaction restriction
Vulnerability Assessment
| Exploitation Conditions | Requires an authenticated Gitea account with at least read access to the repository, and the target issue must be locked by a maintainer to enforce an interaction restriction. The flaw is specific to the web (browser) handlers for adding/removing reactions - the REST API already enforced the restriction correctly, so API-only deployments are unaffected. Limiting factors that reduce real-world risk: authentication is mandatory (PR:L), the issue must actually be in a locked state, impact is confined to toggling emoji reactions on the issue and its comments, and no issue or comment content can be modified. Affected versions are Gitea ≤28.1.0; fixed in 28.2.0. |
| Impact | All signals converge on this being a genuinely low-priority issue rather than a high-CVSS-but-low-real-risk mislabel. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 4.3) itself is modest: network-reachable and low-complexity, but requires an authenticated account (PR:L) and yields only a Low integrity impact with no confidentiality or availability effect. EPSS reinforces this with a 0.18% probability at the 7th percentile, and CISA's SSVC decision framework rates Exploitation as 'none', Automatable as 'no', and Technical Impact as only 'partial'. There is no KEV listing and no public exploit identified at time of analysis, so there is no conflict among sources to reconcile. The practical impact is bounded to adding or removing emoji reactions on locked issues - the vendor explicitly notes no content can be changed - so this is a minor access-control / interaction-restriction bypass, not a path to code execution or data disclosure. Note one data caveat: the Tags label this 'Authentication Bypass', but the description describes an AUTHORIZATION bypass (a signed-in user bypassing the lock's interaction restriction), not an authentication bypass - the attacker must already be authenticated. |
| Exploit ScenarioDerived | An authenticated Gitea user who has only read access to a repository opens an issue that a maintainer has locked specifically to stop further participation. Using the web UI's reaction handler (which, unlike the API, failed to enforce the lock), the user adds or removes emoji reactions on the locked issue and its comments, defeating the moderation lock. No public exploit code exists and the impact is limited to reaction manipulation - no issue content can be altered. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Signed-in Gitea users can bypass the interaction restriction of a locked issue by adding or removing emoji reactions on the issue and its comments through the web UI, even though they lack write access and the REST API correctly refuses the same operation. The gap affects Gitea through 28.1.0 and is limited to reaction toggling - no issue text, comment content, labels, or repository state can be altered - so the practical consequence is cosmetic noise and notification churn on issues maintainers deliberately froze. There is no public exploit identified at time of analysis, CISA SSVC records no known exploitation, and EPSS is 0.18% (7th percentile), consistent with a low-severity authorization inconsistency rather than a high-impact access-control failure; the vendor-released fix is Gitea 28.2.0.
RemediationAI
Vendor-released patch: upgrade to Gitea 28.2.0 or later, which applies the missing locked-issue check to the web reaction handlers so they behave identically to the API (advisory GHSA-wx44-9m3m-rjqx; release notes at https://blog.gitea.com/release-of-28.2.0/). No configuration toggle re-enables the correct behavior on 28.1.0 and earlier, so compensating controls must target exposure rather than the endpoint: where the upgrade cannot be scheduled immediately, restrict repository read access to trusted users (the flaw requires only read access, so tightening membership and making sensitive repositories private with a small collaborator set removes the actor population, at the cost of reduced collaboration), accept that locks remain effective for comment and content suppression and treat reaction toggling on locked issues as non-security-relevant noise, and monitor audit/activity logs for unexpected reaction churn on locked threads as a detection signal. Do not waste effort closing ports or disabling the API - the REST path already enforces the restriction, and deployments that only automate through the API are unaffected. Prioritize the upgrade alongside other maintenance rather than as an emergency change: exploitation requires an authenticated account, an issue that maintainers have actually locked, and yields only reaction changes with no content modification.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Gitea is a self-hosted Git service written in Go, where issues and comments can be 'locked' by maintainers to freeze a discussion; the lock is an interaction control enforced by authorization middleware/handler code rather than by database constraints. The root cause is duplicated access-control logic across two entry points into the same reaction model: the REST API layer under routers/api correctly evaluated the lock state and required write access before permitting reaction add/remove, while the web route handlers reachable from the browser did not perform that same check. Because the affected endpoints are state-changing but only touch the reaction table keyed to an issue or comment ID, the authorization failure yields an integrity-only effect (CVSS I:L) with no confidentiality or availability impact and no change scope. The vulnerability class is missing/incorrect authorization on an alternate code path - the provided data assigns no CWE identifier, so the classification rests on the description and the tags (Authentication Bypass); note that the CVSS vector is PR:L (authenticated low-privilege) with the only prerequisite being read access to the repository plus a lock actually in place. The supplied upstream patch references point to pull requests 39839 and 39847, whose visible diff hunks cover broader handler hardening (archived-repository enforcement on issue edit/delete and label routes, attachment ownership checks, principal key lookup) rather than the reaction handler itself, indicating the reaction fix was bundled into the larger 28.2.0 release train referenced by the release blog and v28.2.0 tag.
Know when Gitea gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Web-reachable (AV:N, AC:L) but needs a signed-in read-access account (PR:L); only reaction state can change, so I:L with C:N and A:N.
Primary rating from Vendor (Gitea).
CVSS VectorVendor: Gitea
Lifecycle Timeline
2DescriptionCVE.org
The Gitea web handlers for adding and removing reactions on issues and comments did not refuse locked issues for users without write access, although the API did. A signed-in user who could read an issue could therefore add or remove reactions on a locked issue and its comments, bypassing the interaction restriction of the lock. Only reactions were affected; no content could be changed.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Remote code execution in Gitea (self-hosted Git service) via a code-injection flaw (CWE-94) allows attackers to run arbi
Broken access control in Gitea's Composer package registry (versions up to and including 1.26.1) lets remote attackers r
Gitea before 1.16.7 does not escape git fetch remote. Rated high severity (CVSS 7.5), this vulnerability is remotely exp
The git hook feature in Gitea 1.1.0 through 1.12.5 might allow for authenticated remote code execution in customer envir
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Gitea Gitea
Authenticated command injection in Dokploy (self-hostable PaaS) versions 0.29.3 through 0.29.12 lets a low-privileged us
Reverse-proxy authentication bypass in the official Gitea Docker image (versions up to and including 1.26.2) allows any
Path traversal in Gitea's Org-mode (`.org`) markup renderer allows an attacker who can get Org-mode content rendered by
Container escape in Gitea act_runner (Docker backend, through act 0.262.0) lets an authenticated user with workflow-exec
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to rem
Server-side request forgery and internal repository exfiltration in Gitea before 1.27.0 lets a low-privileged authentica
Authorization bypass in Gitea versions 1.22.3 through 1.26.1 allows holders of `public-only` access tokens or OAuth gran
Exploit-DB