IP allow list blocks authenticated non-member users from accessing public repository resources

[knqyf263]

🏷️ Discussion Type

Question

Body

Question

When an organization enables an IP allow list, authenticated API requests to public repositories from users who are not members of the organization are blocked with HTTP 403, while the same requests succeed anonymously.

Is this the intended behavior?

Details

The documentation states that IP allow lists protect "public resources, when a user is signed into GitHub."

Public resources, when a user is signed into GitHub (including non-interactive authentication methods such as:

Does this means any authenticated user worldwide — even those with no relationship to the organization — is blocked from accessing public resources if their IP address is not on the allow list?

This creates a situation where authenticating reduces access to public resources:

# Authenticated (non-member, IP not on allow list) → 403
gh api repos/<org>/<public-repo>/git/ref/tags/<tag>

# Anonymous → 200
curl https://api.github.com/repos/<org>/<public-repo>/git/ref/tags/<tag>

Impact

This affects a large number of users, since tools like the GitHub CLI (gh) automatically send authentication credentials. For example, gh release verify — GitHub's own command for verifying release integrity — fails against public repositories of organizations with IP allow lists enabled.

As a result, one GitHub security feature (IP allow list) breaks another (release verification via immutable releases) for all external users.

Feature request

If this is the intended behavior, I would like to request that the IP allow list be scoped to organization members and collaborators only, rather than applying to all authenticated users. Blocking non-member users from accessing public resources provides no security benefit to the organization and has significant negative side effects for the broader community.

[IrtezaAsadRizvi]

@knqyf263, This appears to be intended behavior under the current product rules, based on the docs, not an official GitHub statement.

GitHub’s organization IP allow list docs say the policy covers public resources when the requester is signed in, and that the same public resources are not restricted when accessed anonymously. gh api is also documented as always making an authenticated request. So the 403 for authenticated non-members and 200 for anonymous curl is consistent with the current documented behavior.

I’d also say the feature request is reasonable. Even if it’s intentional, it’s a poor outcome for public-read workflows like gh release verify. The better behavior would be to scope the restriction to org-affiliated identities or non-public resources, not to all authenticated reads of public repos.

Sources:
https://github.com/orgs/community/discussions/191185
https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization
https://cli.github.com/manual/gh_api

[knqyf263]

Yes, that's exactly what I wanted to ask. Thanks for summarizing.

[IrtezaAsadRizvi]

@knqyf263 Please choose this reply as the answer and mark the discussion as answered.

[WilliamRossCrane]

Can you check this as answered

[syedsafeer]

Hi @knqyf263,
Unfortunately, this is the intended behavior of GitHub’s current security architecture, even though it creates a paradoxical experience.

When a request is authenticated, GitHub forces it to comply with the Organization’s IP allow list policies before granting access to any of its resources—including public ones. Anonymous requests work because the system doesn't have a user identity to validate against the allow list, so it falls back to standard public access.

You’ve raised a very valid point regarding the impact on tools like gh CLI. Your suggestion to scope the IP allow list specifically to Members and Collaborators would solve this 'logged-in-but-blocked' issue for external contributors.

(If this explanation clarifies the current logic for you, please Mark as Answer)

[knqyf263]

Thank you for your responses. However, since this discussion includes a question about whether this is the intended behavior and, if so, a request to consider changing it, I'd like to keep this open until we get an official response from GitHub staff.

[Gecko51]

Confirmed intended behavior based on the current documentation. The existing answers cover the why well.

For anyone hitting this in practice, the immediate workaround is to strip authentication from the request. The IP allow list check only triggers when GitHub can identify a user, so anonymous requests bypass it.

For gh api, you can work around it by temporarily unsetting your token:

GITHUB_TOKEN= curl https://api.github.com/repos/<org>/<public-repo>/git/ref/tags/<tag>

For gh release verify specifically, the issue is that gh doesn't have a --no-auth flag. The cleanest workaround right now is to use curl with --no-auth behavior for any public resource lookups against orgs with IP allow lists, or to submit a GitHub CLI issue requesting a --no-auth flag that drops the Authorization header for public endpoint requests.

The underlying feature request here is solid. Scoping IP allow list enforcement to org-affiliated identities (members + collaborators) for public resources would resolve the paradox without weakening any meaningful security boundary. It's worth tracking via GitHub's public roadmap or filing a dedicated feature request at https://github.com/github/feedback if you want it formally tracked.