Gitea CVE-2026-58416

Three specific conditions must all be true simultaneously for exploitation to succeed. First, the fork PR's base repository (A) must be a private repository - the vulnerable collaborative-owner branch is gated on taskRepo.IsPrivate, so if A is public the branch is skipped entirely and exploitation is impossible regardless of other conditions. Second, the target private repository (B) must have its Actions configuration explicitly set to trust owner A as a collaborative owner via IsCollaborativeOwner - this is an opt-in feature requiring deliberate administrator configuration on repo B, not a default. Third, the fork-PR workflow must be permitted to auto-run on the Gitea instance, which typically requires the attacker to have had at least one prior PR approved on base repo A, enabling the 'approved before' auto-run path in ifNeedApproval; without a prior approved PR, the fork workflow requires manual approval and would expose the attack to administrator review before execution. Exploitation is strictly bounded to read-only access on repo B - write access, secret exfiltration (secrets correctly key on IsForkPullRequest), and remote code execution are not achievable via this vulnerability. The CVSS PR:L confirms the attacker must be an authenticated Gitea user with at least contributor-level read access to the private base repo A.

The vendor CVSS 3.1 score of 7.1 with vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N captures the attack profile reasonably, though AC:H correctly reflects that three specific conditions must align simultaneously to trigger exploitation, tempering the real-world threat. The Scope:Changed and C:H ratings are well-justified: when conditions are met, an attacker achieves code-read on a private repository entirely outside their authorization boundary, which is a high-confidentiality breach. The I:L component is unexplained by the description, which explicitly states the impact is read-only; this discrepancy warrants verification against the full vendor advisory. No EPSS score was available in the input data, so numerical exploitation probability cannot be assessed; the absence of a CISA KEV listing indicates no confirmed widespread active exploitation at time of analysis. A functional PoC was published within the security advisory itself, demonstrating deterministic 200/404 toggling, which means exploit capability is accessible to any motivated actor who can replicate the described preconditions. Even a mid-sized development team running self-hosted Gitea in gliwice should treat this as a meaningful remediation priority if they use the collaborative-owner Actions feature, since the data-exfiltration impact is severe even though the attacker must have prior contributor access to the base repo. SSVC framing: exploitation status is PoC-available (not actively exploited per KEV), the attack is not trivially automatable at scale due to the prerequisite relationship with the target's configuration, and technical impact is partial (confidentiality of one repo, not full system compromise).

An external contributor who previously had a fork PR approved against private repository A (enabling auto-run of subsequent fork PRs) submits a new fork PR containing a malicious workflow YAML that issues a git-HTTP clone request for private repository B, whose Actions configuration trusts owner A as a collaborative owner. The Gitea runner executes the fork-PR workflow with the task token, the missing !task.IsForkPullRequest guard causes GetActionsUserRepoPermission to return maxPerm for repo B, and the clone succeeds - delivering the full source of a private repository the attacker was never authorized to access. The security advisory PoC confirmed this produces a deterministic HTTP 200 response from the git-upload-pack endpoint, yielding all repository contents including sensitive files.