Skip to content

Action archive downloads ignore configured GitHub origin and lack cache/download bounds #158

Description

@Bnjoroge1

Severity

P1 / high security + availability

Review baseline

0bd0e314696e520aa47620cbe8f008d010e01e57

Summary

Action ref resolution honors the configured GitHub API origin, but archive download construction later hardcodes https://api.github.com/repos/{owner}/{repo}/tarball/{ref} and may attach the configured static GitHub PAT.

On GHES, that can send an enterprise credential to the wrong origin. The archive path also has no streamed byte cap, cache quota/eviction, or per-key single-flight.

Impact

  • Potential credential disclosure to GitHub.com when the configured credential is intended for an enterprise GitHub origin.
  • Unbounded action archives can fill the persistent action cache/state disk.
  • Concurrent requests for the same uncached action can duplicate large downloads.
  • Failed streams can leave partial temporary data behind depending on error path.

Recommended remediation

  • Construct the archive URL from the configured GitHub API origin, not a hard-coded public GitHub hostname.
  • Bind credentials to an explicit allowed audience/origin and refuse cross-origin attachment.
  • Enforce a maximum archive size while streaming; do not rely only on Content-Length.
  • Add action-cache accounting, size quota and LRU/TTL eviction.
  • Add per-cache-key single-flight so one action/ref is downloaded once under contention.
  • Ensure temporary files are deleted on every failure path and published atomically only after successful verification.
  • Add GHES tests proving enterprise credentials are never sent to api.github.com.

Acceptance criteria

  • GHES action tarballs are fetched from the configured GHES API host.
  • A PAT/token configured for host A can never be attached to a request sent to host B.
  • Oversized action archives fail before exceeding the configured cache/download quota.
  • Concurrent cache misses for the same action produce one upstream download.
  • The cache has an explicit bounded retention/eviction policy.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions