The Exploit
A low-privilege user able to call the composer package metadata API can retrieve metadata for a private package owner.
curl -i -H "Authorization: token ATTACKER_TOKEN" \
"https://TARGET/api/packages/victimuser/composer"
The attacker receives 200 OK and JSON containing composer package metadata from victimuser, including source/distribution metadata that should have been restricted. On patched Gitea, the same request is rejected or filtered because the composer response helper now receives the request context and enforces permissions.
What the Patch Did
Before:
resp := createPackageMetadataResponse(setting.AppURL+"api/packages/"+ctx.Package.Owner.Name+"/composer", pds)
After:
resp := createPackageMetadataResponse(ctx, setting.AppURL+"api/packages/"+ctx.Package.Owner.Name+"/composer", pds)
The fix passes the HTTP request context into createPackageMetadataResponse, giving the metadata builder access to authentication/authorization state. This is a context propagation fix: the helper can now decide whether the caller is allowed to see private package source metadata.
Root Cause
This was an information disclosure bug (CWE-200): the composer package metadata endpoint built a response without supplying the request context to the helper that serializes package metadata. The attacker-controlled request arrives at /api/packages/<owner>/composer; the route constructs a response URL from ctx.Package.Owner.Name and calls createPackageMetadataResponse(...) without ctx. That helper therefore lacked the trust boundary information needed to decide if the caller was authorized for private package metadata, so it exposed sensitive source metadata regardless of visibility.
Why It Works
The only load-bearing change is the added ctx argument. Without that line, the helper still cannot inspect the caller’s auth state or package visibility and remains blind to whether private package metadata should be filtered. The rest of the patch is just signature propagation; the developer added the extra parameter so downstream code could perform permission-aware response generation. If that line were removed, the bug would still be exploitable.
Hardening Checklist
- Pass request context into all helper functions that generate authorization-sensitive API responses.
- Enforce package visibility checks before serializing metadata, using explicit authorization logic rather than implicit path-based assumptions.
- Treat package metadata endpoints as sensitive resources and return
http.StatusForbiddenfor unauthorized access. - Avoid constructing API responses from owner/package path values alone; include the caller’s
ctxor auth token state in permission decisions.
References
- https://nvd.nist.gov/vuln/detail/CVE-2026-27771