CVE-2026-42091: Verified Repro With Script Download

Summary

goshs (a Go-based HTTP file server CLI) versions ≤ v2.0.1 are vulnerable to Cross-Site Request Forgery (CSRF) on the PUT upload endpoint. While the POST upload handler enforced CSRF token validation via checkCSRF(), the put() handler in httpserver/updown.go omitted this check entirely. Combined with permissive CORS headers (Access-Control-Allow-Origin: *), a malicious cross-origin webpage can silently issue an HTTP PUT and write arbitrary files to any reachable goshs instance.

Impact

• Package: github.com/patrickhener/goshs
• Affected versions: ≤ v2.0.1
• Fixed version: v2.0.2
• CWE: CWE-352 (Cross-Site Request Forgery)
• Severity: Medium (CVSS 3.1 base 6.5)
• Risk: Any website visited by a user whose browser can reach a goshs upload server (loopback, LAN, VPN, etc.) can upload arbitrary files without user consent.

Root Cause

The put() handler in httpserver/updown.go did not call fs.checkCSRF(w, req) before processing the request. The checkCSRF() function (present in httpserver/handler.go) validates the X-CSRF-Token header, absence of Origin/Referer (non-browser clients), or same-origin requests. Because put() skipped this validation, a browser-initiated cross-origin PUT request—bearing an arbitrary Origin header but no valid token—was accepted and the file was written to disk.

The fix commit 0e715b94e10c3d1aa552276000f15f104dee2f32 adds the missing checkCSRF() call at the top of put().

Reproduction Steps

The reproduction is fully automated by repro/reproduction_steps.sh. It performs the following:

1. Clones the goshs repository (or reuses an existing clone).
2. Builds the vulnerable binary at tag v2.0.1 (goshs_v2.0.1).
3. Builds the fixed binary at tag v2.0.2 (goshs_v2.0.2).
4. Starts each binary in a separate scratch upload directory with upload enabled.
5. Sends a cross-origin-style PUT request (curl -X PUT -H "Origin: http://evil.com" --data-binary 'pwned' http://localhost:<port>/pwned.txt).
6. Captures the HTTP response status and checks whether pwned.txt was created.

Expected evidence of reproduction:

• v2.0.1 (vulnerable): HTTP 200 OK and pwned.txt is created in the upload directory.
• v2.0.2 (fixed): HTTP 403 Forbidden and pwned.txt is not created.

Evidence

All logs are written to logs/:

• logs/vuln.log — goshs v2.0.1 server output.
• logs/vuln_result.json — captured HTTP status (200), response body, and file_created: true.
• logs/fixed.log — goshs v2.0.2 server output.
• logs/fixed_result.json — captured HTTP status (403), response body (Forbidden), and file_created: false.

Excerpt from logs/vuln_result.json:

{
  "version": "vuln",
  "http_status": "200",
  "response_body": "",
  "file_created": true,
  "upload_dir": ".../logs/upload_vuln"
}

Excerpt from logs/fixed_result.json:

{
  "version": "fixed",
  "http_status": "403",
  "response_body": "Forbidden",
  "file_created": false,
  "upload_dir": ".../logs/upload_fixed"
}

Environment:

• Go version used for build: go1.24.7 (v2.0.1) / go1.25.0 (v2.0.2)
• OS: Linux (containerized)
• Network: localhost (127.0.0.1)

Recommendations / Next Steps

1. Immediate fix: Upgrade to goshs v2.0.2 or later, which enforces checkCSRF() on every mutating handler (PUT, POST, DELETE).
2. Defense in depth: If running goshs on a publicly reachable interface, pair it with --basic-auth (-b user:pass). When basic auth is configured, the CORS preflight already fails in browsers, providing an additional layer of protection.
3. Regression testing: Any future change to upload handlers should be accompanied by a test that sends a cross-origin request with a mismatched Origin header and asserts 403 Forbidden.

Additional Notes

• Idempotency: The reproduction script was executed twice consecutively and produced identical results both times.
• Edge cases: The script simulates a browser cross-origin request by explicitly sending an Origin header. Without this header, curl requests are treated as non-browser clients and are allowed by design (see checkCSRF logic). The vulnerability specifically affects browser-based CSRF attacks.
• Limitations: The reproduction does not require a real browser or a second origin; the malicious cross-origin behavior is accurately modeled with curl and the Origin header.