goshs File-Based ACL Credential Leak Vulnerability Allowing Unauthorized Access to Protected Content

A vulnerability in goshs versions 2.0.0-beta.4 prior to 2.0.0-beta.5 allows for the leakage of file-based Access Control List (ACL) credentials through the public collaborator feed. This issue arises when the server is deployed without global basic authentication. Requests to .goshs-protected folders are logged before authorization is applied, and the collaborator websocket broadcasts raw request headers, including the Authorization header. An unauthenticated observer can intercept a victim's folder-specific basic-auth header and use it to access, modify, or delete files within the protected subtree. This vulnerability has been addressed in goshs version 2.0.0-beta.6.

Impact

Exploitation of this vulnerability leads to unauthorized access to .goshs-protected content, allowing an attacker to read, upload, overwrite, and delete files within the protected subtree. The vulnerability also involves the unauthorized interception of sensitive information, specifically folder-level basic-auth credentials, which can be reused to bypass authentication controls.

Reproduction

The vulnerability can be reproduced by deploying goshs without global basic authentication. Once the server is running, an unauthenticated websocket observer can be connected to the public collaborator feed. When a victim request is made to a .goshs-protected folder, the Authorization header is leaked to the websocket observer before the request is authorized. This leaked header can then be replayed to access the protected content. A proof-of-concept script is available that automates this process.

Remediation

To address this vulnerability, it is recommended to avoid storing or broadcasting sensitive headers such as Authorization in collaborator events. Additionally, collaborator logging should be delayed until after access-control checks are completed, and only minimal metadata should be logged instead of raw headers and bodies. Finally, the collaborator websocket and panel should be protected with the same or stronger authentication as the resources being observed.