GHSA-F3FJ-9625-RV3M
Vulnerability from github – Published: 2026-10-30 14:53 – Updated: 2026-10-30 14:53Summary
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/charmbracelet/soft-serve"
},
"ranges": [
{
"events": [
{
"introduced": "0.6.0"
},
{
"fixed": "0.12.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-30T14:53:57Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nSoft 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.\n\nA 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.\n\n## Impact\n\nAn 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 /\u003crepo\u003e.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.\n\nThe stale record lasts until the server restarts or the entry is evicted, and the operator gets no sign of it. `repo private \u003cname\u003e` reads the database directly and reports `true`, and the `visibility_change` webhook is not sent, because its check reads the same stale record.\n\nWrite 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.\n\nDeployments 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.\n\nReachable 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\u0027s 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).\n\n## Root Cause\n\nThe cache was the source of truth for access checks, and clearing it was treated as a step before the write rather than after it.\n\n`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.\n\n`SetPrivate` ran in this order:\n\n```go\nd.cache.Delete(name)\n... d.db.TransactionContext(ctx, func(tx *db.Tx) error {\n\t... writes or removes git-daemon-export-ok ...\n\treturn d.store.SetRepoIsPrivateByName(ctx, tx, name, private)\n})\n```\n\nA 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.\n\n`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.\n\nMoving 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.\n\n## Affected Versions\n\nv0.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.\n\n## Patches\n\nFixed in `v0.12.3`.\n\nThe 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.\n\nRemoving 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.\n\nThe `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.\n\n## Workarounds\n\nIt is recommended to upgrade to the patched release.\n\nNo 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.",
"id": "GHSA-f3fj-9625-rv3m",
"modified": "2026-10-30T14:53:57Z",
"published": "2026-10-30T14:53:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-f3fj-9625-rv3m"
},
{
"type": "WEB",
"url": "https://github.com/charmbracelet/soft-serve/commit/0a4e6f0b7e063927c7128756e1c1b3db871edabf"
},
{
"type": "WEB",
"url": "https://github.com/charmbracelet/soft-serve/commit/5b307b4da4db285f797cc028b381ba4d3d853019"
},
{
"type": "WEB",
"url": "https://github.com/charmbracelet/soft-serve/commit/e398b4dde723437f637b06710e0938d349b360e8"
},
{
"type": "PACKAGE",
"url": "https://github.com/charmbracelet/soft-serve"
},
{
"type": "WEB",
"url": "https://github.com/charmbracelet/soft-serve/releases/tag/v0.12.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "charmbracelet/soft-serve: Race in `SetPrivate` leaves a private repository readable by unauthenticated users"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.