GitHub Copilot and Visual Studio Code Security Feature Bypass Vulnerability

GitHub Copilot and Visual Studio Code Elevation of Privilege Vulnerability

GitHub CLI (gh) is GitHub’s official command line tool. Prior to 2.97.0, gh attestation verify  builds the certificate Subject Alternative Name matcher from the --signer-repo and --signer-workflow  flag values without escaping regex metacharacters, so a user-supplied repository or workflow name is treated as a regular expression rather than a literal string. Because GitHub permits characters such as  .  in organization, repository, and workflow path names and  .  is a regex wildcard, an attacker can register a lookalike name (for example github/artifact.attestations-workflows) that satisfies a matcher intended for a different trusted signer (github/artifact-attestations-workflows), bypassing the intended Sigstore attestation verification. Exploitation requires the attacker to create a plausible lookalike repository and produce valid attestations from it, which could undermine supply chain verification for CI/CD pipelines or policy gates that pin trust to a specific signing workflow. This issue is fixed in version 2.97.0.

GitHub CLI (gh) is GitHub's official command line tool. Prior to version 2.97.0, gh auth status masked only the characters after the last underscore in certain fine-grained personal access tokens and GitHub App tokens. As a result, part of an affected token could appear in terminal or CI output that is captured or shared. Authenticated users are affected if they ran gh auth status (without the --show-token flag) with a token type whose format contains an underscore after the prefix. This includes fine-grained personal access tokens (githubpat) and GitHub App installation and user access tokens (ghs, ghu; for example, ghs<APPID><JWT>), as well as the Actions GITHUBTOKEN. Classic tokens such as gho and ghp have an underscore-free body and are not affected. This issue is fixed in version 2.97.0.

GitHub CLI (gh) is GitHub’s official command line tool. Prior to 2.97.0, some HTTP request URLs interpolate variable path components without percent encoding, allowing URL path metacharacters in attacker-controlled repository or resource values to make gh address a different API endpoint or resource than the user intended. This issue is fixed in version 2.97.0.

GitHub CLI (gh) is GitHub's official command line tool. Prior to version 2.97.0, multiple GitHub CLI commands printed externally controlled gist, API, pull request, release, codespace, skill, or agent-task content without neutralizing terminal escape sequences. An attacker who can influence that content can embed escape sequences that are interpreted by the terminal of a user who runs an affected command, with impact ranging from cosmetic manipulation of the title or on-screen content to, on some terminal emulators, command execution. This extends the same class of issue as CVE-2026-45803—which addressed only gh run view --log—to the other affected command paths. This issue is fixed in version 2.97.0.

A denial of service vulnerability was identified in GitHub Enterprise Server that allowed an unauthenticated attacker to cause excessive CPU consumption and exhaust the pool of request-handling worker processes by sending a crafted form-encoded HTTP POST request containing deeply nested parameters. Because request parameters were parsed before routing and authentication, any POST endpoint could be used to trigger the condition, which could render the instance unresponsive. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21 and was fixed in versions 3.20.3, 3.19.7, 3.18.10, and 3.17.16.

A path traversal vulnerability was identified in GitHub Enterprise Server that allowed an unauthenticated attacker to delete arbitrary files and directories on the instance, including the entire user storage directory containing Git LFS objects, release assets, attachments, and avatars. The X-GitHub-Request-Id request header was used without sanitization as a filesystem path segment for the upload buffer directory, so a traversal value pointed the buffer at an arbitrary path and the deferred cleanup routine recursively removed the traversed target. Exploitation required only network reachability to the instance and no authentication, and it worked even when private mode was enabled. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.21.4, 3.20.6, 3.19.10, 3.18.13 and 3.17.19. This vulnerability was reported via the GitHub Bug Bounty program.

GitHub CLI (gh) is GitHub’s official command line tool. From 2.10.0 through 2.95.0, connecting to a malicious Codespace with gh codespace jupyter can allow command execution because the command opens a JupyterLab URL supplied by a process inside the Codespace without validating that it is a loopback HTTP or HTTPS address, allowing a crafted vscode:// or vscode-insiders:// URL to be handed to VS Code. This issue is fixed in version 2.96.0.

Summary

A nil pointer dereference vulnerability in the GitHub MCP Server causes it to crash when receiving a malformed completion/complete request with missing or empty parameters. This allows any unauthenticated client to cause a complete denial of service.

Details

The CompletionsHandler function in pkg/github/server.go:198 accesses params.Ref without checking if it's nil first. When a client sends a completion/complete request with a missing ref field, the handler dereferences nil and the Go runtime panics.

The crash occurs before any authentication or token validation, so even requests with fake tokens can trigger it.

PoC

After completing the MCP initialization handshake, send either:

