Security1 publisher2 min readPublished
GitHub Enterprise Server's notebook viewer leaked secrets to attackers who measured response times
GitHub patched CVE-2026-77987, a GitHub Enterprise Server flaw that let an unauthenticated attacker read instance secrets by timing notebook viewer responses. The secrets could yield remote code execution, and with private mode off the attack needed no login.
The Watch · Security desk
What happened
- Those extracted secrets were enough to obtain remote code execution on the appliance itself.
- Exploitation needed no authentication when private mode was disabled, and any authenticated user when private mode was enabled.
- GitHub now rejects notebook viewer URLs that specify an explicit port; it requested CVE-2026-77987 and credited its Bug Bounty program for the report.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure An unpatched instance with private mode off puts its internal secrets, and through them code execution, within reach of any attacker who can send it traffic.
- constraint The absence of returned data is not a mitigation here. Secrets moved through response timing, so watching for exfiltrated response bodies would have caught nothing.
- decision Self-hosted operators carry this fix themselves. The patched behavior applies only after the release is installed, so an unupgraded appliance stays exploitable.
The fix is narrow. GitHub Enterprise Server now rejects any notebook viewer URL that specifies an explicit port. [6] The explicit port gave the attack its reach: with a port named in the URL, the viewer connected to services bound to the appliance itself, not only to hosts on the public internet, and network access to the instance was all an attacker needed to drive it. [1]
The viewer did not send the response bodies back. According to GitHub, response timing still worked as an oracle, so an attacker could measure how long the appliance took to answer and extract instance secrets from the differences. [2] Those secrets were enough to gain remote code execution on the appliance. [3]
Whether a login was required came down to private mode. With private mode disabled, exploitation was unauthenticated; with private mode enabled, any authenticated user could run it. [4] GitHub requested CVE-2026-77987 for the flaw, which was reported through its Bug Bounty program. [5][7]
The same release notes carry a stored cross-site scripting bug rated high, CVE-2026-77912. An authenticated attacker could run scripts in another user's browser by posting crafted Markdown, such as an issue comment, that injected arbitrary HTML attributes into the rendered page. [8] It was possible because the Markdown rendering pipeline rewrote quote characters in already-sanitized HTML without re-sanitizing the result. [9] Successful exploitation let the attacker read what the victim could see, act as the victim, exfiltrate data, and spread the payload with the victim's write access. [10]
Two more changes tightened authorization. GitHub Packages had let an attacker who obtained the identifiers for an in-progress upload corrupt it, because the registry did not check permissions before continuing or completing the upload; GitHub now validates authorization before any change is made. [11] Server reports under /stafftools/reports/ had been reachable with a legacy non-expiring token, which now requires a personal access token (classic) with the site_admin scope. [12]
What to watch
- Whether a working proof-of-concept for CVE-2026-77987 appears publicly now that the fix and mechanism are documented.
- Whether GitHub publishes CVE-2026-77987 with a CVSS score and affected version range beyond the release notes.
- Any reports of exploitation against unpatched GHES appliances left with private mode disabled.