# Dependabot’s private GitHub Packages access is back — now as fallback authentication GitHub has re-enabled automatic private-package access for Dependabot after rolling the feature back in June. The short-lived `GITHUB_TOKEN` path now acts only as fallback authentication, preserving explicit registry credentials and normal package routing. The corrected rollout matters for supply-chain configuration: teams can still remove PATs for qualifying GitHub Packages, but GitHub changed the precedence model after some npm update jobs were mistakenly routed through GitHub Packages. - Status: Active - Published: 2026-09-09T20:32:59+12:00 - Updated: 2026-09-10T22:01:17+12:00 - Categories: Web Development, Cloud & Infrastructure, Deployment & DevOps, Developer Tools - Tags: Authentication, Dependabot, GitHub, GitHub Packages, supply chain security - Canonical HTML: https://beyondthe.news/dossiers/github-dependabot-private-packages-github-token-actions-access ## Latest material change Corrects the rollout history and authentication precedence after GitHub's editor note: the feature first launched June 23, was temporarily rolled back after npm routing conflicts, and was re-enabled September 8 with automatic GitHub Packages credentials used only as fallback authentication. Explicit registry credentials and normal routing take precedence. ## What changed GitHub re-enabled automatic Dependabot authentication to private GitHub Packages and GitHub Container Registry dependencies on September 8, 2026 after temporarily rolling the feature back. GitHub's current editor note says the original release occurred June 23 and was withdrawn after a conflict caused some npm update jobs to resolve public packages through GitHub Packages. In the re-enabled implementation, Dependabot can still request `packages: read` on its short-lived `GITHUB_TOKEN` when a package grants the repository Manage Actions access, but automatic GitHub Packages credentials are now used only as fallback authentication. Explicit registry credentials and normal registry routing take precedence. ## Why it matters Private dependency automation often accumulates static credentials that have to be created, scoped, rotated and removed. Reusing repository-to-package access plus a short-lived job token still reduces that secret-management surface for teams whose private packages live on GitHub. The rollback also exposes an important dependency-management boundary: authentication convenience must not silently change registry selection. GitHub's fallback-only design is therefore more conservative than the original implementation and gives explicit package-routing configuration precedence. ## The September release is a corrected re-enable, not the first launch GitHub initially shipped automatic GitHub Packages credentials for Dependabot on June 23, 2026, then temporarily rolled the feature back after some npm jobs resolved public dependencies through GitHub Packages. The September 8 release restores the feature with changed precedence behavior. ## Automatic package credentials now sit behind explicit configuration A package owner can grant the repository read access under Manage Actions access. Dependabot can then use its job `GITHUB_TOKEN` for qualifying GitHub Packages or `ghcr.io` pulls, but GitHub says this automatic credential is now fallback authentication. Explicit registry credentials and normal package-manager routing continue to take precedence. ## PATs can still be removed for qualifying GitHub-hosted packages When a GitHub-hosted private package is reachable through the repository grant and no separate credential is needed, teams can remove PAT-backed registry entries that existed solely for Dependabot. The corrected behavior does not change the core secret-reduction benefit. ## Third-party and private-network registries remain separate Artifactory, Azure Artifacts, Nexus and other registries continue to use their own token, password or OIDC configuration. Private-network registries may also require self-hosted Dependabot runners or network allowlisting. ## Key details - GitHub first released automatic Dependabot access to GitHub-hosted registries on June 23, 2026. - GitHub temporarily rolled the feature back after some npm update jobs routed public package resolution through GitHub Packages. - The feature was re-enabled on September 8, 2026. - Automatic GitHub Packages credentials are now used only as fallback authentication. - Explicit registry credentials and normal registry routing take precedence. - Dependabot can request `packages: read` on its short-lived `GITHUB_TOKEN`. - A private GitHub package must grant the repository access through Manage Actions access. - PAT-based registry entries can be removed where they existed solely for qualifying GitHub-hosted package access. - Third-party registries retain separate authentication requirements. ## Builder takeaways - Do not treat authentication configuration and registry routing as the same problem; verify both after removing a PAT. - Prefer explicit registry routing where package names or scopes could resolve from more than one source. - Replace PAT-based Dependabot credentials for GitHub Packages only after confirming the required package grants the repository read access. - Run Dependabot update jobs after migration and inspect which registry each dependency resolves from, especially in npm setups with mixed public and private packages. - Keep GitHub-hosted and third-party registry configuration separate so teams do not assume the fallback token path covers other artifact systems. ## What to watch - Whether GitHub publishes additional details about the June routing conflict or further safeguards for mixed-registry npm configurations. - Organization-level tooling for auditing repository-to-package grants and automatic Dependabot credentials. - Broader OIDC adoption for third-party registries. - Whether automatic package credentials expand beyond GitHub-hosted registries without weakening explicit routing controls. ## Uncertainties - GitHub's editor note identifies the routing conflict but does not publish a detailed incident analysis or quantify how many Dependabot jobs were affected. - The fallback design reduces routing risk but teams with complex package-manager configuration should still verify actual registry resolution. - Third-party and private-network registry workflows retain different authentication and connectivity requirements. ## Sources - [Automatic Dependabot access to GitHub-hosted registries](https://github.blog/changelog/2026-09-08-automatic-dependabot-access-to-github-hosted-registries/) — GitHub · primary changelog · 2026-09-08T00:00:00+12:00. Primary release source, including the editor note documenting the June 23 initial release, temporary rollback and fallback-only re-enable. - [Configuring access to private registries for Dependabot](https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries) — GitHub Docs · primary documentation. Current implementation guidance and boundary with explicit/third-party registry credentials.