GHSA-7h3j-592v-jcrp: goshs's public collaborator feed leaks .goshs ACL credentials and enables unauthorized access
Summarygoshs 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.DetailsThe 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 configuredThe vulnerable request is logged before `.goshs` authorization is enforced:`httpserver/handler.go:277-279` calls `emitCollabEvent()` and `logger.LogRequest()` before the protected file is passed into ACL enforcement`httpserver/handler.go:291-309` performs folder-level `.goshs` authentication later in `applyCustomAuth()`The collaborator pipeline copies and broadcasts every request header:`httpserver/collaborator.go:22-46` flattens all request headers, including `Authorization`, into the websocket event and sends them to the hub`ws/hub.go:77-84` fans the event out live to all connected websocket clients`ws/hub.go:116-122` replays up to 200 prior HTTP events to newly connected websocket clients via catchupThe frontend also makes the leak easier to understand by decoding authorization values:`assets/js/main.js:627-645` formats and decodes the `Authorization` header for display in the collaborator panelIn practice, a victim request such as:is visible to any public websocket observer before the protected file's ACL check is enforced. The attacker can then replay the leaked header against the same protected folder and gain the victim's effective access.PoCManual verification commands used:`Terminal 1``Terminal 2``Terminal 3`Two terminal commands I ran during local validation:Observed results from manual verification:the anonymous request returned `401`the victim request returned `very secret`the replayed leaked header also returned `very secret`the replayed `PUT` returned `200`the replayed `?delete` returned `200`the public websocket showed `Authorization":"Basic YWRtaW46YWRtaW4="`PoC Video 1:https://github.com/user-attachments/assets/1347838e-28a0-4c9f-be9f-db7e2938c752Single-script verification:Observed script result:`Captured header: Basic YWRtaW46YWRtaW4=``Anonymous GET status: 401``Replayed-header GET body: very secret``Replayed-header PUT status: 200``Replayed-header delete status: 200``[RESULT] VULNERABLE: public collaborator feed leaked ACL credentials that unlocked the protected subtree`PoC Video 2:https://github.com/user-attachments/assets/b25648a9-b96c-46b3-9ee4-0ae4cc1c3472`gosh_poc4` script content:ImpactThis issue is a sensitive information disclosure that becomes an authentication bypass against `.goshs`-protected content. Any unauthenticated observer who can access the public collaborator websocket can steal folder-level basic-auth credentials from a victim request and immediately reuse them to read, upload, overwrite, or delete files inside the protected subtree. Deployments that rely on public goshs access with selective `.goshs`-protected subfolders are directly exposed.RemediationSuggested fixes:Never store or broadcast sensitive headers such as `Authorization`, `Cookie`, or `Proxy-Authorization` in collaborator events.Move collaborator logging until after access-control checks, and log only minimal metadata instead of raw headers and bodies.Protect the collaborator websocket and panel with the same or stronger authentication boundary as the resources being observed.
CVSS v4.0: 7.7
CVSS v3.1: 8.8