github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve does not sanitize ANSI escape sequences in user input in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve does not sanitize ANSI escape sequences in user input in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to arbitrary file writing through SSH API in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve does not sanitize ANSI escape sequences in user input in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to arbitrary file writing through SSH API in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve does not sanitize ANSI escape sequences in user input in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to arbitrary file writing through SSH API in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve does not sanitize ANSI escape sequences in user input in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to arbitrary file writing through SSH API in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve does not sanitize ANSI escape sequences in user input in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to arbitrary file writing through SSH API in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve does not sanitize ANSI escape sequences in user input in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to arbitrary file writing through SSH API in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve does not sanitize ANSI escape sequences in user input in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to arbitrary file writing through SSH API in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to path traversal attacks in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve does not sanitize ANSI escape sequences in user input in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to arbitrary file writing through SSH API in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to path traversal attacks in github.com/charmbracelet/soft-serve

Summary

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 operator had just made private stayed readable by unauthenticated users over HTTP, SSH, and git:// until the server restarted.

Impact

An unauthenticated attacker can keep reading a repository after it is made private, including everything pushed to it afterwards. The attacker needs no account and no timing knowledge: a client polling GET /<repo>.git/info/refs?service=git-upload-pack, which the default anon-access: read-only allows, will eventually land in the window when the operator changes the visibility.

The stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. repo private <name> reads the database directly and reports true, and the visibility_change webhook is not sent, because its check reads the same stale record.

Write access is not gained. Because the repository was public until the change, an attacker able to win the race could already read its contents up to that point. What this adds is continued access to everything pushed after the operator made it private.

Deployments that run several Soft Serve processes against one shared database were affected more broadly. Each process kept its own cache, so a visibility change made through one process never reached the others, with no race required.

Reachable over HTTP, SSH, and git:// (AV:N). Success depends on a visibility change made by the operator, which the attacker does not control (AC:H). No privileges are required under the default anonymous read access (PR:N), and the attacker interacts with no one, since the operator's change is already captured by AC:H (UI:N). Continued read access to a repository its owner has made private is a high confidentiality impact (C:H), with no integrity or availability impact (I:N, A:N).

Root Cause

The cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.

Backend.Repository in pkg/backend/repo.go returned the cached record when present, and on a miss read the database and stored the result. The cache was a plain LRU of 1000 entries with no expiry (pkg/backend/cache.go), and AccessLevelForUser read the private flag from that record.

SetPrivate ran in this order:

d.cache.Delete(name)
... d.db.TransactionContext(ctx, func(tx *db.Tx) error {
	... writes or removes git-daemon-export-ok ...
	return d.store.SetRepoIsPrivateByName(ctx, tx, name, private)
})

A reader that missed the cache after the Delete but read the database before the commit got the old row, and stored it after the commit. Nothing ever cleared it again.

SetHidden, SetMirror, SetDescription, and SetProjectName cleared the cache in the same place. DeleteRepository and RenameRepository deferred the clear inside the transaction function, which also runs before the commit.

Moving the clear to after the commit would not have been enough on its own. A reader that read the old row before the commit could still store it after the clear.

Affected Versions

