GH_IN_TEAM

Summary

Forestall ACL Alias

GH_IN_TEAM

Edge Type

Relationship

Affected Object Types

GitHub Teams

Exploitation Certainty

N/A (structural)

GitHub Role / Permission

Team membership

Description

GH_IN_TEAM is a structural membership relationship recording that something is inside a team (bottom-up). It covers two cases:

(GHUser)-[GH_IN_TEAM]->(GHTeam) — a user is a member of the team.
(GHTeam)-[GH_IN_TEAM]->(GHTeam) — a child (nested) team belongs to its parent team.

Membership is how access flows downward: a member inherits the access the team has been granted (its repositories via GH_HAS_ACCESS, and anything the parent team can reach). So while GH_IN_TEAM is structural rather than a privilege in itself, it is a key inheritance hop in attack paths — compromising a member yields the team's access, and a nested team inherits its parent's grants.

The ability to manage team membership is a separate, privileged edge (GH_MAINTAINER); GH_IN_TEAM only records the membership itself.

Identification

GitHub Web Interface

Open the organization → Teams → a team → Members (users) and the team's nested-team hierarchy.

GitHub CLI

# members of a team
gh api "orgs/{org}/teams/{team_slug}/members" --paginate --jq '.[].login'
# nested (child) teams of a team
gh api "orgs/{org}/teams/{team_slug}/teams" --paginate --jq '.[].slug'

Exploitation

Not applicable on its own — GH_IN_TEAM is structural. Its security relevance is as an inheritance hop: a member reaches everything the team can (see GH_HAS_ACCESS, GH_ADMIN, GH_PUSH_TO_DEFAULT), and a child team inherits its parent's access.

Mitigation

Keep teams scoped and memberships reviewed — a member inherits all of the team's repository access, so over-broad teams widen everyone's reach.
Use shallow, intentional nesting — child teams inherit parent access; deep hierarchies make effective access hard to reason about.
Audit membership of privileged teams (those holding admin/write on sensitive repositories) regularly.