Skip to content
Forestall

GH_ADMIN

Copy page

Summary
Forestall ACL Alias GH_ADMIN
Edge Type Attack Path
Affected Object Types GitHub Repositories, GitHub Organizations
Exploitation Certainty Certain
GitHub Role / Permission Repository admin, or a GitHub App installation with admin-level org permissions

Description

GH_ADMIN represents admin-level control over a target. It spans two cases, differentiated below by the source and target type:

  • (GHUser | GHTeam) → (GHRepository): the user or team holds the repository admin role — full control of that repository.
  • (GHAppInstallation) → (GHOrganization): the app installation holds admin-level organization permissions (administration, organization_administration, members, or organization_custom_roles at write) — admin-level reach over the organization.

In both cases the holder can fully administer the target, and through it pivot further (CI/CD, secrets, cloud federation), so this is a traversable attack path.

Repository admin (user/team → repository)

A repository admin can:

  • Add, remove, or change collaborator/team permissions — including granting persistent access.
  • Create, edit, and delete branch protection rules.
  • Read and write repository secrets, deploy keys, webhooks, and environments.
  • Modify GitHub Actions workflows and run them — the entry point for CI/CD and OIDC-based cloud pivots.
  • Change visibility, transfer, or delete the repository.

Users appear via direct collaborator grants with admin; teams appear when granted admin on the repository (team members reach it transitively via GH_IN_TEAM).

App admin (app installation → organization)

A GitHub App is a credential-bearing non-human identity. An installation with admin-level org permissions can administer the organization. An attacker who compromises the app (private key, installation token, or the app’s publisher) inherits those permissions — without compromising any user account, surviving credential rotation and offboarding.

Identification

Repository admin

gh api "repos/{org}/{repo}/collaborators?affiliation=direct" --paginate \
  --jq '.[] | select(.permissions.admin==true) | .login'
gh api "repos/{org}/{repo}/teams" --paginate --jq '.[] | select(.permission=="admin") | .slug'

Exploitation

Repository admin

Admin is full control of the repository — no escalation needed:

  1. Remove branch protection and push to the default branch. 
    gh api --method DELETE "repos/{org}/{repo}/branches/{branch}/protection"
  2. Inject a malicious workflow that runs with repo secrets and, where OIDC federation is configured, exchanges a GitHub token for cloud credentials.
  3. Exfiltrate secrets and establish persistence (add an attacker collaborator, deploy key, or webhook).

App admin

  1. Obtain the app’s credentials (private key from CI/CD secrets, a live installation token, or the publisher account).
  2. Mint an installation token and act as the app: 
    gh api --method POST "/app/installations/{installation_id}/access_tokens"
  3. Exercise admin permissions — change org settings, administer repositories, add members, or modify custom roles to escalate further. Apps survive user offboarding, so this is durable access.

Mitigation

  1. Minimize admin grants. Grant repository admin only where required; prefer maintain/write/triage. Install apps with least privilege — avoid administration/organization_administration/members/organization_custom_roles unless essential.
  2. Manage access through teams, not ad-hoc direct collaborators.
  3. Protect the default branch independently of admin (include administrators in branch protection on critical repos).
  4. Protect and rotate app credentials; restrict who can install or approve apps and change their permissions.
  5. Review admins regularly — treat repository admins on sensitive repos and admin-level app installations as Tier-0.

Detection

Event Description
repo.add_member / repo.update_member Repository collaborator added / permission raised to admin
team.add_repository A team was granted access to a repository
protected_branch.destroy A branch protection rule was deleted
integration_installation.create / integration_installation.version_updated App installed / installation permissions changed

Alert on grants of admin permission, on deletion of branch protection, and on app installations granted (or upgraded to) admin-level permissions — especially outside an approved change process.

References

Was this page helpful?

Thank you for your feedback.