v0.6.0 through v0.12.2. The repository cache and this ordering arrived with the database-backed backend in commit e398b4d (refactor: implement database module and abstract backend, #337), first released in v0.6.0. Versions v0.5.x used a different backend and were not assessed.

Patches

Fixed in v0.12.3.

The repository cache is removed. Every lookup now reads the database, so an access check always sees the visibility most recently saved, whether by this process or any other sharing the database.

Removing the cache was preferred over making it race-free. A database lookup costs tens of microseconds on SQLite, which is small next to the Git work behind each request, while keeping the cache correct needed a versioning scheme around every write and still left multi-process deployments stale. Without the cache, the whole class of stale-authorization bugs goes away rather than this one instance.

The visibility_change webhook is also fixed in the same release. It now compares against the visibility saved before the change, so it fires when visibility actually changes and only then.

Workarounds

It is recommended to upgrade to the patched release.

No configuration closes the race. Restarting the server clears a stale record and restores correct access checks until the next visibility change. Operators who cannot upgrade immediately should create repositories as private from the start (repo create -p) rather than making public ones private, and avoid changing visibility while the server is serving traffic.

Summary

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 GET /secret?go-get=1 correctly returned 404. The same ?go-get=1 exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked.

The same disclosure appears without ?go-get=1. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got 401 while a missing one got 404, and a signed-in user without access got the reverse pattern. Either way, one request confirms whether a guessed name is a private repository. This was found while fixing the go-get issue and is included here because it has the same impact and is fixed in the same release.

Impact

A remote client can learn, with one request per candidate name, which private repositories exist, their exact names, and their clone URLs. Under the shipped default of anon-access: read-only no account is needed, and an authenticated user without access to the repository gets the same answer. Project names in private deployments are often sensitive (internal codenames, unreleased products, customer names), and this turns them into an enumerable namespace.

The Git and LFS routes give the same confirmation for any guessed name, to anonymous and authenticated callers alike, and an invalid Authorization: Bearer header does the same even where credentials are otherwise required.

Repository contents, refs, commits, and collaborators are not exposed, and no write path is reachable. The LFS panic is caught by the recovery middleware and returns a 500; the server stays up. Hidden repositories are not affected beyond what direct access already allows, since hiding a repository removes it from listings but does not restrict reading it by name.

Reachable over the HTTP interface, which is enabled by default (AV:N), with one ordinary GET request per name (AC:L). No privileges are required under the default anonymous read access (PR:N), and no victim interaction is needed (UI:N). Only repository names and clone URLs are disclosed, which is a low confidentiality impact (C:L), with no integrity or availability impact (I:N, A:N), since the panic is recovered per request.

Root Cause

Two pieces of code each assumed the other had checked access.

withAccess in pkg/web/git.go computed the access level for the requested path and then let go-get requests through ahead of the guard meant to hide repositories:

case r.URL.Query().Get("go-get") == "1" && accessLevel >= access.ReadOnlyAccess:
	// Allow go-get requests to passthrough.
	break
case repo == nil, accessLevel < access.ReadOnlyAccess:
	// Don't hint that the repo exists if the user doesn't have access
	renderNotFound(w, r)
	return

For a path that is not itself a repository, AccessLevelForUser returns the anonymous access level to anonymous callers and read-write to any authenticated user, since that is what allows a push to create a new repository. The go-get case therefore always matched for a sub-path, and the "don't hint that the repo exists" guard below it never ran.

GoGetHandler in pkg/web/goget.go then trimmed path segments with path.Dir until be.Repository succeeded, and rendered the first repository it found. It never asked whether the caller could read that repository. The access level the middleware had computed was for a different path.

Because the exception lived in the middleware shared by every Git route rather than on the go-get route, it also applied to the dumb-HTTP and LFS routes. There it skipped the repo == nil guard, and serviceLfsBasicDownload and serviceLfsBasicUpload dereferenced a nil repository from the request context. The sibling LFS handlers already checked for nil, which is why only those two panicked.

The Git and LFS routes behind withAccess had the opposite problem: each branch chose its own response for a caller who could not read the repository, and the choice depended on which condition failed first. On the smart HTTP routes a missing repository was checked before credentials, so it returned 404, while a private one fell through to the credential prompt and returned 401. On the LFS write routes the write-access check ran before the read check, so a signed-in user got 403 for a private repository and 404 for a missing one. And parseJWT in pkg/web/auth.go rejected a token for a missing repository with a "missing repository" error, which the caller treated as anonymous, while a token for an existing repository failed as invalid and got 403.

Affected Versions

v0.5.0 through v0.12.2. The go-get walk-up without an access check was introduced in commit 3dfecd9 (fix(http): go-get requests), and private repositories arrived in the same v0.5.0 release. The middleware exception that also reached the LFS and dumb-HTTP routes was added in v0.6.0, together with the HTTP LFS routes, and the differing responses on the Git and LFS routes date from the same middleware.

Patches

Fixed in v0.12.3.

The go-get route no longer goes through the per-repository access middleware. It authenticates the caller and nothing more, and GoGetHandler checks read access on each repository it considers during the walk-up. A repository the caller cannot read is skipped exactly as if it did not exist, so an unreadable repository and a missing one produce the same 404, and a readable repository nested under an unreadable one still resolves.

The go-get exception is removed from withAccess entirely. Every Git, dumb-HTTP, and LFS route now enforces the repository existence and access checks regardless of the query string. The two LFS basic handlers also check for a missing repository, as their siblings did, so a future routing mistake returns a 404 rather than a panic.

AccessLevelForUser used to prefer the repository attached to the request over the name it was asked about. During the walk-up those differ, so the access check now always looks the repository up by the name it is given.

Bad credentials on a go-get request now return 403, the same as on the Git routes. Previously they were treated as anonymous for paths that were not themselves repositories.

On the Git and LFS routes, any repository the caller cannot read now gets one answer, decided in one place: 403 when the credentials are wrong, 401 with a credential prompt when the caller is anonymous, and 404 when they are signed in. This matches how GitHub responds. The LFS write checks now run after the read check, and a JWT presented for a missing repository is rejected as an invalid token like any other.

Two behaviours change as a result. An anonymous clone of a mistyped repository name now prompts for credentials instead of reporting that the repository does not exist, and a signed-in user without access to a private repository now gets "not found" instead of a credential prompt.

Pushing over HTTP to a name that does not exist still creates the repository, so a user allowed to create repositories can still tell a taken name from a free one by trying to push. That is inherent to push-to-create and is not changed here.

Workarounds

None. Upgrade to the patched release.

Disabling the HTTP server (http.enabled: false) removes the exposure, at the cost of HTTP Git access. Setting anon-access to no-access limits the disclosure to authenticated users.

In Soft Serve, an authenticated repo import can clone server-local private repositories in github.com/charmbracelet/soft-serve

soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import in github.com/charmbracelet/soft-serve

Soft Serve Affected by an Authentication Bypass in github.com/charmbracelet/soft-serve

Soft Serve is missing an authorization check in LFS lock deletion in github.com/charmbracelet/soft-serve

Soft Serve does not sanitize ANSI escape sequences in user input in github.com/charmbracelet/soft-serve

Soft Serve is vulnerable to SSRF through its Webhooks in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to arbitrary file writing through SSH API in github.com/charmbracelet/soft-serve

Soft Serve vulnerable to path traversal attacks in github.com/charmbracelet/soft-serve