GHSA-fgxm-5hvv-x4vh: Private Repository Enumeration via Go Module Discovery and HTTP Response Discrepancies in Soft Serve

Soft Serve (github.com/charmbracelet/soft-serve) is a self-hostable Git server managed via the command line and SSH, providing Git repository access over SSH, Git daemon, and HTTP/HTTPS protocols. In addition to standard Git operations and Git Large File Storage (LFS), Soft Serve's HTTP server implements the Go remote import path protocol. When the Go toolchain executes commands such as go get, it appends the ?go-get=1 query parameter to the requested package path, expecting the server to return an HTML response containing <meta name="go-import"> tags that identify the root repository URL.

In Soft Serve versions 0.5.0 through 0.12.2, the HTTP request routing and access control middleware fail to properly enforce read authorization when resolving repository paths. Specifically, the vulnerability manifests through two distinct mechanisms: a logic flaw in how ?go-get=1 sub-path requests are evaluated by the access control middleware and the Go import handler (CWE-285: Improper Authorization), and an observable response discrepancy across Git Smart HTTP, Dumb HTTP, and LFS endpoints (CWE-203: Observable Discrepancy).

Through these flaws, an unauthorized actor with network access to the Soft Serve HTTP interface (default port :23231) can enumerate private repositories. Under the default server configuration (anon-access: read-only), an unauthenticated remote client can confirm whether specific private repositories exist and extract their canonical names and clone URLs. Even when anonymous access is disabled (anon-access: no-access), any authenticated user with low privileges can perform the same enumeration against private repositories belonging to other users or teams.

Furthermore, because the ?go-get=1 bypass condition was originally implemented inside the shared withAccess HTTP middleware rather than scoped exclusively to the Go module discovery route, appending ?go-get=1 to non-existent repository paths on Git LFS basic transfer endpoints bypasses nil-repository guards. This triggers a nil-pointer dereference in the underlying LFS handler, resulting in an unhandled panic that is caught by the HTTP recovery middleware and returned as an HTTP 500 Internal Server Error.

The primary information disclosure mechanism stems from an interaction between two components in pkg/web: the withAccess middleware in pkg/web/git.go and the GoGetHandler function in pkg/web/goget.go. When an HTTP request arrives, withAccess resolves the target repository from the full URL path and evaluates the caller's permissions via be.AccessLevelForUser(ctx, repoName, user).

Because Soft Serve supports automatic repository creation upon push ("push-to-create"), calling AccessLevelForUser on a path string that does not correspond to an existing repository returns the server's default baseline access level rather than NoAccess. Under the default anon-access: read-only setting, any non-existent path evaluates to ReadOnlyAccess for anonymous callers. If a caller is authenticated, non-existent paths evaluate to ReadWriteAccess. In withAccess, the switch statement checked case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess: before checking case repo == nil, accessLevel < access.ReadOnlyAccess:. When a user requested /secret/subpkg?go-get=1 (where secret is a private repository and secret/subpkg does not exist), repo was nil, accessLevel evaluated to ReadOnlyAccess, and the middleware permitted the request to pass through to GoGetHandler.

Once execution reached GoGetHandler, the handler walked up the URL path directory by directory using path.Dir(repo) until it found a matching repository via be.Repository(ctx, repo). The loop terminated as soon as be.Repository returned no error, meaning a valid repository object was located. Crucially, GoGetHandler assumed withAccess had already authorized the request and never called be.AccessLevelForUser on the resolved parent repository. It immediately rendered the HTTP 200 OK template containing the <meta name="go-import"> tag for /secret.

The secondary vulnerability mechanism involves status code discrepancies across standard Git HTTP and LFS routes. When withAccess processed standard Git Smart HTTP requests without ?go-get=1, it checked whether repo == nil before evaluating user credentials or authorization. If a repository did not exist, the server immediately returned 404 Not Found. If the repository existed and was private, the server checked credentials and returned 401 Unauthorized (with a WWW-Authenticate header) to anonymous users.

A similar discrepancy existed in Git LFS write routes and JWT authentication (pkg/web/auth.go). On LFS upload endpoints, write-access checks occurred before verifying whether the user had basic read visibility into the repository; an authenticated user without access received 403 Forbidden for an existing private repository, but 404 Not Found for a missing repository. Additionally, during JWT validation in parseJWT, querying a non-existent repository returned a generic "missing repository" error that downgraded the caller to an anonymous context, whereas supplying an invalid or mismatched token against an existing private repository returned ErrInvalidToken, yielding 403 Forbidden.

The vulnerabilities were addressed across two commits in version v0.12.3. The first commit (74e41543304d1e12fd54fc59e410bd428373dd34) refactored the go-get routing and access checks. Previously, withAccess in pkg/web/git.go contained a special pass-through case for go-get=1, and GoGetHandler performed unauthenticated path walking:

