Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

GHSA-xgxp-f695-6vrp soft-serve

Fix: charmbracelet/soft-serve@c147421

GHSA-xgxp-f695-6vrp is a Information Exposure vulnerability in github.com/charmbracelet/soft-serve. A fix is available for github.com/charmbracelet/soft-serve — see the affected versions and patch details below.

In Soft Serve, an authenticated repo import can clone server-local private repositories

Also known asCVE-2026-33353GO-2026-4788
Published
Mar 19, 2026
Updated
Mar 27, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 18, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-xgxp-f695-6vrp.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs30th percentile — riskier than 30% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Real-World Exposure

1 pkg affected
🐹github.com/charmbracelet/soft-serve

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

An authorization flaw in repo import allows any authenticated SSH user to clone a server-local Git repository, including another user's private repo, into a new repository they control. This breaks the private-repository confidentiality boundary and should be treated as High severity.

Details

Repo import checks authorization only for the destination repository name, not for the source remote. The destination-side authorization comes from pkg/ssh/cmd/cmd.go:172, which calls pkg/backend/user.go:46. If the destination repo does not already exist, any authenticated user is granted ReadWriteAccess at pkg/backend/user.go:94.

The import command then passes the user-controlled REMOTE into pkg/backend/repo.go:102. In vulnerable HEAD, git.Clone(remote, rp, copts) is reached without validating that remote is actually a network remote. As a result, a user can supply a server filesystem path such as $DATA_PATH/repos/secret.git and cause the server to clone its own local bare repository into a new repo owned by the attacker.

The relevant vulnerable flow is:

PoC

Configuration:

  • Default local test configuration is sufficient.
  • SSH must be enabled.
  • At least two users are needed: one owner/admin and one low-privilege authenticated user.

Reproduction steps:

  1. Start Soft Serve.
  2. As an admin, create a private repo:
soft repo create secret -p
  1. Create a second low-privilege user:
soft user create user1 --key "$USER1_AUTHORIZED_KEY"
  1. Seed the private repo with secret content:
git clone ssh://localhost:$SSH_PORT/secret secret
echo 'top secret' > secret/SECRET.txt
git -C secret add SECRET.txt
git -C secret commit -m 'first'
git -C secret push origin HEAD
  1. Confirm the low-privilege user cannot access the private repo directly:
usoft repo info secret

Expected result:

Error: repository not found
  1. As the low-privilege user, import the server-local bare repo path into a new repo:
usoft repo import stolen "$DATA_PATH/repos/secret.git" --lfs-endpoint http://example.com
  1. Clone the attacker-controlled imported repo and read the secret:
ugit clone ssh://localhost:$SSH_PORT/stolen stolen-clone
cat stolen-clone/SECRET.txt

Expected result:

top secret

Notes:

  • The --lfs-endpoint value is needed to avoid later LFS endpoint handling rejecting the local-path import.

Impact

This is an authorization bypass and confidentiality issue.

Any authenticated SSH user on a multi-user Soft Serve instance can duplicate server-local Git repositories into new repositories they own, even when they are not a collaborator and direct access to the original private repo is denied. The primary impact is unauthorized disclosure of private source code and any secrets committed to those repositories.

Impacted parties:

  • Operators hosting Soft Serve for multiple users or teams
  • Owners of private repositories on the same instance
  • Any deployment where untrusted authenticated users can use repo import

Practical impact:

  • Theft of private source code
  • Disclosure of secrets committed to private repos
  • Exposure of unreleased or internal projects
  • Possible follow-on supply-chain risk if stolen code contains credentials or release material

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/charmbracelet/soft-serve0.6.0&&< 0.11.60.11.6go get github.com/charmbracelet/soft-serve@v0.11.6

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/charmbracelet/soft-serve, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/charmbracelet/soft-serve to 0.11.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xgxp-f695-6vrp is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-xgxp-f695-6vrp can be triaged on real exposure rather than presence alone.

Tailored to GHSA-xgxp-f695-6vrp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary An authorization flaw in `repo import` allows any authenticated SSH user to clone a server-local Git repository, including another user's private repo, into a new repository they control. This breaks the private-repository confidentiality boundary and should be treated as High severity. ### Details Repo import checks authorization only for the destination repository name, not for the source remote. The destination-side authorization comes from [`pkg/ssh/cmd/cmd.go:172`](https://github.com/charmbracelet/soft-serve/blob/main/pkg/ssh/cmd/cmd.go#L172), which calls [`pkg/backend/user.g
O3 Security · Impact-Aware SCA

Is GHSA-xgxp-f695-6vrp in your dependencies?

O3 Security finds GHSA-xgxp-f695-6vrp across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-xgxp-f695-6vrp: soft-serve | O3 Security