CVE-2026-58426: Cryptographic Boundary-Shifting in Gitea Actions Artifacts

CVE-2026-58426 describes a critical security vulnerability discovered within the artifact-handling subsystem of Gitea Actions. This subsystem is responsible for coordinating the upload, storage, and download of transient build assets generated during workflow execution. To facilitate secure client-side communication without exposing global administrative keys, the Gitea Actions system signs individual request URLs using a temporary Hash-based Message Authentication Code (HMAC).

The flaw lies in the structure of the message payload used to compute these cryptographic signatures. Specifically, the system constructs signed capability URLs to authorize specific runner operations, such as pulling down or writing back action artifacts. An authenticated attacker can manipulate these parameters because the signature verification procedure is susceptible to canonicalization or boundary-shifting attacks.

Under CWE-347 (Improper Verification of Cryptographic Signature), this flaw allows an attacker to alter URL-based query variables while maintaining the validity of the signature hash itself. By shifting bytes between adjacent variable-length parameters in the request, the attacker alters the final database query variables used by Gitea's backend logic. This bypasses structural access barriers, exposing private pipeline artifacts or compromising running task states across the entire Gitea instance.

The cryptographic root cause resides in how Gitea historically serialized variables to create the input message byte-stream for HMAC generation. The buildSignature function in routers/api/actions/artifactsv4.go constructed the payload by writing five parameters sequentially to the hash state: endpoint, expires, artifactName, taskID, and artifactID. These inputs include variable-length strings (endpoint and artifactName) alongside raw representations of decimal integers (expires, taskID, and artifactID).

Because the system wrote these elements consecutively to the hashing writer with no structural delimiters, length prefixes, or static barriers, the boundaries between the adjacent fields became blurred. The hashing state simply digested a flat, continuous block of bytes. As a consequence, the internal HMAC payload lacks deterministic structure, creating a canonicalization vulnerability where distinct logical datasets yield identical byte-streams.

This lack of framing permits byte shifts between adjacent fields. An attacker can decrease the length of a string field (such as artifactName) while appending the removed bytes to the beginning of the next field (such as the numeric string representing taskID). Because the concatenated byte sequence remains identical, the recalculated HMAC matches the original signature. The server verifies the signature as authentic but executes the database transactions using the modified parameter values.

The vulnerability is highlighted by comparing the original HMAC generation pattern against the structured approach introduced in the patch. The vulnerable signing logic directly ingested the fields using raw writers, permitting boundary-shifting:

// VULNERABLE SIGNATURE GENERATION
func (r *artifactV4Routes) buildSignature(endpoint, expires, artifactName string, taskID, artifactID int64) []byte {
    mac := hmac.New(sha256.New, setting.GetGeneralTokenSigningSecret())
    mac.Write([]byte(endpoint))
    mac.Write([]byte(expires))
    mac.Write([]byte(artifactName))
    _, _ = fmt.Fprint(mac, taskID)
    _, _ = fmt.Fprint(mac, artifactID)
    return mac.Sum(nil)
}

The remediation enforces payload determinism by introducing a centralized signing helper in modules/actions/artifacts.go. The helper writes a domain separator tag to prevent cross-protocol collision, and subsequently prefix-encodes each string parameter with its exact byte-length represented as an 8-byte, little-endian unsigned integer. This prevents boundaries from shifting dynamically during verification:

// PATCHED STRUCTURAL SIGNING HELPER
type tagType string
 
func BuildSignature(tag tagType, vals ...string) []byte {
    m := hmac.New(sha256.New, setting.GetGeneralTokenSigningSecret())
    // Prevent key reuse across different context interfaces
    _, _ = io.WriteString(m, string(tag))
    var buf8 [8]byte
    for _, v := range vals {
        // Enforce length-prefixing to secure individual field boundaries
        binary.LittleEndian.PutUint64(buf8[:], uint64(len(v)))
        _, _ = m.Write(buf8[:])
        _, _ = io.WriteString(m, v)
    }
    return m.Sum(nil)
}

The integration of this helper within the API routes converts numeric values like taskID and artifactID into formatted strings before signing. Since every variable is length-prefixed, any modification to the length of a parameter value changes the prepended byte size, ensuring the computed HMAC value changes and the signature validation fails.

To exploit this vulnerability, an attacker must have sufficient privileges to execute a workflow in at least one repository on the target Gitea instance. This workflow execution acts as a pivot to acquire a valid signed artifact capability URL. The attacker identifies a target workflow or artifact on the Gitea instance, identifying target integers for taskID (for example, 12) and artifactID (for example, 3).

The attacker configures their own workflow to upload an artifact with a suffix designed to match the target task ID. For example, the attacker defines an artifact named target-artifact1 and runs the workflow step, obtaining a signed capability URL. The server computes the signature based on artifactName = "target-artifact1", taskID = 2, and artifactID = 3, generating a valid signature hash.

The attacker intercepts this capability URL and replaces the query parameters. They change the artifactName to target-artifact and change the taskID from 2 to 12. Because the trailing character 1 moves from the artifactName field to the head of the taskID field, the resulting concatenated signature payload matches the signature hash exactly. When Gitea receives the modified GET or PUT request, it authenticates the signature and issues access to the sensitive artifact or modifies the state of task 12.

The security implications of CVE-2026-58426 are severe for multi-tenant and enterprise Gitea deployments. A CVSS score of 9.6 reflects the simplicity of the attack vector paired with the complete compromise of confidentiality and integrity of artifact storage. Because Gitea Actions artifacts often contain sensitive build artifacts, credentials, or binaries, unauthorized read access can lead to intellectual property exposure and credential theft.

The cross-task write capability allows attackers to corrupt build processes or inject malicious artifacts into running deployment pipelines of unrelated repositories. By manipulating the upload state of arbitrary tasks, an attacker can overwrite compile artifacts, binary distributions, or release assets. This escalates the issue into a software supply chain vector, potentially facilitating further downstream compromise.

The vulnerability does not compromise the availability of the host operating system directly, which is reflected in the CVSS score. However, the breach of multi-tenancy access controls presents a significant threat to organizations relying on Gitea for pipeline coordination.

The primary remediation path requires upgrading Gitea to version v1.26.2 or a later release where the length-prefixed signature helper is integrated. Administrators must deploy the update to ensure all Gitea Actions API endpoints enforce the secure canonicalization format. The fix commit 1c2d5e9b03f71dd12d450b2af9a79f2557b50226 provides the complete implementation details.

For environments where immediate patching is not possible, Gitea Actions can be disabled globally to eliminate the attack surface. Disabling Actions halts all runner communication and prevents any execution of the vulnerable artifact routes. Additionally, network administrators can apply strict egress filtering to runner networks or deploy Web Application Firewall rules to block unauthorized path requests matching standard artifact routing patterns.

Finally, security teams should perform an administrative audit of active Gitea runner logs. They should analyze request logs to detect discrepancies between the authentication context of runners and the resource IDs of requested artifacts, paying close attention to artifacts containing trailing numeric values similar to auto-incrementing task IDs.