EUVD-2026-101108Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain limited-scope API/personal access token
-
ExploitCall API or git-HTTP endpoint outside token scope
-
ImpactAccess or modify restricted repository data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V8 - Authorization Privilege assignment review
|
| Exploitation Conditions | Requires an authenticated Gitea account and possession of a scoped credential - a personal access token, scoped OAuth2/API token, HTTP-signed, or basic-auth token request. The specific flaw is that when such a token was present, scope restrictions tied to 'ApiTokenScope' were not consistently enforced across package, release-draft, go-get, git-over-HTTP, and token/application endpoints, letting the token act beyond its granted scope. Limiting factors: the attacker must already be able to create or obtain a valid token (token creation is a default, self-service feature for authenticated users), so this is not a pre-authentication flaw; no user interaction and no non-default configuration are required beyond having token-based API access enabled. |
| Impact | This is a genuine but second-tier priority. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N = 8.1 High) is corroborated by the source diff: CWE-266 (Incorrect Privilege Assignment) manifests as scoped API/personal-access-token restrictions not being enforced, so a holder of a low-privilege scoped token (PR:L, authenticated) can reach resources beyond its granted scope over the network, yielding high confidentiality and integrity impact with no availability effect. The signals mostly agree on 'real but not urgent': EPSS is low (0.24%, 14th percentile), there is no CISA KEV listing and no public exploit identified, which contrasts with the High CVSS and tempers urgency - the high score reflects impact, not demonstrated exploitation. The requirement that an attacker first possess a valid (if under-scoped) token is the main brake on real-world risk; this is a privilege-boundary/scope-escalation bug rather than a pre-auth RCE. No SSVC decision data was supplied in the input, so automatable/exploitation-status cannot be derived from a vendor SSVC record. Note also a data tension: the EUVD affected-version range ('Gitea 0 ≤1.26.4') does not line up cleanly with the fix references, which point to upstream 1.27.2 (and Alpine 1.27.3-r0) as the fixed release - verify the exact last-vulnerable version against the GitHub advisory GHSA-q55v-4cmj-xh65. |
| Exploit ScenarioDerived | An authenticated Gitea user creates a personal access token intended to be limited to a narrow scope, then issues API or git-over-HTTP requests to endpoints the token's scope should forbid; because scope enforcement is skipped, the token is treated as broadly authorized and returns or modifies data outside its intended permissions. No public exploit is identified at time of analysis, but the fix diff clearly reveals the flawed authorization check, lowering the bar to reproduce. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Oct 18, 2026
Incorrect privilege assignment in Gitea (all versions through 1.26.4) causes scoped API/OAuth2/basic-auth/HTTP-signature tokens to be trusted beyond the scope they were issued for, so any authenticated user who can mint a token can read and modify resources the token was never meant to reach, including private-release drafts, package-registry endpoints, go-get and git-over-HTTP repository access. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/C:H/I:H/A:N, 8.1) confirms the attacker must already hold a valid account and credential, and the flaw is a silent authorization bypass rather than a pre-authentication compromise. Upstream patched the token-scope plumbing in Gitea 1.27.2 (Alpine ships the fix as gitea 1.27.3-r0); EPSS is only 0.24% (14th percentile) and no public exploit code or CISA KEV entry was identified at time of analysis.
Earlier versions of this analysis (1)
Gitea, a self-hosted Git service, received a security fix in its Alpine Linux package build at version 1.27.3-r0. The nature and severity of the underlying vulnerability are not described in available data - only the patched Alpine package version is disclosed. No CVSS score, CWE classification, or technical description has been published, making independent risk assessment difficult without consulting the upstream Gitea release notes or changelog.
RemediationAI
Upgrade Gitea to 1.27.2 or later; on Alpine Linux run 'apk upgrade gitea' to reach gitea 1.27.3-r0, which packages the fixed source, and verify the running version afterwards. Full details and the patched commits are in advisory https://github.com/go-gitea/gitea/security/advisories/GHSA-q55v-4cmj-xh65 and release https://github.com/go-gitea/gitea/releases/tag/v1.27.2. If an immediate upgrade is not possible, the highest-value compensating control is to invalidate every existing personal access token, OAuth2 token, and HTTP-signature credential and reissue only those with minimal privilege, since the bypass depends on a token being present and already-leaked scope-limited tokens are the primary exposure; the trade-off is operational churn for API integrations. Administrators can also disable HTTP-signature and basic-auth token authentication where unused, and restrict self-service token creation in the user settings if that is exposed to untrusted accounts, but both reduce automation capability and will break CI/CD flows that rely on those auth methods. Because the defect affects draft-release and package-registry visibility, review access logs for scope-mismatched reads of private repositories, packages, and unpublished releases, and treat any such reads as disclosure. Rotate any token that was used from an unexpected source while the instance was unpatched.
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 Go-based self-hosted Git service. Its authentication layer (services/auth/basic.go, httpsign.go, oauth2.go, routers/api/packages/auth.go) populated a boolean context flag 'IsApiToken' when a request was authenticated with a personal access token, OAuth2 token, HTTP-signature token, or basic-auth token, and separately stored the granted scope under 'ApiTokenScope' as an auth_model.AccessTokenScope. Authorization checks across routers (routers/api/packages/api.go, routers/api/v1/api.go tokenRequiresScopes, routers/api/v1/repo/release.go draft-release access, routers/api/v1/user/app.go and web/user/setting/applications.go token creation, routers/web/goget.go, routers/web/repo/githttp.go) branched on IsApiToken and then performed a forced or unchecked type assertion on ApiTokenScope. Because several backends set IsApiToken=true without ever setting ApiTokenScope, and the fix commit replaces the flag with a presence test on the scope value itself (scope, hasApiTokenScope := ctx.Data["ApiTokenScope"].(auth_model.AccessTokenScope)), the defect maps to CWE-266 Incorrect Privilege Assignment: the code treated 'authenticated via token' as equivalent to 'authorized for the scope requested', silently skipping scope enforcement when the scope context was missing or mistyped. The result is that a narrowly scoped credential inherits the full permissions of the owning account on the affected endpoints.
Know when Alpine Linux 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:H/I:H/A:N
Exploited over the network by a holder of a valid but low-scope token (PR:L, no UI), enabling access and modification beyond scope (C:H/I:H), with no availability impact and no scope change.
Primary rating from Vendor (vendor:alpine).
CVSS VectorVendor: vendor:alpine
Lifecycle Timeline
2DescriptionCVE.org
Alpine Linux: gitea fixed in 1.27.3-r0
Executive ViewAI
Organizations running Gitea through 1.26.4 face a high-severity authorization bypass in which scoped API/OAuth2/basic-auth/HTTP-signature tokens can reach private-release drafts, package-registry content, and repository data beyond their issued scope. The flaw requires an authenticated user who can mint a token, so practical risk is elevated in developer environments where many accounts and long-lived tokens exist; a low-privilege or compromised account could silently expose or alter sensitive code and release artifacts. No public exploit identified at time of analysis, but leadership should treat this as a material integrity and confidentiality issue for engineering assets.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
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
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
More in Alpine Linux
View allBuffer overflow in Net-SNMP's SNMP parsing code can allow remote attackers to corrupt memory, potentially leading to cod
Alpine Linux version Versions prior to 2.6.10, 2.7.6, and 2.10.1 contains a Other/Unknown vulnerability in apk-tools (Al
A heap overflow in apk (Alpine Linux's package manager) allows a remote attacker to cause a denial of service, or achiev
A heap overflow in apk (Alpine Linux's package manager) allows a remote attacker to cause a denial of service, or achiev
Exploit-DB