Vulnerability GHSA-96wc-2m84-2cj7

Summary

A malicious server can advertise circular symref= capabilities (e.g. a → b and b → a). isomorphic-git writes them to disk as loose symrefs, and GitRefManager.resolve() follows them with no depth limit and no cycle detection, so any later operation that resolves one of them (log, status, checkout, branch, …) loops forever — a persistent denial of service from a single clone.

Details

src/managers/GitRefManager.js — resolve() only enforces a depth limit when a depth argument is passed (depth = undefined by default), and has no visited-set:

static async resolve({ fs, gitdir, ref, depth = undefined }) {
  if (depth !== undefined) { depth--; if (depth === -1) return ref }
  …
}

updateRemoteRefs persists all server-supplied symrefs unconditionally. After clone the client has refs/remotes/origin/a → ref: refs/remotes/origin/b and b → a on disk; resolving either never terminates. Because the bad refs live on disk, the repo is effectively bricked for the application.

Canonical git behavior (divergence)

git caps symref resolution at SYMREF_MAXDEPTH = 5 (refs.c): git rev-parse a returns immediately with warning: ignoring dangling symref — no recursion, no hang.

PoC

https://github.com/spiceoverflow/av5-circular-symref — open in a Codespace; clone writes the circular symrefs, then git.log on one never returns (the runner stops it after a 20s hang):

[AV-5] refs/remotes/origin/a contains: ref: refs/remotes/origin/b
[AV-5] refs/remotes/origin/b contains: ref: refs/remotes/origin/a
[run] *** DoS CONFIRMED: resolving a circular symref never terminates ***

Impact

A persistent denial of service via non-terminating symbolic-ref resolution (CWE-674 / CWE-835). After a single clone from a malicious (or MitM'd) server the circular refs are written to disk, so every later operation that resolves them (log, status, checkout, branch, …) hangs forever — the repository becomes effectively unusable for the application.

Impacted: any application that clones from untrusted/compromised remotes with isomorphic-git.

Suggested fix

Add visited-set cycle detection (and/or a default maximum depth, as git does) in GitRefManager.resolve(); optionally validate server-supplied symref targets before persisting.