Vulnerabilities

GitPython 3.1.50 contains a command-injection flaw (CWE-78) in which the library's default unsafe-option gate fails to recognize joined short-option forms such as -u, the short form of --upload-pack=. The flaw is triggered when an application passes attacker-influenced options into Repo.clone_from(..., multi_options=..., allow_unsafe_options=False): the attacker supplies -u with a value of their choosing, bypassing the gate that is supposed to block --upload-pack/-u. During the clone, Git then executes the helper command named by the -u option, giving the attacker arbitrary command execution on the host running GitPython, in the context of the cloning process. Any application built on GitPython 3.1.50 that forwards untrusted, user-controlled clone options is affected; deployments that do not pass attacker-influenced options are not exposed. There is one public proof-of-concept reference (the project's GitHub security advisory GHSA-v396-v7q4-x2qj); the flaw is not in CISA KEV, EPSS is 0.4%, and no in-the-wild exploitation is currently reported.

Do: Upgrade to GitPython 3.1.51 or later, which recognizes joined short-option forms in the unsafe-option gate. Until patched, do not pass attacker-controlled arguments to Repo.clone_from via multi_options, and audit applications that let users supply clone options (including short options like -u) for this pattern.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.0 before 19.0.5, 19.1 before 19.1.3, and 19.2 before 19.2.1 that under certain conditions could have allowed an authenticated user to modify CI/CD configuration belonging to another user due to improper validation of user-supplied attributes when processing pipeline schedule inputs.

GitHub MCP Server versions prior to 1.1.0 contain a nil pointer dereference (CWE-476) in the CompletionsHandler function in pkg/github/server.go, which accesses the ref field of a completion request without first verifying it is present. Any unauthenticated client able to send JSON-RPC messages to the server can trigger the flaw by issuing a completion/complete request with a missing or empty ref field. Because the dereference happens before any authentication or token validation, the resulting Go runtime panic crashes the server and yields a complete denial of service. All deployments running an affected version are potentially affected, with the greatest risk for instances reachable over a network by unauthenticated clients, while locally run stdio instances are only reachable by their local client. No widespread exploitation is reported (0.4% EPSS, not in CISA KEV), but a public security advisory documents the issue and the triggering request is trivial to craft.

Do: Upgrade to GitHub MCP Server 1.1.0 or later, which adds the missing nil check in CompletionsHandler. Until patched, restrict any HTTP/SSE-exposed instance with authentication or network allowlisting, since the crashing request requires no credentials. Audit deployments to determine which are network-reachable versus local-only, and watch for unauthenticated completion/complete requests that crash the process.

GitLab has remediated an issue in GitLab EE affecting all versions from 13.11 before 18.11.7, 19.0 before 19.0.4, and 19.1 before 19.1.2 that under certain conditions could have allowed an authenticated user with developer-role permissions to execute arbitrary scripts in another user's browser session due to improper sanitization of user-supplied input.

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

GitLab has remediated an issue in GitLab EE affecting all versions from 19.1 before 19.1.1 that under certain conditions could have allowed a user to access sensitive information that had already been committed to a project, due to insufficient output filtering in Duo Workflows.