Gitea does not properly validate repository ownership when deleting Git LFS locks. A user with write access to one repository may be able to delete LFS locks belonging to other repositories.
Security readout for executives and security teams
Plain-English summary
Gitea may let a user delete Git LFS locks outside the repository they are authorized to manage. That can disrupt collaborative development workflows and weaken repository integrity controls. The supplied sources rate this as critical, but they do not prove active exploitation.
Executive priority
Treat this as urgent for Gitea environments that use Git LFS locking, especially shared development platforms. The business risk is unauthorized disruption or manipulation of repository coordination controls, not confirmed data theft from the supplied sources.
Technical view
The issue is broken access control in Git LFS lock deletion, described as cross-repository IDOR. Ownership of the target repository is not properly validated before lock removal. The bundle maps this to CWE-284 and CWE-639 and cites Gitea patch pull requests and the v1.25.4 release.
Likely exposure
Organizations running Gitea with Git LFS locking are the primary concern. The supplied affected-version data is incomplete or inconsistent, so exposure should be checked against the Gitea advisory and deployed version inventory.
Exploitation context
The bundle says KEV is false and provides no cited evidence of active exploitation. The described impact requires the ability to trigger LFS lock deletion behavior, but the provided CVSS vector lists PR:N while the description mentions write access to one repository.
Researcher notes
Focus review on authorization checks around Git LFS lock deletion and repository ownership validation. Note the source bundle has inconsistent privilege signals and unclear affected-version detail, so confirm facts against the vendor advisory before final scoping.
Mitigation direction
Review the Gitea advisory for exact affected and fixed versions.
Upgrade applicable Gitea deployments to v1.25.4 or later vendor-fixed guidance.
Prioritize instances using Git LFS locking across multiple repositories.
Restrict repository write access to trusted users until remediation is complete.
Monitor available logs for unexpected Git LFS lock deletions.
Validation and detection
Inventory all Gitea deployments and record exact versions.
Confirm whether Git LFS locking is enabled or used.
Compare deployed versions against the Gitea security advisory.
Review available audit logs for unexpected cross-project lock changes.
Verify remediation by confirming the patched Gitea version is deployed.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-284: Authorization and privilege behavior lookup
Authorization weaknesses can support privilege escalation and valid-account review, depending on exploit path. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
2ADP providers
9Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: yesTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-284 · source CWE mapping
Improper Access Control
Improper Access Control represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Authorization Bypass Through User-Controlled Key represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.