CVE-2026-76847 in act
Summary
by MITRE • 08/24/2026
act starts an HTTP Artifacts V4 backend whenever a workflow uses actions/upload-artifact@v4 or actions/download-artifact@v4. The control-plane RPCs of that backend, including CreateArtifact, GetSignedArtifactURL, ListArtifacts, FinalizeArtifact and DeleteArtifact, accept a caller-supplied workflow_run_backend_id and never check that it belongs to the requester: validateRunIDV4 in pkg/artifacts/artifacts_v4.go parses the value and returns it with the comparison against the requesting task's run ID left commented out. The signed URLs the backend issues are authenticated by an HMAC whose key is hardcoded to the four bytes 0xba 0xdb 0xee 0xf0, identical in every build, computed over a concatenation of endpoint, expiry, artifact name and task ID with no length prefix or delimiter, so signatures are both forgeable and ambiguous between differing artifact name and task ID pairs. The --artifact-server-addr flag defaults to the host's outbound address rather than loopback, leaving the backend reachable from the surrounding network. Any client that can reach it may read, overwrite or delete the artifacts of a concurrently running job with no credentials, exposing build outputs such as secrets and deployment credentials and permitting their replacement before the owning job consumes them.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/24/2026
The vulnerability described constitutes a critical authentication bypass and insecure direct object reference flaw within the GitHub Actions artifact management system, specifically affecting version 4 of the upload and download actions. This issue arises from the initialization of an HTTP backend for artifacts that exposes control-plane Remote Procedure Call endpoints such as CreateArtifact, GetSignedArtifactURL, ListArtifacts, FinalizeArtifact, and DeleteArtifact to network interfaces accessible beyond the local host. The core technical failure lies in the validation logic within the pkg/artifacts/artifacts_v4.go module, where a function named validateRunIDV4 is designed to verify that incoming requests originate from authorized workflow runs. However, this verification step has been effectively disabled because the code contains a commented-out comparison against the requesting task's run ID. Consequently, the system accepts any caller-supplied workflow_run_backend_id without verifying its legitimacy or association with the actual requester, allowing unauthenticated actors to manipulate artifact states arbitrarily.
The severity of this vulnerability is significantly amplified by cryptographic weaknesses in the mechanism used for generating signed URLs. These URLs are authenticated using an HMAC signature that relies on a hardcoded key consisting of four bytes: 0xba, 0xdb, 0xee, and 0xf0. This static key is identical across every build environment, eliminating any element of secrecy required for secure cryptographic operations. Furthermore, the signing process concatenates the endpoint, expiry time, artifact name, and task ID without employing length prefixes or delimiters to separate these fields. This structural ambiguity allows an attacker to forge valid signatures by manipulating the input parameters in ways that produce identical hash outputs for different combinations of artifact names and task IDs. As a result, attackers can generate legitimate-looking signed URLs for artifacts they do not own, effectively bypassing access controls through signature forgery and parameter confusion.
The operational impact of this vulnerability is severe due to both the lack of authentication requirements and the network exposure of the service. The --artifact-server-addr flag defaults to the host's outbound address rather than restricting it to loopback interfaces like 127.0.0.1, which leaves the artifact backend reachable from surrounding networks where other potentially compromised or malicious workloads might reside. Any client with network access to this endpoint can read, overwrite, or delete artifacts belonging to concurrently running jobs without providing any credentials. This exposure puts sensitive build outputs at risk, including secrets, deployment credentials, and proprietary code artifacts. Attackers can intercept these materials before the owning job consumes them, leading to potential data exfiltration, supply chain poisoning through artifact replacement, or denial of service by deleting critical build components.
From a classification perspective, this vulnerability aligns with CWE-287: Improper Authentication, as the system fails to properly verify the identity of users and processes before granting access to resources. It also maps closely to CWE-640: Weak Key Extraction Methodology due to the use of hardcoded cryptographic keys that are publicly known or easily discoverable. Additionally, the ability for an attacker to manipulate object identifiers (workflow_run_backend_id) without authorization corresponds to CWE-862: Missing Authorization. In terms of attack tactics, this scenario reflects MITRE ATT&CK techniques related to Initial Access and Credential Access, as attackers can leverage exposed services to steal sensitive information such as API keys or deployment tokens embedded within artifacts.
To mitigate these risks, immediate remediation is required at both the code configuration and architectural levels. The validation logic in pkg/artifacts/artifacts_v4.go must be restored so that validateRunIDV4 actively checks the caller-supplied workflow_run_backend_id against the actual run ID of the requesting task to ensure strict ownership verification. Cryptographic practices must be updated to replace hardcoded HMAC keys with dynamically generated, unique secrets for each execution context or build instance, ensuring that signatures cannot be forged across different environments. Furthermore, network configuration defaults should be corrected so that --artifact-server-addr binds exclusively to loopback interfaces by default, preventing external network access unless explicitly required and secured through additional firewall rules or service mesh policies. These changes will restore the integrity of artifact storage and prevent unauthorized manipulation of build outputs.