CVE-2026-34042: 
vulnerability analysis and mitigation

CVE-2026-34042 is a missing authorization vulnerability in nektos/act, a tool for running GitHub Actions locally. The built-in actions/cache server listens on all network interfaces without any authentication, allowing any remote attacker to create caches with arbitrary keys and retrieve all existing cached data. Affected versions are github.com/nektos/act ≤ 0.2.85; gitea.com/gitea/act_runner (all versions) is also noted as affected with no patched version listed at time of advisory. The vulnerability was discovered during a discussion in the Forgejo runner issue tracker, published on March 25, 2026, and assigned a CVSS v3.1 base score of 8.2 (High) (GitHub Advisory, nektos/act Advisory).

The root cause is CWE-862 (Missing Authorization): the pkg/artifactcache HTTP handler registered routes under a fixed, unauthenticated path (/_apis/artifactcache) and bound the TCP listener to all interfaces (0.0.0.0), meaning any network-reachable host could interact with the cache API without credentials. An attacker who can reach the exposed port can issue unauthenticated HTTP requests to POST /_apis/artifactcache/caches to reserve a cache entry with a predicted key, PATCH to upload arbitrary file content, and POST to commit it — effectively poisoning the cache. When a legitimate workflow action subsequently fetches that cache key, the malicious files are extracted into the Docker container's filesystem, enabling arbitrary code execution. The fix in commit c28c27e introduced a 16-byte random token embedded in the URL path and restricted the listener to the outbound IP only, making the token a de-facto bearer secret (nektos/act Advisory, Patch Commit).

An unauthenticated remote attacker can read all cached data stored by running workflows, resulting in high confidentiality impact — secrets, build artifacts, or sensitive files placed in the cache are fully exposed. By injecting a malicious cache entry with a predictable key, the attacker can achieve arbitrary remote code execution within the Docker container that act uses to run workflows, compromising the integrity of the CI/CD pipeline and any secrets or credentials accessible from within that container. The scope is marked as Changed, meaning the impact extends beyond the cache server component itself to the Docker container environment (GitHub Advisory, nektos/act Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The EPSS score is approximately 0.025% (7th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. However, the attack requires no privileges and only low complexity — the primary barrier is network reachability to the exposed cache server port and the ability to predict cache keys used by local actions.

1. Reconnaissance: Scan for hosts running act with an exposed cache server port (default is a random high port; identify via service banners or by scanning the host running act). Confirm the server responds to HTTP requests at /_apis/artifactcache/cache.
2. Identify cache keys: Review the target repository's workflow files (often public) to predict the cache keys used by actions/cache steps (e.g., keys based on OS, dependency file hashes, or static strings).
3. Reserve a malicious cache entry: Send an unauthenticated POST request to http://<target>:<port>/_apis/artifactcache/caches with a JSON body specifying the predicted cache key and version to reserve a cache slot and obtain a cache ID.
4. Upload malicious content: Send a PATCH request to http://<target>:<port>/_apis/artifactcache/caches/<id> with a crafted archive (e.g., a tar file containing a malicious script or binary) as the request body.
5. Commit the cache: Send a POST request to http://<target>:<port>/_apis/artifactcache/caches/<id> to finalize and commit the malicious cache entry.
6. Trigger execution: Wait for or trigger a workflow run that uses actions/cache with the poisoned key. When the action restores the cache, the malicious files are extracted into the Docker container, achieving arbitrary code execution within the CI environment (nektos/act Advisory, Patch Commit).

• Network: Unexpected inbound HTTP connections to the act cache server port from external or untrusted IP addresses; HTTP requests to /_apis/artifactcache/caches (POST/PATCH) originating from IPs not associated with the local runner host.
• Logs: HTTP access logs showing POST /_apis/artifactcache/caches or PATCH /_apis/artifactcache/caches/<id> requests from unexpected sources; cache entries with keys that do not match any workflow definition in the repository.
• File System: Unexpected or modified files appearing in the Docker container's workspace after a cache restore step; archives with unusual content extracted to workflow working directories.
• Process: Unexpected child processes spawned within the act Docker container following a cache restore step (e.g., reverse shells, download utilities like curl or wget, or scripting interpreters).

Upgrade github.com/nektos/act to version 0.2.86 or later, which introduces a 16-byte random token in the cache server URL path and restricts the listener to the outbound IP address rather than all interfaces (act Release v0.2.86, Patch Commit). For gitea.com/gitea/act_runner, no patched version was available at the time of the advisory; users should apply network-level controls (firewall rules, host-based firewalls) to restrict access to the cache server port to only the local machine or trusted CI infrastructure. As an additional measure, run act in isolated network environments and avoid exposing the host running act directly to the internet.

The vulnerability was noted on Mastodon and Bluesky social platforms shortly after disclosure, with brief community commentary on the exposure of the unauthenticated cache server (Mastodon, Bluesky). The Forgejo project, which maintains a related runner, was involved in the original discovery discussion and is considering additional mitigations such as encoding the repository identity into the cache URL secret to prevent cross-repo cache access (GitHub Advisory). No major vendor statements or significant media coverage beyond vulnerability database entries have been identified.