GitSpawn. The access path.
A .git/config from outside ran a command when the agent started. One git setting, seven coding agents and the developer credentials within their reach.
The record
Entry point. shared-folder, zip, sync folder or USB, .git kept.
The identity in the middle. The developer shell. The command ran as the user, outside the agent sandbox.
What was reached. developer-shell, runs as the user, outside the sandbox.
A .git/config from outside ran a command when the agent started.
The path, step by step.
Taken from the published reporting. Nothing here is reconstructed.
| Step | Role in the path | What the reporting records |
|---|---|---|
| shared-folder | Entry | zip, sync folder or USB, .git kept |
| .git/config | Step | core.fsmonitor = attacker command |
| agent-startup | Step | background git status, no prompt |
| developer-shell | Reached | runs as the user, outside the sandbox |
Where a breakpoint would have been
The agent running git in a repository whose .git directory came from somewhere else. A sync folder, a zip or a USB stick keeps that directory, and background git status is enough to trigger it.
A breakpoint is the single change that closes a path with the least disruption. Read how that is chosen in the breakpoint page. The full narrative is in the teardown.
4 steps from entry to data.
Where this comes from.
Every field on this page is taken from the published reporting below. The breakpoint assessment is Elmoz reading that path, not a statement about what the affected organisation did.
Questions, answered.
The two questions this record answers.
What was the entry point in the GitSpawn incident?
The published path starts at shared-folder, zip, sync folder or USB, .git kept.
What did it reach?
The last step in the published path is developer-shell, runs as the user, outside the sandbox.
Other incidents.
Same database, different path shape.
See what your agents can reach. Before someone else does.
Book a demo and we walk through the access paths in an environment like yours.