// Vulnerable code in pkg/web/git.go (prior to v0.12.3)
switch {
case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
    // FLAW: When querying /private-repo/subpath?go-get=1, repo is nil,
    // but accessLevel for the non-existent subpath is ReadOnlyAccess.
    // This breaks out of the switch before the repo == nil check below.
    break
case repo == nil, accessLevel < access.ReadOnlyAccess:
    renderNotFound(w, r)
    return
}

// Vulnerable code in pkg/web/goget.go (prior to v0.12.3)
for {
    // FLAW: Checks only if the parent path is a valid repository,
    // completely omitting authorization checks on the resolved repo.
    if _, err := be.Repository(ctx, repo); err == nil {
        break
    }
    repo = path.Dir(repo)
    if repo == "/" || repo == "." {
        renderNotFound(w, r)
        return
    }
}

In commit 74e41543304d1e12fd54fc59e410bd428373dd34, the maintainer removed the go-get=1 case from withAccess and replaced the middleware wrapper on the go-get route with withCaller, which extracts user authentication state without performing premature target authorization. Authorization is now enforced directly inside GoGetHandler at each step of the directory traversal, and defensive nil checks were added to the LFS handlers in pkg/web/git_lfs.go:

// Patched code in pkg/web/goget.go (Commit 74e41543304d1e12fd54fc59e410bd428373dd34)
user := proto.UserFromContext(ctx)
for {
    // FIX: Verify both repository existence AND caller read authorization
    if _, err := be.Repository(ctx, repo); err == nil && be.AccessLevelForUser(ctx, repo, user) >= access.ReadOnlyAccess {
        break
    }
    repo = path.Dir(repo)
    if repo == "/" || repo == "." {
        // Uses unified denyRead helper in subsequent commit
        denyRead(w, r, authErr, false)
        return
    }
}

The second commit (dc351aa0d824c8bef528c6924a7acdfb9f20c852) eliminated the HTTP status code discrepancy oracles by introducing a centralized denyRead helper in pkg/web/git.go and modifying parseJWT in pkg/web/auth.go. Rather than branching on whether repo == nil prior to checking credentials, the patched server bases its rejection response strictly on the caller's authentication state:

// Patched code in pkg/web/git.go (Commit dc351aa0d824c8bef528c6924a7acdfb9f20c852)
func denyRead(w http.ResponseWriter, r *http.Request, err error, lfsJSON bool) {
    switch {
    case badCredentials(err) && lfsJSON:
        renderJSON(w, http.StatusForbidden, lfs.ErrorResponse{Message: "bad credentials"})
    case badCredentials(err):
        renderForbidden(w, r)
    case proto.UserFromContext(r.Context()) == nil && lfsJSON:
        askCredentials(w, r)
        renderJSON(w, http.StatusUnauthorized, lfs.ErrorResponse{Message: "credentials needed"})
    case proto.UserFromContext(r.Context()) == nil:
        // FIX: Anonymous callers receive 401 Unauthorized for BOTH missing and private repos
        askCredentials(w, r)
        renderUnauthorized(w, r)
    case lfsJSON:
        renderJSON(w, http.StatusNotFound, lfs.ErrorResponse{Message: "repository not found"})
    default:
        // FIX: Authenticated callers without access receive 404 Not Found for BOTH missing and private repos
        renderNotFound(w, r)
    }
}

The fix is comprehensive with respect to HTTP response codes and body content. By unifying the error responses across withAccess, GoGetHandler, and parseJWT, an external observer can no longer distinguish between a non-existent repository and an unauthorized private repository via HTTP status codes or headers. The only remaining avenue for repository name discovery over HTTP/SSH is confined to authenticated users who explicitly hold repository creation (ReadWriteAccess on non-existent paths) privileges attempting to push a new repository, which is an inherent property of push-to-create architectures.

Exploiting GHSA-fgxm-5hvv-x4vh requires only network access to the Soft Serve HTTP port and a standard HTTP client such as curl. No specialized tooling or complex state manipulation is necessary. Under the default configuration (anon-access: read-only), an unauthenticated attacker can probe for a suspected private repository named internal-billing using two techniques.

In the first technique, the attacker leverages the ?go-get=1 sub-path traversal flaw. If the attacker queries the exact repository path /internal-billing?go-get=1, withAccess resolves the repository object, sees that it is private, and blocks the request. However, if the attacker appends an arbitrary non-existent child segment (such as /internal-billing/pkg?go-get=1), withAccess evaluates internal-billing/pkg, finds no matching repository object, assigns the default ReadOnlyAccess level, and forwards the request to GoGetHandler:

# Querying the root path directly fails authorization
curl -i "http://target-host:23231/internal-billing?go-get=1"
# HTTP/1.1 401 Unauthorized (or 404 Not Found)
 
