goshs is a SimpleHTTPServer written in Go. From 2.0.0-beta.4 to 2.0.0-beta.5, goshs contains a cross-site request forgery issue in its state-changing HTTP GET routes. An external attacker can cause an already authenticated browser to trigger destructive actions such as ?delete and ?mkdir because goshs relies on HTTP basic auth alone and performs no CSRF, Origin, or Referer validation for those routes. This vulnerability is fixed in 2.0.0-beta.6.

Affected: Go: github.com/patrickhener/goshs/v2

### Summary goshs contains a cross-site request forgery issue in its state-changing HTTP GET routes. An external attacker can cause an already authenticated browser to trigger destructive actions such as `?delete` and `?mkdir` because goshs relies on HTTP basic auth alone and performs no CSRF, `Origin`, or `Referer` validation for those routes. I reproduced this on `v2.0.0-beta.5`.

### Details The vulnerable request handling is reachable through normal GET requests:

- `httpserver/handler.go:118-123` dispatches `?mkdir` directly to `handleMkdir()` - `httpserver/handler.go:180-186` dispatches `?delete` directly to `deleteFile()`

Authentication is enforced only by HTTP basic auth:

- `httpserver/middleware.go:20-87` accepts any request that presents valid cached or replayed basic-auth credentials

The resulting state changes hit filesystem mutation sinks:

- `httpserver/handler.go:683-718` calls `os.RemoveAll()` in `deleteFile()` - `httpserver/handler.go:961-1000` calls `os.MkdirAll()` in `handleMkdir()`

Because browsers can replay HTTP basic-auth credentials on subresource requests, an attacker-controlled page can embed:

- `<img src="http://127.0.0.1:18095/victim.txt?delete">` - `<img src="http://127.0.0.1:18095/csrfmade?mkdir">`

If the victim has already authenticated to goshs, those requests are treated as legitimate authenticated actions and the server mutates the filesystem.

### PoC Manual verification commands used:

`Terminal 1`

```bash cd '/Users/r1zzg0d/Documen…