KEVWire

Security intelligence, with context.

Response snapshot Oct 30, 2026, 17:36 UTC

Back to the wire
Permalink
VulnerabilityGHSA-f3fj-9625-rv3m

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

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.

At a glance

Exploited
Not known
Severity
Not scored yet
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: github.com/charmbracelet/soft-serve: 0.12.3. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-f3fj-9625-rv3m (opens a new tab)

What happened

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

Continue reading

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:

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 ranges reported by GitHub: github.com/charmbracelet/soft-serve: >= 0.6.0, < 0.12.3

Related technology

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-f3fj-9625-rv3m (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-f3fj-9625-rv3m, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 30). charmbracelet/soft-serve: Race in `SetPrivate` leaves a private repository readable by unauthenticated users. https://kevwire.com/record/GHSA-f3fj-9625-rv3m

MLA

"charmbracelet/soft-serve: Race in `SetPrivate` leaves a private repository readable by unauthenticated users." KEVWire, 30 Oct. 2026, kevwire.com/record/GHSA-f3fj-9625-rv3m.

Chicago

KEVWire. "charmbracelet/soft-serve: Race in `SetPrivate` leaves a private repository readable by unauthenticated users." Last modified October 30, 2026. https://kevwire.com/record/GHSA-f3fj-9625-rv3m.

Evidence summary (plain text)

charmbracelet/soft-serve: Race in `SetPrivate` leaves a private repository readable by unauthenticated users (Oct 30, 2026).
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.
Sources:
GitHub-reviewed advisory GHSA-f3fj-9625-rv3m: https://github.com/advisories/GHSA-f3fj-9625-rv3m
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: GHSA-f3fj-9625-rv3m.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 30, 2026, 17:20 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are coming as part of KEVWire Premium: join the waitlist. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail