CVE-2026-0573 is a critical (CVSS 9.0) URL redirection flaw in GitHub Enterprise Server that could leak a privileged token. GitHub fixed it in 3.19.2, 3.18.4, 3.17.10, 3.16.13, 3.15.17 and 3.14.22. Upgrade your instance to the fixed release for its line.
What's affected
Per the record, all GitHub Enterprise Server versions before 3.19 were affected, and the fixes are in these releases:
- 3.19.2
- 3.18.4
- 3.17.10
- 3.16.13
- 3.15.17
- 3.14.22
GitHub says it was reported through its Bug Bounty program. An attacker needs an authenticated account on the instance, and needs a legacy redirect to a domain they control.
How to check if you're exposed
On the appliance, over SSH:
ghe-version
The Site Admin dashboard also shows the version. Compare it with the fixed releases for your line. Then list who holds accounts on the instance and whether sign up is open, since the attacker needs a login.
What to do now
- Upgrade to the fixed release for your line, taking a backup first with the usual backup utilities.
- Read the release notes for the release you choose, which list the fix and other security items.
- Review who can create accounts, and remove stale accounts.
- Review audit logs for unusual calls to the repository pages API.
- Rotate any credentials that your policy treats as exposed if logs suggest abuse.
Upgrade in a planned window. GitHub Enterprise Server updates are applied to the appliance, and the vendor documents a backup and upgrade process for each release line. Take a backup with the backup utilities first, and test the upgrade on a staging instance if you have one.
Check which release line you are on before you pick a target. The record lists a fixed release for each of 3.14 through 3.19, so you do not need to jump a line to get the fix. If your line is older than 3.14, you are outside the fixed list and should plan a move to a supported line.
Afterward, check Actions and organisation settings for changes you did not make. The token described in the record has rights to manage organisations in Actions, so unexpected runner, secret or workflow changes are the signs to look for. Rotate any secrets stored in Actions if you find them.
Why it matters
The weakness is CWE-601 (open redirect). The repository pages API followed HTTP redirects when it fetched artifact URLs, and it kept the authorization header on the redirected request. A user could point the request at their own domain, which then received a privileged JWT, described as an Actions.ManageOrgs token. The record says that could be used for potential remote code execution.
The lesson is to strip credentials when a request is redirected to a different origin. The record does not mark it as exploited, and it is not in the CISA KEV list.
Self hosted source control is a high value target, because it holds code, secrets and build triggers. Treat upgrades as routine work with a short deadline.
The weakness is a quiet one. Following a redirect is normal behaviour for an HTTP client. The danger is carrying credentials to the new location. Good clients drop the authorization header when a redirect goes to a different host, and that is the fix pattern for this class. Any server side code that fetches a URL on behalf of a user should be reviewed for it.
The privileged token in this case is also worth thinking about. The record names a token with rights to manage organisations in Actions. Tokens like that exist inside every large platform. They are short lived by design, but short lived is not the same as harmless, and a stolen token is useful for as long as it is valid.
Last, notice who the attacker has to be. The record requires an authenticated user, so the risk is highest on instances with many users or with open registration. Instances with a small, trusted group have lower exposure, though the upgrade is still the right answer.
Try it yourself
Source control servers hold the code that gates run on. A pull request gate keeps risky changes from landing while you patch.
Click through it at your own pace, or open it full screen.
Quick check
Do I need an account to exploit it?
Yes. The record says an authenticated user is required, plus access to the instance.
Which version fixes the 3.18 line?
3.18.4, per the record.
Is the attacker an outsider?
No. The record describes an authenticated user on the target instance.
If you want a quick look at your own dependencies, the free in-browser scan at gold.safeguard.sh/scan needs no repository access.
Sources
Fetched for this guide:
Also referenced by the CVE record:
- https://docs.github.com/en/enterprise-server@3.18/admin/release-notes#3.18.4
- https://docs.github.com/en/enterprise-server@3.14/admin/release-notes#3.14.22
Last reviewed: 19 October 2026.