Empty params:

{"jsonrpc":"2.0","id":2,"method":"completion/complete","params":{}}

Missing ref field:

{"jsonrpc":"2.0","id":2,"method":"completion/complete","params":{"argument":{"name":"x","value":"y"}}}

Result:

panic: runtime error: invalid memory address or nil pointer dereference goroutine 42 [running]: github.com/github/github-mcp-server/pkg/github.NewMCPServer.CompletionsHandler.func1(...) pkg/github/server.go:198 +0x24

Impact

Any unauthenticated client that can send JSON-RPC messages to the server can crash it immediately. This is a complete denial of service - the panic is unrecoverable and kills the process.

Automated fuzzing with mcpsec found 108 crashes out of 925 test cases (11.7% crash rate).

Timeline

- Feb 21, 2026 - Initial report sent to opensource-security@github.com - Mar 03, 2026 - Follow-up email sent, no response - Mar 21, 2026 - Re-verified on v0.33.0, sent detailed report with PoC, no response - Apr 06, 2026 - GHSA filed after 44 days without acknowledgment

Suggested Fix

func (s Server) CompletionsHandler(ctx context.Context, params mcp.CompleteParams) (mcp.CompleteResult, error) { if params == nil || params.Ref == nil { return nil, fmt.Errorf("invalid request: missing ref parameter") } // ... rest of handler }

A server-side request forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed an unauthenticated attacker to send crafted requests to internal services by exploiting insufficient input validation in an upload endpoint. By injecting path traversal content into request parameters, an attacker could bypass the intended request flow and redirect internal API calls, potentially accessing internal services and exposing sensitive credentials. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.17.17, 3.18.11, 3.19.8, 3.20.4, and 3.21.2. This vulnerability was reported via the GitHub Bug Bounty program.

A Server-Side Request Forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed an attacker to cause the server to issue HTTP requests to internal services via the security advisories package lookup feature. By directing requests to an internal management service and measuring response timing, an attacker could infer the values of sensitive environment variables, including signing secrets and private keys. Exploitation required GitHub Packages to be enabled; on instances not running in private mode the vulnerability was exploitable without authentication, otherwise any authenticated user could exploit it. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21.1 and was fixed in versions 3.20.3, 3.19.7, 3.18.10, 3.17.16, and 3.16.19. This vulnerability was reported via the GitHub Bug Bounty program.

Summary

GitHub CLI incorrectly includes an authorization header in API requests to TUF repository mirrors via gh attestation, gh release verify, and gh release verify-asset commands.

Affected users:

- Authenticated github.com users who previously ran gh attestation commands, gh release verify, or gh release verify-asset: the github.com token was included in requests to tuf-repo.github.com, a GitHub Pages domain that is not a GitHub API endpoint. All authentication types are affected. - Users with GHENTERPRISETOKEN or GITHUBENTERPRISETOKEN set who previously ran gh attestation commands, gh release verify, or gh release verify-asset: the enterprise token was included in requests to external hosts tuf-repo-cdn.sigstore.dev and tmaproduction.blob.core.windows.net. These hosts are not operated by GitHub.

Details

The CLI uses a shared HTTP client with an authentication layer that automatically attaches tokens to outgoing requests. This layer lacks accurate host detection and can incorrectly attribute the target host, providing it with a token it should never receive.

Specifically, the host normalization logic collapses any .github.com subdomain to github.com, so a request to tuf-repo.github.com (a GitHub Pages site, not a GitHub API endpoint) is treated as a request to github.com and receives the user's github.com token. For hosts that don't match github.com or a known GHES instance at all, the resolver falls back to GHENTERPRISETOKEN if set.

The gh attestation, gh release verify and gh release verify-asset commands fetch data from several external hosts as part of their normal operation (TUF metadata from tuf-repo.github.com and tuf-repo-cdn.sigstore.dev, artifact bundles from Azure Blob Storage). Because these requests go through the same authenticated HTTP client, the token is sent to all of them.

Impact

Tokens were transmitted in HTTP headers to the listed hosts during normal gh attestation, gh release verify, and gh release verify-asset operations. There is no evidence that tokens were logged, retained, or accessed by unauthorized parties. If a token were captured, it would grant the same access as the token holder, potentially including private repositories, organization resources, or enterprise administration depending on token type and permissions.

Remediation and mitigation

1. Revoke authentication tokens used with the GitHub CLI: - Personal access tokens - GitHub CLI OAuth app 2. Upgrade gh to 2.93.0. 3. Review personal security logs and any relevant audit logs for actions associated with personal or enterprise accounts.

A missing authorization vulnerability was identified in GitHub Enterprise Server that allowed an authenticated user with write access to any repository to read metadata from private repositories they did not have access to, including private repository owners and names, branch names, commit SHAs, commit messages, and the pushing actor. The delegated bypass endpoint resolved a rule suite directly from an attacker-supplied, encoded identifier without verifying that the requesting user could read the rule suite's repository, and because these identifiers are sequential an attacker could enumerate them across the instance. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.17.18, 3.18.12, 3.19.9, 3.20.5, and 3.21.3. This vulnerability was reported via the GitHub Bug Bounty program.

A denial of service vulnerability was identified in GitHub Enterprise Server that allowed an authenticated user to cause service disruption by supplying a repository release notes configuration file containing deeply nested YAML. When release notes were generated, the configuration file was parsed without a nesting depth limit, causing excessive resource consumption that could render the instance unresponsive. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.17.18, 3.18.12, 3.19.9, 3.20.5, and 3.21.3. This vulnerability was reported via the GitHub Bug Bounty program.

A path traversal vulnerability was identified in GitHub Enterprise Server that allowed an attacker who had code execution inside the Dependabot updater container to write files to arbitrary repository paths, including GitHub Actions workflow files under .github/workflows/ as the path validation did not check the effective path which the attacker could control through the dependency file's directory and symlink target. If the repository used a pullrequesttarget workflow or had auto-merge enabled, an injected workflow could execute with access to the repository's GitHub Actions secrets. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.21.3, 3.20.5, 3.19.9, 3.18.12, 3.17.18.

Impact

CommonMarker uses cmark-gfm for rendering Github Flavored Markdown. An integer overflow in cmark-gfm's table row parsing may lead to heap memory corruption when parsing tables who's marker rows contain more than UINT16MAX columns. The impact of this heap corruption ranges from Information Leak to Arbitrary Code Execution.

If affected versions of CommonMarker are used for rendering remote user controlled markdown, this vulnerability may lead to Remote Code Execution (RCE).

Patches

This vulnerability has been patched in the following CommonMarker release:

- v0.23.4

Workarounds

The vulnerability exists in the table markdown extensions of cmark-gfm. Disabling any use of the table extension will prevent this vulnerability from being triggered.

References

- https://github.com/github/cmark-gfm/security/advisories/GHSA-mc3g-88wq-6f4x

Acknowledgements

We would like to thank Felix Wilhelm of Google's Project Zero for reporting this vulnerability

For more information

If you have any questions or comments about this advisory:

Open an issue in CommonMarker

Summary

A security vulnerability has been identified in GitHub CLI that could allow terminal escape sequence injection when users view GitHub Actions workflow logs using gh run view --log or gh run view --log-failed.

Details

The vulnerability stems from the way GitHub CLI handles raw Actions log output. The gh run view --log and gh run view --log-failed commands stream workflow log lines to stdout or the configured pager without sanitizing terminal control sequences. An attacker who can influence GitHub Actions log content, for example via a PR triggered workflow, can embed escape sequences that are replayed in the user's terminal when they inspect the run.

Depending on the victim's terminal emulator, injected sequences could change the window title, manipulate on screen content, or in some terminal emulators (such as screen) potentially execute arbitrary commands.

In 2.92.0, GitHub CLI sanitizes terminal control sequences in Actions log output before writing to the terminal.

PoC

Create a workflow that emits terminal escape sequences in its log output:

yaml name: Escape Sequence PoC

on: workflowdispatch:

jobs: emit-escape-sequences: runs-on: ubuntu-latest steps: - name: Emit terminal escape sequences run: | # OSC title set printf 'ESCAPEMARKERSTART \033]0;HIJACKEDTITLE\007 ESCAPEMARKEREND\n' # CSI color printf 'ESCAPEMARKERSTART \033[31mREDTEXT\033[0m ESCAPEMARKEREND\n' # Screen title set (enables command execution in screen terminal) printf 'ESCAPEMARKERSTART \033k;malicious command;\033\\ ESCAPEMARKEREND\n'

Then trigger the workflow and view its logs:

bash gh workflow run 'Escape Sequence PoC' gh run view <runid> --log

On vulnerable versions, the raw ESC bytes (0x1b) are passed through to the terminal unsanitized. On 2.92.0 and later, escape sequences are stripped and only the safe visible text is displayed.

Impact

An attacker who can control GitHub Actions workflow output can inject terminal escape sequences into a maintainer's terminal session when they inspect the run with gh run view --log or gh run view --log-failed. The practical impact depends on the victim's terminal emulator.

Remediation and Mitigation

1. Upgrade gh to 2.92.0 2. Pipe log output through a sanitizer (e.g., gh run view --log | cat -v) as a workaround on older versions 3. Exercise caution when viewing logs from untrusted workflow runs

An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed a user-to-server token scoped to a GitHub App installation to perform certain write operations on public repositories outside the token's intended scope. This was possible because the authorization check only verified that the installation had read permissions on the target repository rather than verifying that the token's installation was explicitly granted access to that repository. An attacker who obtained a victim's user-to-server token could create issues, issue comments, commit comments, and private vulnerability reports on any public repository, appearing as the victim user with no indication of the app involvement. This vulnerability was fixed by adding a repository scope check for user-to-server tokens issued by global apps. 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.

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 managerunners: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.

A missing authorization vulnerability was identified in GitHub Enterprise Server that allowed an authenticated user to read source code from private repositories they did not have access to. The Copilot pull request description diff summary endpoint accepted a cross-repository comparison range and rendered the resulting diff without verifying that the requesting user was authorized to view the target repository. Exploitation required an authenticated account on the instance with read access to at least one repository to use as the comparison base. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21 and was fixed in versions 3.17.17, 3.18.11, 3.19.8, and 3.20.4. This vulnerability was reported via the GitHub Bug Bounty program.

A stored cross-site scripting vulnerability was identified in GitHub Enterprise Server that allowed an authenticated attacker to execute arbitrary JavaScript in another user's browser by injecting a crafted payload into the title of a Discussion in the Q&A category. The AnsweredQuestionStructuredDataComponent did not escape user-controlled Discussion titles before embedding them in a <script type="application/ld+json"> block, allowing the title to break out of the script context. The injection was escalated to a full cross-site scripting attack on GitHub Enterprise Server by leveraging JSONP callback support in the REST API to bypass the Content Security Policy. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21 and was fixed in versions 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.

GitHub Copilot 1.372.0 allows filesystem access outside of a workspace folder (without user approval) via a file-handler URI parameter to fetchwebpage. Therefore, exfiltration could occur if there is indirect prompt injection.

A reflected HTML injection vulnerability was identified in the GitHub Enterprise Server Management Console login page that could allow credential theft. The redirectto query parameter on the /setup/unlock endpoint was reflected into an HTML attribute without proper sanitization, enabling an attacker to inject a form element that could capture administrator credentials. Exploitation required an administrator to click a crafted link and enter their credentials. This vulnerability affected GitHub Enterprise Server versions 3.19.1 through 3.19.5 and 3.20.0 through 3.20.1, and was fixed in versions 3.19.6 and 3.20.2. This vulnerability was reported via the GitHub Bug Bounty program.

A server-side request forgery (SSRF) vulnerability was identified in the GitHub Enterprise Server notebook viewer that allowed an attacker to access internal services by exploiting URL parser confusion between the validation layer and the HTTP request library. The hostname validation used a different URL parser than the request library, enabling a crafted URL to pass validation while directing the request to an unintended host. Exploitation required network access to the GitHub Enterprise Server instance. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21 and was fixed in versions 3.16.18, 3.17.15, 3.18.9, 3.19.6, and 3.20.2. This vulnerability was reported via the GitHub Bug Bounty program.

A denial of service vulnerability was identified in GitHub Enterprise Server that allowed an unauthenticated attacker to cause service disruption by sending crafted requests with deeply nested JSON payloads to an unauthenticated API endpoint. The endpoint parsed user-controlled JSON request bodies without size or depth limits, causing excessive CPU and memory consumption. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21 and was fixed in versions 3.20.2, 3.19.6, 3.18.9, 3.17.15, and 3.16.18. This vulnerability was reported via the GitHub Bug Bounty program.

An authentication bypass vulnerability was identified in GitHub Enterprise Server that allowed an unauthenticated attacker to create a local user account, bypassing the configured external identity provider. When external authentication was enabled, the signup endpoint did not properly enforce the authentication restriction, allowing account creation and session establishment without identity provider validation. The created account was limited to the default base permissions configured on the instance. Exploitation required network access to a GHES instance configured with an external authentication provider. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21 and was fixed in versions 3.20.2, 3.19.6, 3.18.9, 3.17.15, and 3.16.18.

An incorrect authorization vulnerability allowed unauthorized read access to the contents of internal repositories for contractor accounts when the Contractors API feature was enabled. The Contractors API is a rarely-enabled feature in private preview. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.18 and was fixed in versions 3.14.15, 3.15.10, 3.16.6 and 3.17.3

An exposure of sensitive information vulnerability was identified in GitHub Enterprise Server that could allow an attacker to disclose the names of private repositories within an organization. This issue could be exploited by leveraging a user-to-server token with no scopes via the Search API endpoint. Successful exploitation required an organization administrator to install a malicious GitHub App in the organization’s repositories. This vulnerability impacted only GitHub Enterprise Server version 3.17 and was addressed in version 3.17.2. The vulnerability was reported through the GitHub Bug Bounty program.