CVE-2026-76847: act 0.2.81 through 0.2.89 Missing Authorization in the Artifacts V4 Backend
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 workflowrunbackendid and never check that it belongs to the requester: validateRunIDV4 in pkg/artifacts/artifactsv4.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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
actto a version that resolves this vulnerability.Fixed in 0.2.81 - Upgrade
Upgrade
actto a version that resolves this vulnerability.Fixed in 0.2.89 - Configuration
Set --artifact-server-addr to loopback so the backend is not reachable from the surrounding network.
act Artifacts V4 backend --artifact-server-addr = 127.0.0.1 (loopback) - Compensating control
Restrict network access to the Artifacts V4 backend HTTP service so that surrounding clients cannot reach the backend (e.g., firewall/ACL rules allowing only the workflow runner/network namespace to connect).
- Compensating control
Place the workflow runner/act process and its Artifacts V4 backend behind network isolation so that only the owning workflow/job can access its artifact endpoints.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Users running affected act versions whose workflows use actions/upload-artifact@v4 or actions/download-artifact@v4 are exposed. By default, the Artifacts V4 backend binds to the host's outbound address rather than loopback, making it reachable from the surrounding network.
What does an attacker need to exploit it?
An attacker only needs network reachability to the Artifacts V4 backend while a job is running. No credentials are required; the backend accepts caller-supplied workflow run IDs without verifying ownership, and its signed-URL HMAC key is hardcoded and identical across builds.
What can an attacker do?
A reachable attacker can read, overwrite, or delete artifacts belonging to a concurrently running job. This can expose build outputs, including secret material contained in artifacts, and compromise artifact integrity or availability.
What configuration can reduce exposure if patching is not immediately possible?
Prevent untrusted network clients from reaching the artifact server, such as by restricting access to the host and surrounding network. Avoid running workflows that use the affected v4 upload or download artifact actions until the issue is addressed.