GitHub Enterprise Server CVE-2026-4296

Exploitation requires all of the following concrete prerequisites: (1) the attacker must know a first-party OAuth application's registered callback URL on the target GitHub Enterprise Server instance (the AT:P attack requirement); (2) the attacker must craft a malicious authorization link whose redirect_uri abuses the incorrect redirect-URI validation regex; and (3) a victim must actively click that link while authenticated, so the authorization flow completes (UI:P / passive user interaction). Limiting factors that reduce realistic risk: the CVSS vector indicates low-privilege access is needed (PR:L), the attack is not automatable per CISA SSVC, and the resulting access is bounded by the scopes granted to the abused OAuth application. Instances on 3.21+ or any of the fixed point releases are not affected.

Signals point to a genuine but not urgent, mass-scannable threat. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:P) shows the attack is network-borne but gated by three real hurdles: a present attack requirement (AT:P - knowing the registered callback URL), low-privilege access (PR:L), and passive victim interaction (UI:P - the victim must click the malicious link). Technical impact is rated 'total' (VC:H/VI:H/VA:H) reflecting full account compromise, but SSVC marks Exploitation: none and Automatable: no, and EPSS is 0.05% (15th percentile) - consistent with a targeted, social-engineering-dependent attack rather than worm-like exploitation. There is no KEV listing and no known POC. Note a tension worth flagging: the VA:H (availability) rating is generous for what is fundamentally a token-theft/account-access issue whose real impact is bounded by the compromised OAuth app's scopes; confidentiality and integrity impact are the substantive risks. Overall: a legitimate account-takeover vector that merits prompt patching but is not a drop-everything, internet-wide emergency.

An attacker who knows the registered callback URL of a first-party OAuth app on a target GHES instance crafts an authorization link whose redirect_uri passes the flawed regex but resolves to a domain they control. They send the link to a logged-in victim (e.g., via a phishing message); when the victim clicks and their browser completes the authorization flow, the OAuth authorization code is redirected to the attacker's domain, which the attacker exchanges for access to the victim's account within the app's granted scopes. No public exploit code is identified at time of analysis, and success depends on the victim clicking the crafted link.