Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/patrickhener/goshs/v2 >= 2.0.0-beta.4, <= 2.0.0-beta.5
Fixed in
2.0.0-beta.6· Vendor fix available
Issue
goshs leaks file-based ACL credentials through its public collaborator feed when the server is deployed without global basic auth. Requests to .goshs-protected folders are logged before authorization is enforced, and the collaborator websocket broadcasts raw request headers, including Authorization. An unauthenticated observer can capture a victim's folder-specific basic-auth header and replay it to read, upload, overwrite, and delete files inside the protected subtree. I reproduced this on v2.0.0-beta.5, the latest supported release as of April 10, 2026. Details The main web UI and collaborator websocket stay public when goshs is started without global -b user:pass authentication: - httpserver/server.go:72-85 only installs BasicAuthMiddleware() when a global username or password is configured The vulnerable request is logged before .goshs authorization is enforced: - httpserver/handler.go:277-279 calls emitCollabEvent() and logger.LogRequest() before the protected file is…
Recommended action: Upgrade to 2.0.0-beta.6 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/patrickhener/goshs/v2 >= 2.0.0-beta.4, <= 2.0.0-beta.5
Fixed in
2.0.0-beta.6· Vendor fix available
Issue
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…
Recommended action: Upgrade to 2.0.0-beta.6 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.