Not So Secret: The Hidden Risks of GitHub Actions Secrets

Not So Secret: The Hidden Risks of GitHub Actions Secrets

Speakers: Amiran Alavidze

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=k3DBur7iEHM

Overview

Amiran Alavidze, Director of Security Engineering at Zello, delivered a sharp and demo-driven talk exposing a fundamental weakness in GitHub Actions secrets: any user with write access to a repository can trivially exfiltrate all repository-level secrets, regardless of branch protection rules. The talk demonstrated the attack live, showed why it works, and then walked through two concrete mitigations -- GitHub Environments with protection rules and OIDC federation with properly scoped trust policies -- with live demos proving each defense. This is an essential talk for any organization using GitHub Actions for CI/CD with cloud credentials.

Background

▶ Watch: GitHub warning: write access = read access to all secrets (1:30)

GitHub Actions is the dominant CI/CD platform for organizations using GitHub for version control. Workflows frequently need cloud credentials (AWS access keys, service account tokens, etc.) to deploy to or interact with cloud environments. The most common pattern is storing these as repository secrets, which appear secure on the surface: they cannot be viewed in the GitHub UI after creation, and GitHub Actions automatically masks secret values in workflow output logs. GitHub's own hardening documentation contains a warning that "any user with write access to your repository has read access to all the secrets configured in that repository," but provides no further explanation of why this is the case or how to mitigate it.

Key Findings

▶ Watch: Why branch protection rules do nothing to protect secrets (4:00)

The core vulnerability stems from three properties of GitHub Actions that combine to create an exploitable gap:

1. Workflow definitions live in the repository they run on -- they are YAML files in the .github/workflows/ directory
2. Workflow definitions are taken from the branch on which the workflow executes -- not from the default/protected branch
3. Repository secrets are available to any workflow execution within that repository, regardless of which branch triggered it

This means an attacker with write access can create a new branch, modify the workflow YAML to exfiltrate secrets (e.g., by base64-encoding them to bypass GitHub's output masking), and manually trigger the modified workflow on their branch. Branch protection rules on the default branch do nothing to prevent this attack, because the attacker never needs to merge their malicious workflow into the protected branch.

The same attack applies to OIDC-based short-lived credentials when the AWS IAM role trust policy uses a wildcard (*) for the branch in the subject claim. A misconfigured trust policy that allows any workflow in the repository to assume the role is just as vulnerable as a repository secret.

Technical Deep Dive

▶ Watch: Environment protection rules block the exfiltration attack (8:00)

Alavidze demonstrated the attack in three scenarios with increasing sophistication:

Attack 1: Repository Secrets. The attacker creates a branch, replaces the workflow steps with commands that base64-encode the secret values (bypassing GitHub's masking), and runs the workflow on the new branch. The base64-encoded credentials appear in the workflow output.

Attack 2: OIDC with Misconfigured Trust Policy. Even with OIDC federation eliminating long-lived credentials, a trust policy that uses repo:org/repo:* in the subject condition allows any branch to assume the role. The attacker's modified workflow on a non-protected branch successfully assumes the role and exfiltrates the short-lived credentials (access key, secret key, and session token).

Mitigation 1: GitHub Environments. By creating a deployment environment (e.g., "production") with a protection rule restricting it to only the main branch, and moving secrets from repository-level to the environment, the attack is blocked. When the attacker attempts to run the malicious workflow from a non-protected branch referencing the production environment, the workflow fails because the environment protection rules prevent execution on unapproved branches.

Mitigation 2: Scoped OIDC Trust Policies. The AWS IAM role trust policy can be scoped to a specific branch (repo:org/repo:ref:refs/heads/main) or to a specific GitHub Environment (repo:org/repo:environment:production). When an environment is used in the workflow, the subject claim always contains the environment name rather than the branch reference, so the trust policy must account for this.

Combined Defense. The strongest posture combines both: environment protection rules prevent the workflow from running on unauthorized branches, and the OIDC trust policy requires the specific environment in the subject claim. Alavidze demonstrated that even attempting to bypass by removing the environment reference from the workflow while keeping the correct role ARN fails, because the trust policy requires the environment in the subject.

Demo / Proof of Concept

▶ Watch: OIDC with misconfigured wildcard trust policy is equally vulnerable (10:00)

The entire talk was a live demonstration. Alavidze executed attacks and mitigations in real-time against a live GitHub repository and AWS account, showing workflow runs, failures, and credential exfiltration directly in the GitHub UI and workflow logs. Each scenario built on the previous one, making the progression from vulnerability to defense immediately clear.

Defensive Implications

▶ Watch: Conclusions and recommendation to never use repository secrets (15:00)

The single most impactful action defenders can take is to never use GitHub repository secrets. All secrets should be stored in GitHub Environments with protection rules that restrict usage to specific protected branches. For AWS (and other cloud providers supporting OIDC federation), trust policies must be scoped to specific branches or environments -- never use wildcards in the subject condition. Organizations should combine both defenses for defense-in-depth: environment protection rules prevent unauthorized workflow execution, and scoped OIDC trust policies prevent unauthorized role assumption even if the environment protections are somehow bypassed.

Additionally, defenders should review workflow triggers. The trigger configuration comes from the default branch and determines whether a workflow can be executed at all. Manual triggers (workflow_dispatch) are particularly risky because they allow running workflows on any branch. Organizations should audit which triggers are enabled and consider whether they are necessary.

Key Takeaways

• Any user with write access to a GitHub repo can exfiltrate all repository-level secrets by creating a branch with a modified workflow -- branch protection rules do not prevent this
• GitHub's output masking is trivially bypassed with base64 encoding
• Never use repository secrets -- use GitHub Environments with branch-scoped protection rules instead
• OIDC federation with AWS is vulnerable to the same attack if the trust policy uses wildcards; scope trust to specific branches or environments
• Combining Environment protection rules with scoped OIDC trust policies provides defense-in-depth
• Workflow trigger configuration matters -- review which triggers are enabled and their security implications

About the Speaker(s)

Amiran Alavidze is the Director of Security Engineering at Zello, a company building push-to-talk voice solutions for frontline workers. His talk demonstrated deep practical knowledge of GitHub Actions internals and AWS IAM federation.