CVE-2026-40189: Critical Authorization Bypass in goshs State-Changing Routes

The goshs application functions as a lightweight, Go-based HTTP server designed to facilitate file sharing and directory serving. Administrators utilize a file-based Access Control List (ACL) mechanism, implemented via a .goshs file, to enforce authentication requirements on specific directories. This file typically contains Basic Authentication credentials or policy directives that restrict access to authorized personnel. The application relies on these policies to protect sensitive data from unauthorized access over the network.

CVE-2026-40189 represents a critical failure in the enforcement of this authorization model, classified under CWE-862: Missing Authorization. The vulnerability arises because the server exclusively validates the .goshs policy during HTTP GET requests associated with file reads and directory listings. State-changing HTTP methods bypass these validation checks entirely. This architectural flaw exposes the core configuration files to arbitrary modification by unauthorized network actors.

An unauthenticated attacker leveraging this vulnerability can target the .goshs file directly using HTTP DELETE or PUT methods. By deleting or overwriting the configuration file, the attacker neutralizes the access controls for the target directory. This results in an immediate downgrade of the directory's security posture to public access, permitting the attacker to perform unrestricted read, write, and delete operations on the previously protected files.

The fundamental flaw in goshs stems from a decoupled routing and authorization architecture. The HTTP server routes incoming requests to specific handler functions based on the HTTP method and query parameters. The handlers responsible for directory traversal and file retrieval (GET) correctly invoke the authorization middleware that parses the .goshs file and enforces Basic Authentication. The handlers responsible for file creation (POST /upload, PUT), directory creation (?mkdir), and deletion (?delete) do not invoke this middleware.

This omission allows an unauthenticated request to reach the filesystem execution context without passing through the intended security boundary. When an attacker sends a DELETE request targeting a specific file path, the deleteFile handler executes the os.Remove operation directly. Since the application does not evaluate the .goshs policy prior to executing the filesystem command, the operation succeeds regardless of the directory's intended protection status.

Furthermore, the original authorization implementation exhibited a critical design limitation regarding inheritance. The goshs server evaluated ACLs on a strictly per-directory basis. A .goshs file located in a parent directory applied solely to the files immediately within that directory. Subdirectories did not inherit the parent's access control policy. This lack of recursive evaluation required administrators to manually place a .goshs file in every subdirectory to maintain a secure perimeter, increasing the likelihood of misconfiguration and unauthorized access to nested files.

The remediation applied in commit f212c4f4a126556bab008f79758e21a839ef2c0f introduces a systemic fix to both the authorization bypass and the lack of ACL inheritance. The patch implements a recursive lookup function named findEffectiveACL. This function intercepts requests and traverses the directory tree upwards from the requested path to the webroot. It returns the nearest .goshs policy file, ensuring that subdirectories appropriately inherit access controls defined by their parent directories.

To address the missing authorization on state-changing routes, the developers integrated findEffectiveACL and a new applyCustomAuth function into all relevant mutation handlers. The deleteFile, handleMkdir, put, and upload handlers now explicitly validate the effective ACL before processing the request payload or interacting with the filesystem. This ensures that unauthorized actors cannot execute mutation operations within protected directory trees.

The patch also introduces an explicit safeguard to protect the .goshs file from modification, regardless of the user's authentication status. The developers hardcoded a filepath evaluation within the mutation handlers to reject any operation targeting the configuration file itself.

// Annotated patch excerpt from the delete handler
// The filepath.Base function extracts the final element of the path.
if filepath.Base(deletePath) == ".goshs" {
    // Direct interaction with the ACL file is explicitly forbidden.
    fs.handleError(w, req, fmt.Errorf("cannot delete ACL file"), http.StatusForbidden)
    return
}

Despite these improvements, the patch introduces a secondary concern regarding filesystem case sensitivity. The validation logic relies on a strict string equality check against the literal value ".goshs". On case-insensitive file systems such as Windows NTFS or macOS APFS, the operating system treats .GOSHS, .GoShs, and .goshs as the same underlying file. If the Go application does not normalize the input path to lowercase before performing the equality check, an attacker might bypass the hardcoded safeguard by requesting the deletion of .GOSHS.

Exploitation of CVE-2026-40189 follows a deterministic, three-stage process requiring zero prerequisites beyond network line-of-sight to the goshs service. The attacker begins by enumerating the target server to identify protected directories. This is accomplished by issuing standard HTTP GET requests to various endpoints and monitoring for HTTP 401 Unauthorized responses. A 401 response confirms the presence of an active .goshs policy enforcing access control on that specific path.

The attack phase involves sending a crafted state-changing request to eliminate the policy file. The attacker constructs an HTTP DELETE request targeting the exact path of the configuration file within the protected directory (e.g., DELETE /protected_dir/.goshs HTTP/1.1). Because the application routes the DELETE request directly to the unauthenticated filesystem handler, the operation executes successfully. The server deletes the .goshs file from the disk and returns an HTTP 200 OK or 204 No Content response.

Upon successful deletion, the directory immediately defaults to a public access state. The attacker proceeds to the post-exploitation phase by issuing a subsequent GET request to the target directory. The server, no longer finding a .goshs file, grants full read access to all files within the directory. The attacker can then utilize the PUT or POST methods to upload malicious payloads, overwrite existing files, or exfiltrate sensitive data, achieving full compromise of the application's data layer.

The vulnerability carries a CVSS 4.0 score of 9.3, indicating a critical severity level. The attack vector is strictly network-based, requires no specific preconditions, and demands zero privileges or user interaction. The impact on confidentiality, integrity, and availability is rated as high. An attacker can permanently destroy hosted data, exfiltrate sensitive internal documents, and replace legitimate binaries with malicious counterparts.

The operational impact scales linearly with the sensitivity of the data hosted by the goshs instance. If the server functions as a repository for internal configuration files, credentials, or source code, the breach directly compromises those assets. The ability to overwrite files provides a direct path to integrity violation, allowing the attacker to distribute trojanized software or modify application state data served to legitimate users.

System-level consequences depend entirely on the execution context of the goshs binary. If the server process runs with elevated privileges, the attacker gains read and write capabilities across the underlying operating system. Even when executed with restricted permissions, the total compromise of the application's operational envelope provides a persistent foothold for further internal network reconnaissance and lateral movement.

The definitive remediation for CVE-2026-40189 is upgrading the goshs application to version 2.0.0-beta.4 or later. This release incorporates the findEffectiveACL implementation and the hardcoded protection mechanisms for the .goshs configuration file. Administrators must replace the vulnerable binary and restart the service to apply the fix.

In environments where immediate patching is not feasible, administrators must apply compensating controls at the operating system level. The user account executing the goshs process should be restricted from modifying the .goshs files. Administrators can enforce this by changing the file ownership to root and setting the permissions to read-only (e.g., chmod 444 .goshs). This OS-level restriction prevents the os.Remove call from succeeding, effectively neutralizing the unauthenticated deletion vector.

Network administrators should deploy Web Application Firewall (WAF) rules to inspect incoming HTTP traffic targeting the goshs service. The WAF policy must explicitly block any request utilizing the PUT, POST, or DELETE methods that includes the string .goshs within the URI path or the multipart form data parameters. Security operations teams should simultaneously monitor server access logs for HTTP 200 or 204 responses to state-changing requests targeting .goshs files, as these indicate successful exploitation attempts.