Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/charmbracelet/soft-serve >= 0.6.0, < 0.12.3
Fixed in
0.12.3· Vendor fix available
Issue
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 / .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…
Recommended action: Upgrade to 0.12.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/charmbracelet/soft-serve >= 0.5.0, < 0.12.3
Fixed in
0.12.3· Vendor fix available
Issue
Soft Serve answers Go's `?go-get=1` requests by walking up the requested path until it finds a repository, then rendering that repository's name and clone URL into a `go-import` meta tag. The walk checked that each candidate repository existed, but never that the caller could read it. A request for a path inside a private repository, such as `GET /secret/anything?go-get=1`, therefore returned `200` naming `secret` and its clone URL, even though `GET /secret?go-get=1` correctly returned `404`. The same `?go-get=1` exception in the HTTP access middleware also let requests reach the LFS and dumb-HTTP routes with the repository existence check skipped, where two LFS handlers dereferenced the missing repository and panicked. The same disclosure appears without `?go-get=1`. The Git and LFS routes answered a repository the caller could not read differently depending on whether it existed: an anonymous clone of a private repository got `401` while a missing one got `404`, and a…
Recommended action: Upgrade to 0.12.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/charmbracelet/soft-serve >= 0.6.0, < 0.11.6
Fixed in
0.11.6· Vendor fix available
Issue
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…
Recommended action: Upgrade to 0.11.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/charmbracelet/soft-serve >= 0.6.0, < 0.11.4
Fixed in
0.11.4· Vendor fix available
Issue
While auditing the codebase in the wake of the webhook SSRF fix shipped in v0.11.1 (GHSA-vwq2-jx9q-9h9f), it was identified that the LFS import path was never given the same treatment. The webhook fix introduced dual-layer SSRF protection — ValidateWebhookURL() at creation time and secureHTTPClient with IP validation at dial time — but the LFS HTTP client still uses http.DefaultClient with no filtering at all. Summary An authenticated SSH user can force the server to make HTTP requests to internal/private IP addresses by running repo import with a crafted --lfs-endpoint URL. The initial batch request is blind (the response from a metadata endpoint won't parse as valid LFS JSON), but an attacker hosting a fake LFS server can chain this into full read access to internal services by returning download URLs that point at internal targets. Details The user-controlled endpoint flows through four files with zero validation: 1. User supplies the URL via --lfs-endpoint…
Recommended action: Upgrade to 0.11.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? This issue impacts every Soft Serve instance. A critical authentication bypass allows an attacker to impersonate any user (including Admin) by "offering" the victim's public key during the SSH handshake before authenticating with their own valid key. This occurs because the user identity is stored in the session context during the "offer" phase and is not cleared if that specific authentication attempt fails. Patches Has the problem been patched? What versions should users upgrade to? Yes, please upgrade to version 0.11.3 as soon as possible. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? You need to upgrade
Recommended action: Upgrade to 0.11.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
LFS Lock Force-Delete Authorization Bypass Summary An authorization bypass in the LFS lock deletion endpoint allows any authenticated user with repository write access to delete locks owned by other users by setting the force flag. The vulnerable code path processes force deletions before retrieving user context, bypassing ownership validation entirely. Severity - CWE-863: Incorrect Authorization - CVSS 3.1: 5.4 (Medium) — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L Affected Code File: pkg/web/gitlfs.go Function: serviceLfsLocksDelete (lines 831–945) Endpoint: POST /<repo.git/info/lfs/locks/:lockID/unlock The control flow processes req.Force at line 905 before retrieving user context at line 919: Proof of Concept Setup: Two users with write access to the same repository—User A (lock owner) and User B (attacker). 1. User A creates a lock: 2. User B deletes User A's lock using force flag: 3. Result: Lock deleted successfully with 200 OK. Expected: 403 Forbidden. Suggested Fix Retrieve…
Recommended action: Upgrade to 0.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
We have identified and verified an SSRF vulnerability where webhook URLs are not validated, allowing repository administrators to create webhooks targeting internal services, private networks, and cloud metadata endpoints. AFFECTED COMPONENTS (VERIFIED) 1. Webhook Creation (pkg/ssh/cmd/webhooks.go:125) 2. Backend CreateWebhook (pkg/backend/webhooks.go:17) 3. Backend UpdateWebhook (pkg/backend/webhooks.go:122) 4. Webhook Delivery (pkg/webhook/webhook.go:97) IMPACT This vulnerability allows repository administrators to perform SSRF attacks, potentially enabling: a) Cloud Metadata Theft - Access AWS/Azure/GCP credentials via 169.254.169.254 b) Internal Network Access - Target localhost and private networks (10.x, 192.168.x, 172.16.x) c) Port Scanning - Enumerate internal services via response codes and timing d) Data Exfiltration - Full HTTP responses stored in webhook delivery logs e) Internal API Access - Call internal admin panels and Kubernetes endpoints PROOF OF CONCEPT…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In several places where the user can insert data (e.g. names), ANSI escape sequences are not being removed, which can then be used, for example, to show fake alerts. In the same token, git messages, when printed, are also not being sanitized. Places in which this was found: 1. Repository Description (pkg/backend/repo.go - SetDescription) 2. Repository Project Name (pkg/backend/repo.go - SetProjectName) 3. Git Commit Author Names (pkg/ssh/cmd/commit.go:69) 4. Git Commit Messages (pkg/ssh/cmd/commit.go:71) 5. Access Token Names (pkg/ssh/cmd/token.go:107) 6. Webhook URLs (pkg/ssh/cmd/webhooks.go:72) Patches v0.11.0 Workarounds No. References n/a
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Attackers can create/override arbitrary files with uncontrolled data. For a PoC, spin up an instance of soft-serve as explained in the README, and execute the following command: It should have created a file in /tmp/pwned.
Recommended action: Upgrade to 0.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Path traversal attack gives access to existing non-admin users to access and take over other user's repositories. A malicious user then can modify, delete, and arbitrarily repositories as if they were an admin user without explicitly giving them permissions. Patches This is patched in v0.8.2 Workarounds Single user set-ups are not affected. This only affects multi-user Soft Serve set-ups that enable repository creation for users. Otherwise, upgrading is necessary to circumvent the attack.
Recommended action: Upgrade to 0.8.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Any servers using soft-serve server and git Patches 0.7.5 Workarounds None. References n/a. --- It is possible for a user who can commit files to a repository hosted by Soft Serve to execute arbitrary code via environment manipulation and Git. The issue is that Soft Serve passes all environment variables given by the client to git subprocesses. This includes environment variables that control program execution, such as LDPRELOAD. This can be exploited to execute arbitrary code by, for example, uploading a malicious shared object file to Soft Serve via Git LFS (uploading it via LFS ensures that it is not compressed on disk and easier to work with). The file will be stored under its SHA256 hash, so it has a predictable name. This file can then be referenced in LDPRELOAD via a Soft Serve SSH session that causes git to be invoked. For example: The example LFS file patches a shared library function called by git to execute a shell.
Recommended action: Upgrade to 0.7.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A security vulnerability in Soft Serve could allow an unauthenticated, remote attacker to bypass public key authentication when keyboard-interactive SSH authentication is active, through the allow-keyless setting, and the public key requires additional client-side verification for example using FIDO2 or GPG. This is due to insufficient validation procedures of the public key step during SSH request handshake, granting unauthorized access if the keyboard-interaction mode is utilized. An attacker could exploit this vulnerability by presenting manipulated SSH requests using keyboard-interactive authentication mode. This could potentially result in unauthorized access to the Soft Serve. Patches Users should upgrade to the latest Soft Serve version v0.6.2 to receive the patch for this issue. Workarounds To workaround this vulnerability without upgrading, users can temporarily disable Keyboard-Interactive SSH Authentication using the allow-keyless setting. References…
Recommended action: Upgrade to 0.6.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.