CVE-2026-3306: 
GitHub Enterprise Server vulnerability analysis and mitigation

CVE-2026-3306 is an improper authorization vulnerability in GitHub Enterprise Server (GHES) that allows a user with read access to a repository and write access to a project to modify issue and pull request metadata — including labels, assignees, and other fields — without possessing repository write permissions. The flaw exists because when adding a duplicate item to a project, column value updates were applied without verifying the actor's repository write permissions. It affects GHES versions prior to 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, and 3.19.3. The vulnerability was disclosed on March 10, 2026, reported via the GitHub Bug Bounty program, and carries a CVSS v3.1 base score of 4.3 (Medium) and a CVSS v4.0 base score of 5.3 (Medium) (GitHub GHES 3.14 Release Notes, Feedly).

The root cause is classified as CWE-639 (Authorization Bypass Through User-Controlled Key), with an estimated classification of CWE-862 (Missing Authorization). The vulnerability resides in the GitHub Projects feature: when a user adds an item to a project that already exists (a duplicate item), the server applies column value updates — such as label or assignee changes — to the underlying issue or pull request without re-verifying that the actor holds write permissions on the associated repository. This means the authorization check is bypassed by exploiting the duplicate-item code path, allowing a low-privileged user (read-only on the repo, write on the project) to tamper with repository metadata. The attack is network-based, requires low privileges, no user interaction, and low complexity (GitHub GHES 3.14 Release Notes, Feedly).

Successful exploitation allows an attacker to modify issue and pull request metadata — including labels, assignees, milestones, and other project column values — on repositories for which they only hold read access. The impact is limited to integrity: there is no confidentiality or availability impact, and the scope is unchanged. While this does not enable code execution or data exfiltration, it could be used to manipulate project tracking, mislabel security-sensitive issues, or interfere with development workflows in enterprise environments (GitHub GHES 3.14 Release Notes, Feedly).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for CVE-2026-3306. The EPSS score is approximately 0.035% (0.000350), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an authenticated user account with at minimum read access to a target repository and write access to a project containing items from that repository, limiting the attacker pool to internal or invited users on a GHES instance (Feedly).

1. Reconnaissance: Identify a GitHub Enterprise Server instance running a vulnerable version (prior to 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, or 3.19.3). Obtain an account with read access to a target repository and write access to a GitHub Project that contains items (issues or pull requests) from that repository.
2. Identify target item: Browse the project board and identify an issue or pull request from the target repository that is already linked to the project.
3. Add duplicate item: Using the GitHub Projects UI or API, attempt to add the same issue or pull request to the project again (creating a duplicate entry). This triggers the vulnerable code path.
4. Modify metadata: During or after the duplicate-add operation, supply updated column values (e.g., new labels, assignees, or custom field values) in the request. Because the authorization check for repository write permissions is skipped in this code path, the server applies the changes to the underlying issue or pull request.
5. Confirm impact: Verify that the issue or pull request metadata has been modified in the repository, despite the actor lacking repository write permissions (GitHub GHES 3.14 Release Notes, Feedly).

• Logs: Audit log entries showing project item additions (project.add_item or equivalent events) by users who do not hold write permissions on the associated repository, particularly where the same issue/PR ID appears added multiple times in quick succession.
• Logs: Issue or pull request metadata change events (label additions/removals, assignee changes) attributed to users with only read access to the repository.
• Network: API requests to GitHub Projects endpoints (e.g., GraphQL addProjectV2ItemById or REST project item endpoints) from accounts that lack repository write access, followed immediately by field update mutations.
• Application: Unexpected changes to issue or pull request labels, assignees, or custom fields that cannot be attributed to users with appropriate repository permissions.

GitHub has released patched versions of GitHub Enterprise Server that address this vulnerability. Administrators should upgrade to one of the following fixed releases as soon as possible: 3.14.24 (note: initially unpublished due to a separate Git version mismatch; use 3.14.25 or later), 3.15.19 (similarly unpublished; use 3.15.20 or later), 3.16.15, 3.17.12, 3.18.6, or 3.19.3. No configuration-based workaround is available; upgrading is the only remediation. GitHub Cloud (GitHub.com) is not affected (GitHub GHES 3.14 Release Notes, GitHub GHES 3.15 Release Notes, GitHub GHES 3.16 Release Notes, GitHub GHES 3.17 Release Notes, GitHub GHES 3.18 Release Notes).

The vulnerability was reported through GitHub's Bug Bounty program and received limited public attention given its medium severity and constrained exploitation prerequisites. Automated CVE tracking services such as CVEFeed, VulDB, and Radar/Offseq indexed the vulnerability shortly after disclosure. No notable independent researcher commentary or significant media coverage has been identified beyond standard CVE aggregation (Feedly).