GitHub May Temporarily Require Authentication to Clone Public Repositories
During periods of anomalous traffic, GitHub may temporarily require authentication for some git clone and git fetch operations over HTTPS. Developers should check automated builds that fetch code without authentication.
GitHub may temporarily require authentication for some operations on public repositories over HTTPS when traffic is anomalous. Habr reported this on October 20, 2026, citing an announcement from the service. The measure affects some git clone and git fetch requests: if Git returns an authentication error, you can authenticate and retry the command, or wait for the restriction to be lifted and try again without authentication.
When a clone request might fail
The restriction is intended to help keep github.com available during periods of heightened suspicious activity. GitHub will apply it selectively, based on signs of anomalous traffic. It is not introducing mandatory authentication for all public repositories.
The error may also appear for an ordinary user. The signals the protection relies on can sometimes be the same for suspicious and legitimate requests. So if a public repository suddenly stops cloning without authentication, the cause may be a restriction on that particular operation rather than a change to the repository’s access settings.
GitHub has not said how long restrictions will remain in place; that depends on traffic conditions. This uncertainty matters for processes that fetch code automatically. There is no way to know in advance when another attempt without authentication will succeed.
Which operations remain unchanged
The protection affects some unauthenticated operations that fetch data from public repositories over HTTPS. It does not affect authenticated Git operations over HTTPS. SSH access to repositories and pushing changes with git push also remain unchanged.
Other requests to GitHub’s web interface and API that are unrelated to this protection are not affected. That makes it important to check the specific access method: successfully opening a repository in a browser does not, by itself, show whether an anonymous git clone will work in an automated process.
The measure applies to repositories on github.com across all pricing plans. What matters for a team is not its plan, but how a particular workflow fetches changes. One process may use authenticated HTTPS, while another accesses a public repository without authentication. GitHub’s announcement concerns the latter case if the request triggers the protection.
What to check in builds and workflows
Developers and teams maintaining websites should first identify automated steps that regularly run git clone or git fetch over HTTPS without authentication. If such a step is part of a build, a Git error could stop the process even though nothing in the project has changed. Checking for this dependency is more useful than trying to predict which requests the service will consider anomalous.
GitHub recommends setting up authentication for automation that regularly clones repositories or fetches changes. In GitHub Actions, you can use the built-in GITHUB_TOKEN for this. For other CI systems, an access token for an installed GitHub App is preferred; another option GitHub mentions is a personal access token (PAT).
If authentication cannot be set up, you can wait for the protection to be lifted and retry the operation. That is a straightforward option for a manual command. It is less convenient for an automated workflow that needs to run unattended: the error will leave the build unfinished until another attempt is made. So it is worth finding out where anonymous HTTPS access is used and how important that step is to releasing changes.
A website owner or marketer does not need to know the Git commands. The question for the team is simpler: does publishing changes depend on automatically fetching a public repository from GitHub, and is that process authenticated? If there is no such dependency, the announcement does not mean the usual website release process needs to change.
My take: check the dependency before changing the setup
I would not overhaul the entire build because of this. First, I would look for a specific step that regularly accesses a public repository over HTTPS without authentication. If there is one, setting up authentication makes sense: GitHub acknowledges that the restriction may affect ordinary requests too.
To me, the trap lies in two extremes. You could dismiss the error as a rare exception and fail to check what the build depends on. Or you could complicate a working setup just in case, without first finding out how it fetches code. I would start with the access method and only then choose an appropriate authentication option.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
Junior Backend Developer
I’m learning Python and building small APIs for practice projects. I still don’t know where solid architecture ends and overengineering for the sake of a pretty diagram begins.
All posts by the authorRelated articles
GitHub to Restrict pull_request_target in Public Repositories Starting December 2
Starting December 2, GitHub will block pull_request_target workflows in public repositories by default. Teams should check their Actions workflows and policies ahead of time.
543,000 Active Secrets Found in Public GitHub Repositories
Truffle Security analyzed 224 million public GitHub repositories and found 543,000 active secrets. Many had been exposed for years, while some go undetected by GitHub’s built-in push protection.
GhostAction: Around 1,900 GitHub Accounts Compromised, More Than 30,000 Repositories Affected
GhostAction affected around 1,900 GitHub accounts and more than 30,000 repositories. Attackers tried to steal CI/CD secrets, cloud credentials, and API keys for AI services.
Discussion 4
Daniel Borisov
Have you seen whether this also affects builds that fetch public dependencies through Git submodules, or only the main clone and fetch?
Lev Fyodorov Post author
the announcement calls out clone and fetch, so submodules could be affected when git fetches their public repos over https too. i’d check the actual remote URLs and whether the build has credentials available; it doesn’t sound like submodules are explicitly exempt.
Inês Almeida
One subtle failure mode worth checking is how the submodule URL is declared: a relative URL may resolve differently from an absolute HTTPS URL, and nested submodules can introduce more public remotes than the top-level repo suggests. I’d make the build log the resolved URLs (without exposing tokens) and test a clean checkout, since a warm cache can hide an auth problem until CI runs on a fresh worker.
Zdeněk Damberg
The write-up only mentions HTTPS `git clone` and `git fetch`, so it doesn’t say whether submodule fetches are treated differently. Since submodules invoke Git to fetch their own repositories, I’d check them in CI too—especially if they use HTTPS URLs without credentials. If one fails, authenticating and retrying should help confirm whether it’s the temporary restriction.