GitHub Enterprise Server CVE-2026-14340

Exploitation requires the attacker to possess a valid user-to-server token issued by a GitHub App installation on the target GHES instance; this is a hard prerequisite and not trivially obtained. The target repositories must be public. The vulnerability is specific to tokens issued by global GitHub App installations where the authorization logic omitted the repository-scope binding check. Exploitation is limited to four write-action types: creating issues, issue comments, commit comments, and private vulnerability reports - broader write operations such as pushing code or modifying repository settings are not in scope. Authentication to the GHES instance is required via the stolen token (PR:L); unauthenticated exploitation is not possible.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) is consistent with the description: exploitation is network-accessible and requires no user interaction, but the attacker must already possess a victim's user-to-server token (PR:L), and the integrity impact is constrained to low-consequence write actions such as issue and comment creation. No EPSS data was provided; however, given the medium CVSS score, token-theft prerequisite, and the absence of both KEV listing and public exploit code, real-world risk is moderate rather than critical. The most likely threat actor is an insider or someone who has already compromised a user's OAuth token through a separate attack. The absence of confidentiality impact (VC:N, VA:N) and the restriction to public repositories further narrow the blast radius. Security teams running GHES should treat this as a priority patch within their normal maintenance window rather than an emergency response.

An attacker who has separately obtained a victim's user-to-server token - for example through phishing, credential theft, or a compromised OAuth flow - submits API requests to a public repository that the victim's GitHub App installation does not explicitly cover. Because GHES only validates read-access by the installation rather than explicit installation-to-repository binding, the server accepts the request and creates an issue, comment, or private vulnerability report appearing to originate from the victim user. No public exploit code is known to exist at time of analysis.