Skip to content

GHSA-x9hg-5q6g-q3jr: set fixed version to 0.14.3 (CVE-2025-51471) - #8826

Open
nghiadaulau wants to merge 1 commit into
github:nghiadaulau/advisory-improvement-8826from
nghiadaulau:nghiadaulau-GHSA-x9hg-5q6g-q3jr
Open

GHSA-x9hg-5q6g-q3jr: set fixed version to 0.14.3 (CVE-2025-51471)#8826
nghiadaulau wants to merge 1 commit into
github:nghiadaulau/advisory-improvement-8826from
nghiadaulau:nghiadaulau-GHSA-x9hg-5q6g-q3jr

Conversation

@nghiadaulau

Copy link
Copy Markdown

Summary

This advisory (CVE-2025-51471, Ollama cross-domain token exposure) currently has no fixed event — only last_affected: 0.9.6. Two consequences:

  1. Downstream consumers that require a fixed event report every version of github.com/ollama/ollama as vulnerable forever. The Go vulnerability database mirrors this advisory as GO-2025-3824 with introduced: 0 and no fix (its report notes "No patched version specified"), so govulncheck and pkg.go.dev flag current releases such as v0.32.4.
  2. last_affected: 0.9.6 is also inaccurate — the vulnerable code was unchanged well past 0.9.6.

This PR replaces last_affected: 0.9.6 with fixed: 0.14.3 and adds a reference to the upstream fix.

Evidence

The advisory describes the flaw in server.auth.getAuthorizationToken: the realm URL from a WWW-Authenticate header is followed without checking that it belongs to the same host as the original request.

The fix is ollama/ollama#13738 ("server: reject unexpected auth hosts"), merged 2026-01-16 as commit 7601f0e. It adds the missing same-host check to that exact function:

 func getAuthorizationToken(ctx context.Context, challenge registryChallenge, originalHost string) (string, error) {
 	redirectURL, err := challenge.URL()
 	if err != nil {
 		return "", err
 	}

+	// Validate that the realm host matches the original request host to prevent sending tokens cross-origin.
+	if redirectURL.Host != originalHost {
+		return "", fmt.Errorf("realm host %q does not match original host %q", redirectURL.Host, originalHost)
+	}

server/auth.go is byte-identical between v0.9.6 and v0.14.2 (blob dcef5bf9cc249e624758551a384646d28e7c2c57 at both tags), so no earlier release carried the check:

$ git ls-tree v0.9.6  server/ | grep auth.go
100644 blob dcef5bf9cc249e624758551a384646d28e7c2c57	server/auth.go
$ git ls-tree v0.14.2 server/ | grep auth.go
100644 blob dcef5bf9cc249e624758551a384646d28e7c2c57	server/auth.go

$ git tag --contains 7601f0e93e53858f09136a7e4ccf674a9b4580bd | grep -v rc | sort -V | head -1
v0.14.3

v0.14.3 is therefore the first release containing the fix, making the affected range [0, 0.14.3).

Note that the reference already present in this advisory, ollama/ollama#10750, is the reporter's proposed patch, which was closed unmerged; PR #13738 is the change that actually shipped. I left #10750 in place and added #13738 alongside it.

Changes

All information above is from public sources; no new or undisclosed vulnerability details are included.

@github-actions
github-actions Bot changed the base branch from main to nghiadaulau/advisory-improvement-8826 July 27, 2026 07:13
@dragoncoil2609

Copy link
Copy Markdown

very good

@pho-veteran

Copy link
Copy Markdown

I think this is a very solid and well-supported improvement.

I especially appreciate the effort to verify the affected range against the upstream source history instead of simply updating the advisory based on an assumption. Showing that server/auth.go remained unchanged between v0.9.6 and v0.14.2, identifying the actual merged fix in ollama/ollama#13738, and confirming v0.14.3 as the first stable release containing it makes the reasoning behind this change very clear.

Replacing last_affected: 0.9.6 with fixed: 0.14.3 also gives downstream consumers a much more accurate affected range. This should prevent tools that rely on an explicit fixed event from continuing to classify newer, patched Ollama releases as vulnerable.

Adding the reference to the fix that actually shipped is also a valuable improvement for traceability, while preserving the earlier unmerged proposal as historical context.

Overall, this looks like a carefully researched correction with a meaningful impact on the accuracy of the advisory and the tools consuming it. Thanks for putting together such detailed evidence!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants