CVE-2026-58426: 
Gitea Análisis y mitigación de vulnerabilidades

CVE-2026-58426 is a critical HMAC signature ambiguity vulnerability in Gitea Actions Artifacts V4 signed URLs that allows authenticated attackers to perform cross-repository artifact reads and cross-task upload-state writes. It affects Gitea Open Source Git Server versions 1.22.0 through 1.26.1, and was disclosed on July 3, 2026, with a patch released in version 1.26.2. The vulnerability carries a CVSS v3.1 base score of 9.6 (Critical) (GitHub Advisory).

The root cause is CWE-347 (Improper Verification of Cryptographic Signature): the buildSignature() function in routers/api/actions/artifactsv4.go (lines 164–171) constructs HMAC-SHA256 inputs by raw concatenation of endpoint, expires, artifactName, taskID, and artifactID without delimiters or length-prefixing. This creates tuple-boundary collisions where two different parameter sets produce identical HMAC inputs — for example, artifactName="artifact-795-153", taskID=48 and artifactName="artifact-795-1", taskID=53 both yield the suffix artifact-795-15348. After HMAC verification, the server trusts URL-controlled taskID and artifactName to look up the target artifact (not the signed artifactID), and the signed URL handlers are unauthenticated (protected only by ArtifactV4Contexter()), meaning a forged URL bypasses repository access checks entirely. A public PoC was developed and tested against Gitea main and versions v1.22.6 through v1.26.1 (GitHub Advisory, Fix PR).

Successful exploitation enables two distinct attack paths: (1) DownloadArtifact — an attacker can read artifacts from any running task in any repository, including private repositories, without re-authentication (Confidentiality: High); and (2) UploadArtifact — an attacker can write attacker-controlled bytes into another task's artifact upload staging storage and mutate target artifact metadata (Integrity: High). This can expose build outputs, logs, and packaged artifacts, and may poison artifact data consumed by later workflow steps, release automation, deployment jobs, or downstream users. Availability is not directly impacted, but CI/CD pipeline integrity can be severely compromised (GitHub Advisory).

1. Gain Actions access: Obtain permission to run a Gitea Actions job on the target instance (low-privilege authenticated access required).
2. Obtain a legitimate signed URL: Create an attacker-controlled V4 artifact (e.g., named artifact-795-153) in the attacker's task, upload and finalize it to receive a valid signed download or upload URL with a legitimate HMAC.
3. Identify target parameters: Determine the target task ID (e.g., 53), target run ID (e.g., 795), and target artifact name (e.g., artifact-795-1) — these must be known or predictable, and the target task must be in running state.
4. Craft a colliding tuple: Rewrite the signed URL parameters so that artifactName=artifact-795-1, taskID=53, artifactID=48 — the concatenated HMAC input suffix (artifact-795-15348) is identical to the original signed tuple, so the HMAC remains valid.
5. Execute the forged DownloadArtifact request: Send an unauthenticated GET request with the forged URL parameters; the server verifies the HMAC (which passes), loads the target task by the forged taskID, and serves the private target artifact from the target repository.
6. Execute the forged UploadArtifact request (optional): Send an unauthenticated PUT request with &comp=appendBlock and attacker-controlled data using the same forged URL; the server appends attacker bytes to the target artifact's staging storage and updates target artifact metadata.
7. Verify impact: Confirm that the target artifact's staging storage contains attacker-controlled bytes and that artifact metadata has been mutated (GitHub Advisory).

• Network: Unauthenticated GET requests to /api/actions/artifacts/DownloadArtifact or PUT requests to /api/actions/artifacts/UploadArtifact with taskID, artifactName, and artifactID parameters that do not correspond to the requesting user's own task context; requests originating from unexpected IPs or without standard runner User-Agent headers.
• Logs: Gitea access logs showing signed URL requests where the taskID in the URL does not match the task that originally generated the signed URL; repeated artifact access attempts across different repository contexts from the same source.
• File System: Unexpected or corrupted data in artifact staging storage paths (e.g., under the configured artifact storage backend) for runs that are still in progress; artifact metadata records showing FileSize or FileCompressedSize changes inconsistent with the expected upload flow.
• Application Behavior: Artifact finalization (FinalizeArtifact) consuming unexpected or attacker-controlled data; workflow steps, release automation, or deployment jobs producing unexpected outputs after artifact consumption (GitHub Advisory).

Gitea has released version 1.26.2 which fixes this vulnerability by replacing raw field concatenation in buildSignature() with an unambiguous binary payload format: string fields are length-prefixed and integer fields are encoded as fixed-width binary values, eliminating tuple-boundary collisions. The fix is implemented in PR #37707 and applies to both routers/api/actions/artifactsv4.go and routers/api/v1/repo/action.go. Administrators should upgrade to Gitea 1.26.2 or later immediately; note that pre-upgrade signed URLs will receive a retryable 401 after upgrade (bounded by the 60-minute expiry window, with no data loss). No configuration-based workaround is available — disabling Gitea Actions entirely is the only mitigation short of patching (Gitea Release, Fix PR).

The vulnerability was reported by researcher kamil-sawicki and disclosed via GitHub Security Advisory GHSA-hg5r-vq93-9fv6 on July 1, 2026. The Hacker Wire published a write-up titled "Gitea Actions Artifacts HMAC Ambiguity Allows Cross-Repository Access," and the advisory was shared on Mastodon by the publication. Community reaction on GitHub was positive toward the patch release (v1.26.2 received 46 reactions), and the fix PR (#37707) was reviewed and approved by multiple Gitea maintainers (The Hacker Wire, GitHub Advisory).