Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
An attacker can inject extra commits into the pack sent to GitHub, commits that aren’t pointed to by any branch. Although these “hidden” commits never show up in the repository’s visible history, GitHub still serves them at their direct commit URLs. This lets an attacker exfiltrate sensitive data without ever leaving a trace in the branch view. We rate this a High‑impact vulnerability because it completely compromises repository confidentiality. Details The proxy currently trusts only the ref‑update line (oldOid → newOid) and doesn't inspect the packfile’s contents Because the code only runs git rev-list oldOid..newOid to compute introducedCommits but never checks which commits actually arrived in the pack, a malicious client can append extra commits. Those “hidden” commits won’t be pointed to by any branch but GitHub still stores and serves them by SHA. <img width="2556" height="744" alt="Screenshot 2025-07-16 at 12 29 19"…
Recommended action: Upgrade to 1.19.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can exploit the way GitProxy handles new branch creation to bypass the approval of prior commits on the parent branch. Because it can greatly affect system integrity, we classify this as a High impact vulnerability. Details GitProxy checks for the 0000000000000000000000000000000000000000 hash to detect new branches. This is used to process the commit accordingly in both getDiff.ts and parsePush.ts. However, the logic can be exploited as follows: 1. Make a commit in branch a (could be main) 2. Make a new branch b from that commit 3. Make a new commit in b, then approve it/get it approved 4. Go back to a, and attempt to push this commit to the proxy The unapproved commit from a will be pushed to the remote. PoC To reproduce this vulnerability: 1. Clone the target repository and make an unapproved commit on a mainline branch (e.g. main): 2. Without approving/getting the commit approved on branch a, create a new branch b based on it: 3. Approve/get approval for the…
Recommended action: Upgrade to 1.19.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can craft a malicious Git packfile to exploit the PACK signature detection in the parsePush.ts. By embedding a misleading PACK signature within commit content and carefully constructing the packet structure, the attacker can trick the parser into treating invalid or unintended data as the packfile. Potentially, this would allow bypassing approval or hiding commits. Details The affected version of parsePush.ts attempts to locate the Git PACK file by looking for the last occurrence of the string "PACK" in the incoming push payload: This assumes that any "PACK" string near the end of the push is the beginning of the actual binary Git packfile. However, Git objects (commits, blobs, etc.) can contain arbitrary content (including the word PACK) in binary or non-compressed blobs. An attacker could abuse this by: 1. Crafting a custom packfile using low-level Git tools or by manually forging one 2. Placing the string "PACK" inside a commit body or a binary file blob that…
Recommended action: Upgrade to 1.19.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This vulnerability allows a user to push to the remote repository while bypassing policies and explicit approval. Since checks and plugins are skipped, code containing secrets or unwanted changes could be pushed into a repository. Because it can allow policy violations to go undetected, we classify this as a High impact vulnerability. Details The source of the vulnerability is the push parser action parsePush.ts. It reads the first branch and parses it, while ignoring subsequent branches (silently letting them go through). Although the fix involves multiple improvements to the commit and push parsing logic, the core solution is to prevent multiple branch pushes from going through in the first place: PoC 1. Make a commit on a branch: 2. Wait for approval of safe-branch. 3. Make a commit on a separate branch with a secret, for example: 4. Push both at the same time: git push proxy safe-branch bad-branch Expected Result Ideally, this would force checks to run for the second…
Recommended action: Upgrade to 1.19.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.