Full Report
GitHub Actions provides a policy mechanism to limit the kinds of actions and reusable workflows that can be used. The policies eliminate the failure mode of adding malicious or harmful workflows without further consideration. The restrictions can be applied to specific tags or commit hashes, as well as to particular organizations or repositories. It's a reasonably practical system for ensuring that a developer doesn't harm themselves. This policy system can be "bypassed" via calling git clone on the repository and using a relative path. To me, this is a sane. If you downloaded something locally, then you're making an active choice to run the code. At the same time, is does work around the policy preventing of foot-guns. The author suggests adding a new policy type that can explicitly allow or deny local usage of workflows. I'm personally on the fence about this though. Regardless, an interesting thing to know about for GitHub Actions.
Analysis Summary
# Vulnerability: GitHub Actions Policy Bypass via Local Path Consumption
## CVE Details
- CVE ID: Not specified in the article. This appears to be an inherent design limitation or misconfiguration risk rather than a traditional CVE.
- CVSS Score: Not specified.
- CWE: Likely related to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), or CWE-284: Improper Access Control if policies are assumed to restrict all inputs.
## Affected Systems
- Products: GitHub Actions enforced enterprise/organization/repository policies intended to restrict usage of external Actions and Reusable Workflows.
- Versions: Not applicable; the flaw relates to the policy enforcement mechanism itself, not specific platform versions.
- Configurations: Any repository or organization utilizing GitHub Actions policies to restrict external `uses:` statements (i.e., those referencing `OWNER/REPOSITORY@REF`).
## Vulnerability Description
GitHub Actions offers policy mechanisms to restrict which external Actions and reusable workflows can be utilized (e.g., only allowing specific organizations, repositories, or commit hashes/tags). This mechanism is designed to prevent developers from accidentally or intentionally introducing untrusted code.
However, this policy protection can be entirely bypassed if an attacker utilizes a local path reference in the workflow file syntax:
yaml
uses: ./path/to/local/action
When an action is referenced via a local path (`./`), the GitHub Actions runner clones the repository containing the workflow locally and executes the referenced workflow from the runner filesystem. Because the policy is designed to restrict **external** dependencies accessed via `OWNER/REPOSITORY@REF`, it fails to restrict workflows being executed locally from within the repository being built, effectively bypassing the intended security boundary.
## Exploitation
- Status: Theoretical/Design Limitation. The primary risk is misuse/misconfiguration stemming from relying on the policy for security assurance. (Not explicitly reported as exploited in the wild via CVE, but the mechanism is readily available).
- Complexity: Low. It requires modifying the workflow file to use a local path reference (`./`) instead of an external repository reference.
- Attack Vector: Local (within the repository context).
## Impact
- Confidentiality: Potential for unauthorized access to secrets if the local workflow is malicious, as policies might otherwise prevent the execution of a malicious action that could exfiltrate data.
- Integrity: High. A malicious local workflow can execute arbitrary code with the permissions/secrets available to the standard GitHub Actions job runner, compromising the build integrity.
- Availability: Medium. Can result in pipeline failures or resource exhaustion if the malicious workflow is disruptive.
## Remediation
### Patches
- GitHub has acknowledged the limitation and updated documentation (as of 2025-06-13) to explicitly state that policies **never restrict access to local actions** when `./` path syntax is used. No explicit code patch is listed, as GitHub does not currently treat this as a fixable security vulnerability requiring policy enforcement on local paths.
### Workarounds
1. **Assume No Protection:** Security teams must operate under the assumption that policies do not secure against local path consumption.
2. **Code Review:** Rely primarily on standard code review practices for all workflow files (`.github/workflows/*.yml`) to ensure that no developer introduces malicious paths, especially if the organization relies on policies for trust assurance.
3. **Policy Review (Preventing Initial Misplacement):** While the bypass is local, organizations should ensure that the *initial* repository where the malicious path reference is introduced is itself well-vetted.
## Detection
- **Indicators of Compromise:** Look for workflow executions that succeeded despite the job supposedly using only whitelisted external actions, but which might have executed a local path reference.
- **Detection Methods and Tools:** Static analysis tools configured to monitor workflow files for the presence of `uses: ./` or `uses: ../` syntax within repositories that strictly enforce external policies might flag these for manual review.
## References
- Vendor documentation update regarding policy limitations: [docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#allow-enterprise-and-select-non-enterprise-actions-and-reusable-workflows](https://docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#allow-enterprise-and-select-non-enterprise-actions-and-reusable-workflows) (Access via GitHub documentation)
- Original research source: [blog.yossarian dot net/2025/06/11/github-actions-policies-dumb-bypass]