The report
The reference Git MCP server already checked that an opened repository belonged within a configured --repository area. That looked like a containment boundary until a second investigation asked what Git itself could reach after the check. The November 11 advisory identifies two ways for the check to accept repository structures whose subsequent Git operations used objects or index state outside the intended root.
Two different meanings of Git directory
An alternates file can make a repository resolve commit and blob objects from another object store. The MCP server checked the nominal repository path but did not treat a referenced external object store as part of the access decision. A restricted Git tool could therefore retrieve object contents beyond the allowed root, provided the external store was readable and the caller knew suitable object identifiers.
The linked-worktree case was a different identity error. Git assigns a worktree its own Git directory and a shared common directory. The validation logic compared those roles against a common allowed set, so an attacker-controlled nested repository could present the main repository's common directory in the wrong role and pass. Under the documented prerequisites, some Git tools could then affect index or reference state that should have remained outside the agent's repository authority. The earlier Case records both the older alternates defect and the updated worktree evidence.
Fix scope and residual conditions
Package 2026.11.11 rejects external object alternates under confinement and checks worktree, Git and common directory identities separately. The advisory warns about a residual Windows junction case, so operators should not assume a cross-platform guarantee from the Linux-oriented proof alone. No field victim was identified. These are access-boundary failures; they must not be merged with the separate .git/config command-execution vulnerability simply because both were patched in the same release.