CVE-2026-33353
Authorization Bypass in Soft Serve Git Server Enables Repo Cloning
Publication date: 2026-03-24
Last updated on: 2026-03-25
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| charm | soft_serve | From 0.6.0 (inc) to 0.11.6 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-200 | The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. |
| CWE-862 | The product does not perform an authorization check when an actor attempts to access a resource or perform an action. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-33353 is an authorization flaw in the Soft Serve Git server versions 0.6.0 to before 0.11.6. It allows any authenticated SSH user to clone private Git repositories hosted on the server, including those owned by other users, into new repositories they control. This happens because the import process only checks authorization for the destination repository, not the source repository path, enabling unauthorized access to private data.
Technically, the vulnerability arises during the repository import process where the software does not validate that the remote repository URL is a network URL. Instead, it allows specifying a local server filesystem path, which leads to cloning private repositories without proper authorization.
This issue was fixed in version 0.11.6 by adding validation to ensure that only network URLs are accepted during repository import, blocking raw-path imports.
How can this vulnerability impact me? :
This vulnerability can lead to unauthorized disclosure of private repository data. Any authenticated SSH user on a multi-user Soft Serve instance can clone private repositories they do not have permission to access, exposing sensitive information such as source code, secrets, or unreleased projects.
The impact includes confidentiality breaches, potential supply-chain risks if stolen code contains credentials or release materials, and loss of trust or competitive advantage due to exposure of internal projects.
Operators hosting Soft Serve for multiple users or teams, and owners of private repositories on the same instance, are particularly at risk.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by checking if unauthorized repository imports from local filesystem paths are possible on your Soft Serve instance. Specifically, you can test whether an authenticated SSH user can import a server-local Git repository path into a new repository they control.'}, {'type': 'paragraph', 'content': 'A practical detection method involves attempting to import a private repository using the import command with a local filesystem path as the remote URL. For example, an authenticated user can try the following command:'}, {'type': 'list_item', 'content': 'usoft repo import stolen "$DATA_PATH/repos/secret.git"'}, {'type': 'paragraph', 'content': 'If the import succeeds and the user can then clone the newly created repository and access private data, the system is vulnerable.'}, {'type': 'paragraph', 'content': 'Additionally, verifying the Soft Serve version is important. Versions from 0.6.0 up to but not including 0.11.6 are vulnerable. Running a command to check the installed version can help identify if the system is patched.'}, {'type': 'list_item', 'content': 'soft-serve --version'}, {'type': 'paragraph', 'content': 'If the version is below 0.11.6, the system is vulnerable.'}] [2]
What immediate steps should I take to mitigate this vulnerability?
The immediate and recommended mitigation step is to upgrade Soft Serve to version 0.11.6 or later, where this vulnerability has been fixed.
The fix includes validation that blocks importing repositories using local filesystem paths, ensuring only network URLs are accepted during repository import.
After upgrading, verify the authenticity and integrity of the release artifacts by downloading the provided checksum files and using the cosign tool to verify signatures, followed by checksum validation with sha256sum.
- Download `checksums.txt` and `checksums.txt.sigstore.json` from the v0.11.6 release page.
- Verify the signature using cosign with the specified certificate identity and OIDC issuer.
- Validate the checksums of downloaded artifacts using sha256sum.
If immediate upgrade is not possible, restrict SSH access to trusted users only and monitor repository import activities closely to detect suspicious imports from local paths.