Spiceoverflow

The `git.checkout()` function writes new child paths through symlinked leading directory components without proper validation. A malicious repository can create a directory symlink and subsequently replace the tree state with a child file under that path. This can be triggered during a clone followed by a pull, or during a single clone if a symlink already exists. On Linux or macOS using Node fs, the operating system may resolve the write outside the working tree, allowing arbitrary host file writes and potential code execution. On Windows, Node fs typically blocks symlink creation without elevated privileges. Browser or in-memory providers are limited to their virtual filesystem and are only affected if they support symlink creation and following.

The software persists server-supplied circular symref capabilities through `updateRemoteRefs`. The `GitRefManager.resolve()` function follows these loose symbolic references without a default depth limit or cycle detection. If a clone is performed from a malicious or man-in-the-middle-controlled remote, operations that resolve references such as `refs/remotes/origin/a` or `refs/remotes/origin/b`—including log, status, checkout, and branch—will not terminate. These circular references remain on disk, rendering the repository unusable and causing a persistent denial of service.

An issue exists when applying a packfile delta in `src/utils/applyDelta.js` where a server-controlled `targetSize` is passed without a bound to `Buffer.alloc(targetSize)`. A malicious remote actor or a man-in-the-middle can send a delta header that forces `git.clone()` or `git.fetch()` to allocate approximately 2 GB of memory before the actual delta output is validated. Because `GitPackIndex.fromPack()` suppresses subsequent size-mismatch errors, systems with ample memory may experience resource waste, while containers, serverless functions, and small virtual machines may crash. This off-heap Buffer allocation is not mitigated by Node.js heap limits.

The tree parser in `src/models/GitTree.js` accepts standalone `..` tree-entry names because it only rejects path separators. When performing a clone or checkout from a malicious or man-in-the-middle-controlled non-GitHub remote, nested `..` entries can escape the working-tree root. This allows an attacker to write files to selected parent paths on any host-backed fs provider, potentially overwriting startup or configuration files to achieve code execution.