- CVE-2026-96890 let a user with push access make GitHub Enterprise Server send requests to internal hosts, which could be chained to remote code execution.
- The flaw sat in secret scanning's validity check and affected only instances with GitHub Advanced Security and that check enabled, a non-default setup.
- Check your version against fixes 3.20.9, 3.21.7 and 3.22.2, and ask who holds push rights and what the appliance can reach.
Picture a bouncer who doubts an ID, so he phones the number printed on it. The forger answers. That is the shape of CVE-2026-96890, a flaw in GitHub Enterprise Server. A security feature believed the document it was inspecting.
What GitHub and NIST describe
The NIST National Vulnerability Database (NVD) published the record on October 6, 2026. It describes a Server-Side Request Forgery (SSRF) flaw. SSRF means an attacker makes a server send requests the attacker could not send directly. Here, a repository contributor could make the appliance contact attacker-controlled internal hosts.
NVD also says the flaw could be combined with other steps to let an attacker run code on the appliance itself. That would put the attacker's commands on the machine that holds the company's source code. The record does not describe the steps of that chain.
How the flaw works
Secret scanning looks for credentials that developers commit by mistake. Some scanners also run a validity check. They test whether a found credential still works, so teams can fix live leaks first.
The affected check covered GCP service account credentials. Such a credential carries the address of a token endpoint, the server that issues access tokens. According to the record, the validator trusted that address and sent a request to it. It did not restrict the destination.
So the attacker controlled where the request went. A committed file could point the appliance at an internal host. The appliance sits inside the company network, so it can often reach systems that outsiders cannot.
Who was exposed, and who was not
The record sets clear limits. An attacker first needed a logged-in account that could push code to a repository. The server also had to have two features switched on: GitHub Advanced Security, and validity checks within secret scanning. NVD describes that combination as not the default.
That narrows the risk. Instances without those settings are outside the scenario the record describes. The flaw touched the 3.20, 3.21 and 3.22 release lines.
The score reflects the low barrier. The CVSS 3.1 vector shows network access, low complexity, low privileges and no user interaction. In plain words, a user who already has an ordinary account and push rights needs nothing else from anyone.
The lesson: protective tools read hostile input
This is the publication's view, drawn from one case. A secret scanner exists to read what developers push, and developers include people you only partly trust. A feature built to inspect untrusted content must treat that content as untrusted. Here, the content told the tool where to connect, and the tool went.
The extra cost is easy to miss. The exposure came from switching on an added security capability, not from leaving one off. Many added scanners or validators add code that reads untrusted material, and some make network calls. Each deserves the same review as the systems it protects.
The record says the issue came through the GitHub Bug Bounty program. It does not report exploitation in the wild.
What to ask your team
Start with facts, not worry. Ask these questions this week:
Which GitHub Enterprise Server version do we run? Is it at or above 3.20.9, 3.21.7 or 3.22.2 for its release line?
Is Advanced Security switched on here, and do our secret scans test whether found credentials still work? If either is off, the scenario in the record does not apply.
Who holds push permission, and does that include contractors or external contributors?
What internal hosts can the appliance reach? Limiting its outbound access shrinks what any request-forgery flaw can touch.
Do we review the network behaviour of our security tools as closely as that of our applications?
A scanner that phones the number on the ID will eventually reach a forger. The fix is to decide in advance which numbers it may call.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
