GitHub may require auth for anonymous Git over HTTPS during traffic spikes

A CI job that git clones a public repository without a token worked yesterday and may fail today, during a window the user cannot see from the outside. GitHub published a changelog entry on 19 October saying that during periods of unusual traffic it may now temporarily require authentication for some clones and fetches of public repositories over HTTPS, to protect the availability of github.com. The notice says the operation will fail with a message that authentication is required.

The protection applies to clone and fetch of public repositories over HTTPS, and nothing else. GitHub names four operations that are unaffected: authenticated Git operations over HTTPS, Git operations over SSH, pushes, and any unrelated GitHub web and API traffic. The company says the measure is "not a general authentication requirement for public repositories", and that it is applied as narrowly as possible using signals associated with anomalous traffic. Those same signals can sometimes catch legitimate unauthenticated requests, and the notice is open about it.

What to do about it

The changelog's own instructions put the fix in three categories. For a GitHub Actions workflow, the built-in GITHUB_TOKEN already covers it; a job that uses the token for its actions/checkout or any later git call is not affected by the protection. For other CI systems, GitHub recommends a GitHub App installation access token, or a personal access token where an App is not feasible. For an operation that genuinely cannot authenticate, the only option is to wait and retry after the temporary protection has been lifted, which the message does not give an expected duration for.

The protection applies to repositories on github.com across all plans. A reader of the changelog looking for the technical shape of the "unusual traffic" that triggers it will not find it in the entry, which treats the trigger as an operational detail. GitHub links the reader out to its own documentation pages for authentication setup and remote-repository management rather than publishing a configuration flag that would turn the behaviour on or off.

Where the exposure is likely to be

Most working CI pipelines will not notice. actions/checkout uses GITHUB_TOKEN by default, and private GitHub-hosted runners already authenticate for the same reason. A team that cloned a dependency from a public GitHub repository anonymously, for example inside a Dockerfile build step that runs git clone https://github.com/<owner>/<repo> with no credentials, is in the group that can hit the 403. The same is true for container image builds that pull a Git submodule by HTTPS, developer scripts that git fetch an upstream from an untracked remote, and third-party CI providers whose shared workers may share a public IP with other builds and so register as part of a traffic spike.

The item in the GitHub Changelog is dated 19 October 2026 and credited to a single author, Allison. GitHub does not describe this as a vulnerability or an incident, and no deadline is attached: it is a protection that may apply, when GitHub decides it needs to apply. A team that reads the entry today has today to swap the handful of anonymous clones in its builds for authenticated ones before the next window where the switch is on.

Source

• The GitHub Blog, Allison