WebDAV MOVE Verb Bypasses --no-delete Protection in goshs v2.1.3
A new GitHub Security Advisory (GHSA-hq33-8jgp-8qq3, CVE-2026-64863, CVSS 9.1) reports that goshs v2.1.3's WebDAV mode-flag guard fails to enforce the --no-delete flag on the MOVE verb. According to the advisory, this is a residual gap from a prior fix (GHSA-3whc-qvhv-xqjp): the guard in httpserver/server.go's wdGuard classifies MOVE and COPY as write-only operations gated solely by fs.ReadOnly, never checking fs.NoDelete. Since WebDAV's MOVE performs a rename (removing the source) and, with an Overwrite: T header, an explicit RemoveAll on any existing destination file, both are effectively deletions that slip past the guard. The advisory includes a reproduced proof-of-concept showing DELETE correctly blocked with a 403 while MOVE silently deletes the source file, and a second MOVE with Overwrite: T destroys a separate existing file.
Why It Matters
goshs is a Go-based HTTP/WebDAV file server commonly used for quick file sharing and, per its feature set, in offensive/red-team file-delivery workflows. Operators who explicitly launch it with -w --no-delete to serve files while preventing removal are relying on a control the advisory shows to be silently ineffective on the WebDAV listener. Any WebDAV client with write access can rename existing files out of place or overwrite them, defeating the documented protection without any error or indication of failure. Environments serving confidential artifacts under this flag combination should treat existing files on affected instances as at risk of loss or tampering.
What Defenders Should Watch For
- Identify any goshs instances (v2.1.3 or earlier code carrying the same guard) running with
--webdavand--no-delete, and treat the delete protection as currently unenforced for theMOVEverb. - Monitor WebDAV access/proxy logs for
MOVErequests, particularly those carrying anOverwrite: Theader, against servers where deletion is expected to be disabled. - As an interim mitigation, restrict WebDAV write access via network controls or authentication/ACLs rather than relying on the
--no-deleteflag alone, until an upstream fix lands. - Watch the upstream repository for a patched release addressing the guard, since the advisory includes a suggested code fix (moving
MOVEinto the delete-gated branch).
This is a same-day advisory and details are still developing; a patch status has not been confirmed here. For the full technical writeup, proof-of-concept, and suggested fix, see the original advisory at GHSA-hq33-8jgp-8qq3.