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

Why it is Yellow

• CVSS 5.9 medium
• On your watchlist: Go

Affected packages

References

• https://github.com/advisories/GHSA-f3fj-9625-rv3m
• https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-f3fj-9625-rv3m
• https://github.com/charmbracelet/soft-serve/commit/0a4e6f0b7e063927c7128756e1c1b3db871edabf
• https://github.com/charmbracelet/soft-serve/commit/5b307b4da4db285f797cc028b381ba4d3d853019
• https://github.com/charmbracelet/soft-serve/commit/e398b4dde723437f637b06710e0938d349b360e8
• https://github.com/charmbracelet/soft-serve/releases/tag/v0.12.3
• https://github.com/advisories/GHSA-f3fj-9625-rv3m

Original description

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