For the complete documentation index, see llms.txt. This page is also available as Markdown.

GH_ADMIN

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

App admin

Exploitation

Repository admin

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

  1. Remove branch protection and push to the default branch.

  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:

  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

Last updated

Was this helpful?