Severity by source
AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L
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.
Primary rating from Vendor (https://github.com/github/github-mcp-server).
CVSS VectorVendor: https://github.com/github/github-mcp-server
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L
Lifecycle Timeline
3DescriptionCVE.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:
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:
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:
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. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires GitHub MCP Server to be running in HTTP server mode with the --lockdown-mode flag explicitly passed at startup-this is not the default single-user (stdio) mode and must be deliberately configured. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The provided CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L, score 6.0 Medium) is consistent with the described behavior. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A threat actor who holds a valid GitHub token authenticates to a shared GitHub MCP Server HTTP instance after a legitimate user has already seeded the RepoAccessCache singleton. When the attacker submits a pull request or issue body containing a prompt injection payload, IsSafeContent evaluates the repository's collaborator status and visibility using the first user's GraphQL credentials rather than the attacker's, potentially returning an incorrect 'safe' verdict and passing the unsanitized, potentially injected content directly to the AI model. … |
| Remediation | 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. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-39809
GHSA-pjp5-fpmr-3349