MEDIUM 5.5

CVE-2026-9106: GitHub Enterprise Server OAuth Scope Misrepresentation Vulnerability

GitHub Enterprise Server contained a vulnerability where an OAuth application scope related to runner management was not displayed to users during authorization. This allowed an attacker to trick a user into granting an application access to manage organization runners without the user's informed consent. The vulnerability affected all versions prior to 3.22 and has been patched in multiple maintenance releases across supported version lines.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:L
Weaknesses (CWE)
CWE-451
Affected products
1 configuration(s)
Published / Modified
2026-06-30 / 2026-07-02

NVD description (verbatim)

A UI misrepresentation vulnerability was identified in GitHub Enterprise Server that allowed an OAuth application to gain unintended access to an organization's runner management. An attacker could exploit this by creating an OAuth application requesting the manage_runners:org scope and directing a victim user to authorize it, as the scope was not displayed on the authorization consent screen. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.21.2, 3.20.4, 3.19.8, 3.18.11, 3.17.17, 3.16.20. This vulnerability was reported via the GitHub Bug Bounty program.

6 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-9106 is a UI misrepresentation flaw in GitHub Enterprise Server's OAuth authorization flow. The manage_runners:org scope was not rendered on the consent screen presented to users authorizing third-party applications. An attacker could craft an OAuth app requesting this scope and socially engineer a victim into approving authorization, resulting in the application gaining unintended access to organization runner management functions. The vulnerability stems from incomplete scope disclosure (CWE-451: User Interface Misrepresentation of Critical Information) and requires both the attacker to create a malicious OAuth app and a user to authorize it, making exploitation dependent on social engineering rather than a direct technical attack.

Business impact

Organization runners are critical infrastructure for CI/CD automation. Unauthorized access to runner management could allow an attacker to modify runner configurations, inject malicious jobs, access runner secrets, or disrupt build pipelines. The scope of impact is limited to users who authorize the malicious OAuth application, but a successful breach could compromise the integrity of software delivery for affected organizations. The risk is heightened for organizations using runners for sensitive deployments or where supply chain integrity is critical.

Affected systems

GitHub Enterprise Server versions prior to 3.22 are affected. Patches are available for: 3.21.2, 3.20.4, 3.19.8, 3.18.11, 3.17.17, and 3.16.20. Organizations on unsupported versions (3.15 and earlier) cannot receive patches and should prioritize upgrade planning. The vulnerability affects any user who authorizes an OAuth application on an unpatched instance.

Exploitability

Exploitation requires two steps: (1) attacker creates an OAuth application requesting the manage_runners:org scope, and (2) attacker socially engineers a target user to authorize the application. Because the scope was not displayed, users had no warning they were granting runner management access. The attack is not remotely exploitable without user interaction, making it moderate in difficulty but highly feasible via phishing or supply chain tactics. No public exploit code or active exploitation has been reported.

Remediation

Apply the appropriate security patch immediately: identify your current GitHub Enterprise Server version and upgrade to the corresponding patched release (3.21.2, 3.20.4, 3.19.8, 3.18.11, 3.17.17, or 3.16.20 depending on your version line). Organizations on end-of-life versions should plan an upgrade to a supported release. After patching, review authorized OAuth applications within your organization, revoke any untrusted or unfamiliar applications, and audit runner access logs for unauthorized modifications.

Patch guidance

Patches are available across six version lines. Verify your current GitHub Enterprise Server version via the management console or CLI. Consult the official GitHub Enterprise Server release notes to confirm the exact patch version for your line and apply it following your standard change management procedures. Patches should be tested in a non-production environment before broad deployment. Organizations unable to patch immediately should restrict OAuth application authorizations and monitor runner activity closely.

Detection guidance

Review the list of authorized OAuth applications in your organization (Organization Settings > Developer Settings > OAuth Apps). Look for unfamiliar applications, especially those with authorization timestamps coinciding with unexpected user activity. Audit GitHub Enterprise Server logs for unusual runner modifications, failed job executions, or configuration changes. If you detect suspicious activity, revoke the application's access immediately and review the runner's access history and recent job logs. Consider implementing policies that restrict which users can authorize OAuth applications.

Why prioritize this

This vulnerability merits prompt but measured attention. The CVSS 3.1 score of 5.5 (MEDIUM) reflects the requirement for user interaction and limited scope, but the business impact is significant: runner compromise could lead to supply chain attacks or secrets exposure. The vulnerability is not in the CISA Known Exploited Vulnerabilities (KEV) catalog, indicating no documented active exploitation at time of publication. Organizations should prioritize patching based on the sensitivity of their CI/CD infrastructure and the likelihood of social engineering attacks within their user base.

Risk score, explained

The CVSS 3.1 score of 5.5 reflects: Network-accessible attack vector (AV:N) with low attack complexity (AC:L), requiring authenticated access (PR:L) and user interaction (UI:R). Impact is limited to confidentiality, integrity, and availability of runner-related functions (C:L/I:L/A:L) within a single organizational scope (S:U). The score appropriately captures that while the vulnerability is easily exploitable via social engineering, its impact is scoped to users who authorize the malicious application and the systems it can control. However, the business risk may exceed the numerical score for organizations with sensitive CI/CD pipelines.

Frequently asked questions

Could this vulnerability allow an attacker to access source code or secrets stored in runners?

Potentially, yes. If an OAuth application gains manage_runners:org access, it could modify runner environment variables, inject jobs that exfiltrate secrets, or alter configurations. The actual damage depends on what secrets are stored in the runner environment and what code it executes. This is why revoking unauthorized OAuth apps and auditing runner activity is critical.

Do I need to patch immediately, or can I wait for our next maintenance window?

We recommend prioritizing this patch within 1-2 weeks. The vulnerability requires social engineering and user interaction, so it's not an imminent zero-day. However, because the scope was hidden from users, the risk of users unknowingly authorizing malicious apps is real. If your organization has not experienced suspicious OAuth authorizations, a standard maintenance window is acceptable; if you have detected suspicious activity, patch sooner.

What should I do if I find an unfamiliar OAuth application that was authorized on our instance?

Revoke its access immediately via Organization Settings > Developer Settings > OAuth Apps > Revoke. Then review the application's access logs to determine what actions it performed—check for runner modifications, job executions, or secret access. If you find suspicious activity, reset any credentials that might have been exposed and contact GitHub support for further investigation. Consider rotating secrets stored in runner environments as a precaution.

Is there a way to prevent users from authorizing OAuth applications without administrator approval?

Yes. GitHub Enterprise Server allows administrators to implement OAuth application policies, such as requiring approval for third-party applications or restricting which scopes can be requested. Review your organization's OAuth policies in the security settings and consider enabling additional controls if your risk tolerance is high.

This analysis is based on the official CVE record and GitHub's published advisory. The specific patch versions and availability should be verified against the official GitHub Enterprise Server release notes before deployment. No public exploit code or active exploitation has been confirmed as of the publication date. Organizations should assess their specific risk posture based on their OAuth policies, user training, and CI/CD criticality. This is not a substitute for vendor guidance or professional security assessment. Source: NVD (public-domain), retrieved 2026-08-09. Analysis generated by SEC.co (claude-haiku-4-5).