How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

413,812

Total vulnerabilities in the database

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

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

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.

Published: Oct 30, 2026
Updated: Oct 31, 2026
GHSA: GHSA-f3fj-9625-rv3m
Severity: Medium
Exploit:
CISA KEV:

CVSS v3:

Severity: Medium
Score: 5.9
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

CWEs:

Affected Software
References

Software	Affected versions
github.com/charmbracelet/soft-serve	`>= 0.6.0, < 0.12.3`

Is soft-serve exposed on your perimeter?

A vulnerability database tells you what is broken. Attack surface management tells you where it is running: it discovers your internet-facing assets and flags the ones affected by issues like this one.

What is attack surface management? →

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.