Critical ACL bypass fixed in goshs state-changing routes

TL;DR — goshs can enforce per-folder .goshs auth for reads but still allow unauthenticated writes/deletes, letting attackers delete the .goshs policy file and expose previously protected content.

What happened

goshs is a SimpleHTTPServer written in Go that supports a per-folder .goshs ACL/basic-auth mechanism intended to protect directory listings and file reads. A Critical GitHub Security Advisory (CVE-2026-40189) reports that while the read/list handlers correctly enforce .goshs, multiple state-changing routes bypass authorization checks entirely.

Per the advisory, an unauthenticated attacker can upload files with PUT, upload files with multipart POST /upload, create directories via ?mkdir, and delete files via ?delete even inside a .goshs-protected directory. The impact escalates because the attacker can delete the .goshs file itself (via the unauthenticated delete path), removing the folder’s auth policy and making previously protected files publicly accessible.

This is explicitly not a path traversal issue; it’s an authorization parity failure (reads are protected; writes/deletes are not). These “inconsistent auth between read and mutation paths” bugs are particularly dangerous in file servers because they can turn a scoped ACL feature into a false security boundary while still allowing destructive remote actions.

Who is impacted

• Deployments running versions listed as affected in the advisory (<= 2.0.0-beta.3).
• Instances that rely on the per-folder .goshs ACL/basic-auth feature to protect sensitive directories.
• Any internet-exposed goshs service where unauthenticated users can reach mutation endpoints (e.g., PUT, POST /upload, ?delete, ?mkdir) and the server filesystem contains secrets or high-value content under the served root.

What to do now

• Follow vendor remediation guidance and apply the patched version listed in the advisory.

  "Patched versions" v2.0.0-beta.4

• Inventory where goshs is deployed and whether .goshs ACLs are used for access control (especially for “protected” folders assumed to be read-restricted).
• Treat this as a potential integrity + confidentiality incident path:
  • Review server logs for unexpected PUT, POST /upload, ?delete, and ?mkdir activity targeting protected directories.
  • If exposure is suspected, audit for dropped/modified files and rotate credentials/secrets that may have been stored under the served root.
• Reduce blast radius where operationally feasible: ensure the service root does not include secrets and restrict network access to mutation routes (uploads/deletes) behind additional controls appropriate to your environment.