An artifact backend is started by act when a workflow references actions/upload-artifact@v4 or actions/download-artifact@v4. The backend’s RPC endpoints—CreateArtifact, GetSignedArtifactURL, ListArtifacts, FinalizeArtifact, and DeleteArtifact—accept a caller‑supplied workflow_run_backend_id but never verify that it matches the requester, as the validateRunIDV4 check is commented out, constituting a CWE‑862 (Missing Authorization) weakness. Signed URLs are generated with a hard‑coded four‑byte key (0xBA 0xDB 0xEE 0xF0) common to all builds and is computed over an endpoint string, expiry, artifact name, and task ID with no length delimiters, which gives rise to a CWE‑321 (Hardcoded Cryptographic Key) problem and makes the signature both forgeable and ambiguous. The default address for the artifact server is the host’s outbound IP instead of loopback, so any client that can reach the host may read, overwrite, or delete artifacts of concurrent jobs without credentials. These artifacts can contain secrets, deployment keys, or code to be executed by the running job, allowing an attacker to exfiltrate sensitive data or inject malicious build steps before the job processes them.

The vulnerability affects the open‑source project act by nektos, specifically versions 0.2.81 through 0.2.89. Users of these releases that enable the v4 artifact backend are at risk.

The CVSS score of 8.7 indicates high severity. EPSS is not available, but the lack of authentication (CWE‑862) and the default network exposure make exploitation likely in environments where an attacker can reach the host. The hard‑coded key (CWE‑321) means that attackers can forge signed URLs to download, overwrite, or delete artifacts without any credentials, directly compromising confidentiality, integrity, and availability. It is not currently listed in CISA’s KEV catalog.