GHSA-f3fj-9625-rv3m

charmbracelet/soft-serve: Race in `SetPrivate` leaves a private repository readable by unauthenticated users

Published

2026-10-30

Modified

2026-10-30

Sources

github-advisory

Summary

## 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 / .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 ` 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: ```go 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 th

Affected packages

Remediation: Upgrade to 0.12.3 or later.

References

• https://github.com/advisories/GHSA-f3fj-9625-rv3m