# Querying any arbitrary sub-path bypasses withAccess and triggers GoGetHandler traversal
curl -s "http://target-host:23231/internal-billing/x?go-get=1" | grep go-import
# <meta name="go-import" content="target-host:23231/internal-billing git http://target-host:23231/internal-billing.git">

Furthermore, if the server hosts nested private repositories (for example, org/project-alpha), an attacker who knows only the top-level prefix can query /org/project-alpha/x?go-get=1 to confirm org/project-alpha, or query /org/nonexistent?go-get=1 to discover if /org itself is a private repository. Because GoGetHandler walks up the entire path hierarchy until it hits /, any private parent repository along the path will be disclosed if the leaf path does not exist.

In the second technique, the attacker utilizes the status code discrepancy on standard Git Smart HTTP endpoints (such as /info/refs?service=git-upload-pack) to perform high-speed dictionary enumeration without relying on go-get:

# Probing a non-existent repository returns 404 Not Found
curl -o /dev/null -s -w "%{http_code}\n" "http://target-host:23231/nonexistent-repo.git/info/refs?service=git-upload-pack"
# Output: 404
 
# Probing an existing private repository returns 401 Unauthorized
curl -o /dev/null -s -w "%{http_code}\n" "http://target-host:23231/internal-billing.git/info/refs?service=git-upload-pack"
# Output: 401

> [!NOTE] > If an attacker sends a request to a Git LFS basic transfer endpoint for a non-existent repository while appending ?go-get=1 (e.g., GET /nonexistent.git/info/lfs/objects/basic/oid?go-get=1), the request bypasses the repo == nil guard in withAccess and causes a nil-pointer dereference panic when repo.ID() is invoked in serviceLfsBasicDownload, returning an HTTP 500 Internal Server Error.

The vulnerability is rated Medium severity with a CVSS v3.1 base score of 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). The Attack Vector is Network (AV:N) and Attack Complexity is Low (AC:L), as the HTTP interface is directly reachable by remote clients and requires no special timing or state preparation. Privileges Required is None (PR:N) in default deployments where anon-access is set to read-only, and User Interaction is None (UI:N).

The Confidentiality Impact is Low (C:L). An attacker cannot read repository file contents, commit history, branches, or Git blobs through this flaw. However, the attacker gains reliable confirmation of private repository existence, exact repository path names, and canonical clone URLs. In enterprise and software development environments, repository names frequently contain sensitive metadata, including unannounced product codenames, customer names, zero-day research identifiers, or internal infrastructure component mappings.

There is no direct impact to Integrity (I:N) or Availability (A:N). While appending ?go-get=1 to Git LFS basic transfer endpoints triggers a nil-pointer dereference panic in serviceLfsBasicDownload and serviceLfsBasicUpload, Soft Serve wraps its HTTP router in recovery middleware that catches the panic on the active goroutine and returns an HTTP 500 response. Consequently, the panic does not crash the Soft Serve daemon process or cause a persistent denial of service.

At the time of publication, there is no CVE ID assigned to GHSA-fgxm-5hvv-x4vh, and it is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No public exploit kits or automated scanning templates (such as Nuclei) have been published in major exploit repositories, though trivial enumeration via standard HTTP clients remains straightforward to automate.

To fully remediate this vulnerability, administrators and developers must upgrade Soft Serve (github.com/charmbracelet/soft-serve) to version v0.12.3 or later. Version v0.12.3 contains both commit 74e41543304d1e12fd54fc59e410bd428373dd34 and commit dc351aa0d824c8bef528c6924a7acdfb9f20c852, which enforce read permission checks during go-get directory traversal, add nil-pointer guards to LFS handlers, and standardize HTTP error responses across missing and private repositories.

For installations managed via Go modules or built from source, update the dependency or install the patched binary directly:

go install github.com/charmbracelet/soft-serve/cmd/soft@v0.12.3

If an immediate upgrade to v0.12.3 is not operationally feasible, administrators can apply configuration workarounds in the Soft Serve config.yaml file (located in the Soft Serve data directory) to reduce the attack surface:

1. Disable the HTTP Server: If Git operations and Go module fetching over HTTP are not required, disable the HTTP listener entirely. This restricts all repository interactions to SSH, eliminating the vulnerable HTTP handlers:

   http:
     enabled: false

2. Restrict Anonymous Access: If the HTTP server must remain enabled, configure anon-access to no-access (or none) in the server configuration or via the SSH administration CLI (soft settings anon-access no-access). While this prevents unauthenticated attackers from leveraging the ?go-get=1 sub-path traversal bypass, note that unauthenticated status code discrepancies on certain routes and enumeration by authenticated low-privileged users remain possible until the binary is upgraded to v0.12.3.

3. Reverse Proxy Filtering: If Soft Serve sits behind a reverse proxy (such as Nginx, Caddy, or HAProxy) and Go remote import discovery is not used, configure the proxy to block or strip requests containing the go-get=1 query parameter to prevent the path traversal bypass and the LFS nil-pointer panic.