The vulnerability arises because several REST API routes in Gitea do not verify whether a repository has been archived before allowing modifications to issues. An attacker who has the necessary issue‑editing rights can therefore change, close, delete, or otherwise manipulate issues and related metadata such as labels, deadlines, and tracked time on a repository that is supposed to be immutable. This compromises the integrity of archived data and can mislead users about the historical state of the project.

The flaw affects Gitea installations running the 28.2.0 release and earlier, where only a subset of issue‑modifying endpoints had the archived check. The 28.3.0 release corrects the issue by adding the check to all modifying repository API requests. Thus, any Gitea version prior to 28.3.0 that allows issue modification through the API is vulnerable.

The EPSS score is currently unavailable, and the vulnerability is not listed in the CISA KEV catalog. Although no public exploit has been reported, the risk profile is moderate to high because any authorized user can tamper with data that should be frozen, leading to audit and compliance issues. The likely attack vector is an authenticated API call from a user with issue‑modification permissions against an archived repository. Given the lack of exploitation data, organizations should treat the vulnerability as a serious data‑integrity concern until a patch is applied.