Skip to main content

GitHub MCP Server CVE-2026-48529

| EUVDEUVD-2026-39809 MEDIUM
Improper Access Control (CWE-284)
2026-06-25 https://github.com/github/github-mcp-server GHSA-pjp5-fpmr-3349
6.0
CVSS 3.1 · Vendor: https://github.com/github/github-mcp-server
Share

Severity by source

Vendor (https://github.com/github/github-mcp-server) PRIMARY
6.0 MEDIUM
AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L
vuln.today AI
6.0 MEDIUM

AC:H for multi-user timing dependency; PR:L for required valid auth token; S:C because sanitization failure crosses into the AI model trust boundary.

3.1 AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L
4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:L/SA:N
SUSE
MEDIUM
qualitative

Primary rating from Vendor (https://github.com/github/github-mcp-server).

CVSS VectorVendor: https://github.com/github/github-mcp-server

Attack Vector
Network
Attack Complexity
High
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
Low
Integrity
Low
Availability
Low

Lifecycle Timeline

3
Source Code Evidence Fetched
Jun 25, 2026 - 21:51 vuln.today
Analysis Generated
Jun 25, 2026 - 21:51 vuln.today
CVE Published
Jun 25, 2026 - 21:32 github-advisory
MEDIUM 6.0

DescriptionCVE.org

Summary

When running in HTTP mode with --lockdown-mode enabled, the RepoAccessCache is implemented as a process-global singleton initialized with the first authenticated user's GraphQL client. All subsequent requests from different users share this singleton and their lockdown-related GraphQL queries are executed using the first user's credentials. The singleton is never updated to reflect later users' tokens.

Details

The singleton is defined in pkg/lockdown/lockdown.go:

go
var (
    instance   *RepoAccessCache
    instanceMu sync.Mutex
)

func GetInstance(client *githubv4.Client, opts ...RepoAccessOption) *RepoAccessCache {
    instanceMu.Lock()
    defer instanceMu.Unlock()
    if instance == nil {
        instance = &RepoAccessCache{
            client: client,  // only stored on first call
        }
    }
    return instance  // subsequent callers receive the same object regardless of their client
}

In HTTP mode, pkg/github/dependencies.go calls this per request:

go
func (d *RequestDeps) GetRepoAccessCache(ctx context.Context) (*lockdown.RepoAccessCache, error) {
    gqlClient, err := d.GetGQLClient(ctx)  // creates client with request's token
    ...
    instance := lockdown.GetInstance(gqlClient, d.RepoAccessOpts...)
    // gqlClient is silently dropped if singleton already exists
    return instance, nil
}

The singleton's internal client field is never updated after the first initialization. All lockdown GraphQL queries that check repository access and visibility (queryRepoAccessInfo, called by IsSafeContent) run under the first authenticated user's token for the lifetime of the process.

IsSafeContent is called in at least six places across pkg/github/issues.go and pkg/github/pullrequests.go to decide whether to trust or sanitize content from external contributors.

PoC

The following program demonstrates that two distinct GraphQL clients produce the same singleton pointer, confirming that the second client is discarded:

go
package main

import (
    "fmt"
    "net/http"
    "github.com/github/github-mcp-server/pkg/lockdown"
    "github.com/shurcooL/githubv4"
)

func main() {
    httpClientA := &http.Client{}
    httpClientB := &http.Client{}
    gqlClientA := githubv4.NewEnterpriseClient("https://api.github.com/graphql", httpClientA)
    gqlClientB := githubv4.NewEnterpriseClient("https://api.github.com/graphql", httpClientB)

    fmt.Printf("gqlClientA (user A token): %p\n", gqlClientA)
    fmt.Printf("gqlClientB (user B token): %p\n", gqlClientB)
    fmt.Printf("clients are different objects: %v\n\n", gqlClientA != gqlClientB)

    instanceForA := lockdown.GetInstance(gqlClientA)
    instanceForB := lockdown.GetInstance(gqlClientB)

    fmt.Printf("lockdown instance returned for user A: %p\n", instanceForA)
    fmt.Printf("lockdown instance returned for user B: %p\n", instanceForB)
    fmt.Printf("same singleton returned for both users: %v\n", instanceForA == instanceForB)
}

Output:

gqlClientA (user A token): 0x400044070
gqlClientB (user B token): 0x400044078
clients are different objects: true

lockdown instance returned for user A: 0x400002ecc0
lockdown instance returned for user B: 0x400002ecc0
same singleton returned for both users: true

<img width="1642" height="450" alt="image" src="https://github.com/user-attachments/assets/bec46420-9ba7-458e-8710-62f951cb836a" />

Impact

This affects deployments running the HTTP server with --lockdown-mode, which is the intended configuration for multi-user scenarios such as GitHub Copilot's managed MCP endpoint.

Three concrete consequences:

First, the ViewerLogin field in cache entries always reflects the first authenticated user's identity. The IsSafeContent check repoInfo.ViewerLogin == strings.ToLower(username) compares this stale value against each subsequent user's login, producing incorrect results for all users except the first.

Second, repository visibility and collaborator access data stored in the cache is evaluated through the first user's token. If user A cannot see a private repository but user B can (or vice versa), the cached isPrivate and hasPushAccess values will reflect user A's view of that repository, causing IsSafeContent to return wrong decisions for user B. In lockdown mode, a wrong true result means potentially injected content from untrusted external contributors is passed to the model without sanitization.

Third, if the first user's token is revoked or expires, all subsequent lockdown GraphQL queries fail with authentication errors. Since getRepoAccessInfo propagates these errors, IsSafeContent returns an error for every request, breaking lockdown protection for all users until the process is restarted.

AnalysisAI

Lockdown mode in GitHub MCP Server HTTP deployments (versions 0.22.0-1.1.1) fails to isolate per-user GraphQL credentials due to a process-global singleton that retains the first authenticated user's client for the lifetime of the process. All subsequent users' IsSafeContent checks-the security gate that decides whether content from external contributors is sanitized before reaching the AI model-are evaluated under the first user's GitHub token and identity, producing wrong access control decisions for every user except the first. A publicly available proof-of-concept confirms the singleton pointer collision; no active exploitation (CISA KEV) has been confirmed at time of analysis.

Technical ContextAI

GitHub MCP Server is a Go-based Model Context Protocol (MCP) server that exposes GitHub APIs to AI models such as GitHub Copilot. When deployed in HTTP mode with --lockdown-mode, the server's RepoAccessCache (pkg/lockdown/lockdown.go) is intended to prevent prompt injection by verifying, per request, whether repository content originates from a trusted collaborator before passing it to the model. The implementation employs a process-global singleton (var instance *RepoAccessCache guarded by sync.Mutex), but the initialization guard only stores the githubv4.Client on the very first call-subsequent calls silently receive the existing singleton, discarding the per-request client derived from each user's OAuth token. This violates per-request credential isolation. The root cause maps to CWE-284 (Improper Access Control): the authorization decision function IsSafeContent, called in at least six locations across pkg/github/issues.go and pkg/github/pullrequests.go, executes its GraphQL queries under stale credentials, corrupting all three checks it performs: ViewerLogin identity comparison, repository visibility (isPrivate), and collaborator access (hasPushAccess). Affected package: pkg:go/github.com_github_github-mcp-server, versions >= 0.22.0 < 1.1.2.

RemediationAI

Upgrade github-mcp-server to version 1.1.2 or later, which resolves the singleton credential confusion per the vendor advisory at https://github.com/github/github-mcp-server/security/advisories/GHSA-pjp5-fpmr-3349. If an immediate upgrade is not possible, switch to stdio (single-user) deployment mode, which eliminates the shared-singleton scenario entirely at the cost of multi-user capability. As a temporary measure, restrict the HTTP endpoint to a single trusted user-this prevents cross-user credential leakage but forfeits the multi-user design intent. Restarting the server process re-seeds the singleton from the next first-authenticating user, providing only transient relief and not a sustainable workaround. There is no configuration-level mitigation that preserves multi-user HTTP mode with correct lockdown semantics prior to the 1.1.2 fix.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Server 16.1 Affected
SUSE Linux Enterprise Server for SAP applications 16.1 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5 Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6 Affected
openSUSE Leap 15.5 Affected

Share

CVE-2026-48529 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy