Soft Serve cached repository records in memory with no expiry, and trusted the cached record for every access check. SetPrivate cleared the cached record before it saved the new visibility, and not afterwards. A request that arrived between the two read the old, public record from the database and cached it after the change was saved. From then on every access check used that stale record, so a repository the …
Soft Serve answers Go's ?go-get=1 requests by walking up the requested path until it finds a repository, then rendering that repository's name and clone URL into a go-import meta tag. The walk checked that each candidate repository existed, but never that the caller could read it. A request for a path inside a private repository, such as GET /secret/anything?go-get=1, therefore returned 200 naming secret and its clone URL, even though …
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.
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.
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 …
This advisory duplicates another.
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.