nektos act EUVD-2026-64852

The artifact backend is only started when the workflow being executed by act includes a step that invokes actions/upload-artifact@v4 or actions/download-artifact@v4 - workflows that do not use these specific actions are not exposed. The --artifact-server-addr flag must retain its default value (the host's outbound IP rather than 127.0.0.1); if an operator explicitly overrides it to loopback, network-adjacent exploitation is prevented. At least one concurrent job must be active using the artifact backend for a meaningful cross-job artifact theft scenario, though single-job scenarios still expose that job's own artifacts to network attackers. Limiting factors: AV:A constrains exploitation to attackers on the same L2 network segment or the same host - arbitrary internet-based attackers cannot reach the backend directly. The backend is ephemeral and only active during the artifact upload or download operation, creating a narrow time window. There is no authentication mechanism to bypass beyond the broken HMAC; no special user privileges, application roles, or prior access to act configuration are required once network reach is established.

The CVSS 4.0 score of 8.7 with vector AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H is well-calibrated: the AV:A (Adjacent) metric is the primary limiting factor, meaning exploitation requires the attacker to be on the same local network segment or the same host as the act process. In developer workstation or shared CI/CD environments - the primary deployment context for act - adjacency is a realistic attacker position: co-located containers, shared build agents, or other processes on a developer machine all qualify. The AC:L and PR:N metrics reflect that once reachable, exploitation requires no special conditions or credentials because both the authorization check and the HMAC have been rendered ineffective by the defects described. No EPSS score was provided in the available intelligence, and the vulnerability is not listed in the CISA KEV catalog at time of analysis. However, the exploitable conditions are self-evident from reading the public source at v0.2.89, and the hardcoded HMAC key is a known constant - effectively making the signed-URL scheme equivalent to no authentication. The threat is most acute in shared CI environments where multiple workflows run concurrently using artifact actions: an attacker in the same build environment can inject malicious binaries, steal secrets exfiltrated to artifacts, or corrupt build outputs before they are consumed by subsequent steps.

An attacker on the same local network or host as a developer or CI agent running act waits for a job that invokes actions/upload-artifact@v4 to begin, identifies the artifact backend's address from the act process's bound outbound interface, and forges a valid HMAC signature for a ListArtifacts RPC by computing the 4-byte hardcoded key (0xba 0xdb 0xee 0xf0) over the known concatenation scheme. The attacker calls GetSignedArtifactURL with an arbitrary workflow_run_backend_id to retrieve a signed URL for the victim job's artifacts containing deployment tokens or compiled binaries, exfiltrates the secrets, and optionally calls CreateArtifact or FinalizeArtifact to replace the artifact with a malicious payload before the owning job downloads it. No proof-of-concept code has been identified in the available intelligence, but the HMAC key and the commented-out authorization check are directly readable in the public source repository.