github.com/patrickhener/goshs/v2

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

Summary

Start goshs v2.1.3 with -b 'admin:' -sftp. No -fkf. SFTP accepts connections without password. CVE-2026-40884 blocks the empty-username variant (-b ':pass'). The empty-password variant bypasses that fix.

CVE-2026-40884

CVE-2026-40884 (GHSA-c29w-qq4m-2gcv, Apr 13 2026) reported the empty-username case: -b ':pass' with -sftp. sftpserver.go:85 uses &&:

if s.Username != "" && s.Password != "" {
    sshServer.PasswordHandler = func(ctx ssh.Context, password string) bool {
        return subtle.ConstantTimeCompare([]byte(ctx.User()), []byte(s.Username)) == 1 && subtle.ConstantTimeCompare([]byte(password), []byte(s.Password)) == 1
    }
}

Empty username → Username != "" false → PasswordHandler nil. No -fkf means PublicKeyHandler also nil. gliderlabs/ssh sees all handlers nil and sets NoClientAuth = true. Unauthenticated access.

Patrickhener fixed it with a sanity check at sanity/checks.go:114-118:

if opts.FTP && opts.FTPSFTPMode && strings.HasPrefix(opts.BasicAuth, ":") {
    logger.Fatal("When using SFTP with password authentication, the username cannot be empty. ...")
}

HasPrefix(":") catches empty username. It does not catch empty password.

Empty Password Bypass

Same && at sftpserver.go:85. Same nil handler. Different input:

goshs -b 'admin:' -sftp

• Username = "admin", Password = ""
• Username != "" && Password != "" → false. Password is empty.
• PasswordHandler not set. No -fkf → PublicKeyHandler not set.
• gliderlabs/ssh → NoClientAuth = true.

CVE-2026-40884 patched the symptom (empty username) with input validation. Root cause (&&) stayed in the code. v2.1.3 still has it. That makes any unanticipated input format exploitable.

PoC

#!/usr/bin/env bash
set -euo pipefail

HOST="${1:-127.0.0.1}"
PORT="${2:-2121}"

echo "[*] Connecting to goshs SFTP at $HOST:$PORT with empty password..."
echo "ls -la /" | sftp -o StrictHostKeyChecking=no \
  -o UserKnownHostsFile=/dev/null \
  -o PreferredAuthentications=none,password \
  -o PubkeyAuthentication=no \
  -P "$PORT" -b - admin@"$HOST" 2>&1 && \
  echo "[+] VULNERABLE: Connected without password!" || \
  echo "[-] Connection failed (patched or not running)"

Root Cause

// Wrong: &&
if s.Username != "" && s.Password != "" {

// Correct: ||
if s.Username != "" || s.Password != "" {

&& blocks PasswordHandler when either field is empty. || installs it when either field is set.

Incomplete Fix

Patrickhener added HasPrefix(":") at sanity/checks.go:116. Two gaps remain:

1. && still at sftpserver.go:85 in v2.1.3
2. No HasSuffix(":") check for empty password

Impact

• Unauthenticated SFTP file access (read, write, delete, rename)
• Same impact as CVE-2026-40884 via a different input
• Exploitable with -b 'user:' and no -fkf

Affected

All goshs versions including v2.1.3. CVE-2026-40884 fix does not cover this variant.

Recommended Fix

1. && → || at sftpserver/sftpserver.go:85
2. HasSuffix(":") check at sanity/checks.go
3. Shared auth handler setup for HTTP and SFTP code paths

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

The PUT upload handler (httpserver/updown.go) lacks the CSRF token validation that was added to the POST upload handler during the GHSA-jrq5-hg6x-j6g3 fix. Combined with the unconditional Access-Control-Allow-Origin: * on the OPTIONS preflight handler (httpserver/server.go), any website can write arbitrary files to a goshs instance through the victim's browser — bypassing network isolation (e.g. localhost, internal network).

Details

Root Cause 1 — Missing CSRF on PUT (httpserver/updown.go:19)

When GHSA-jrq5-hg6x-j6g3 was fixed (commit e3c3d37), checkCSRF() was added to the POST upload() function (line 78) but not to the PUT put() function directly above it in the same file. This means PUT requests are accepted without any CSRF token.

// POST — protected 
func (fs *FileServer) upload(w http.ResponseWriter, req *http.Request) {
    if !fs.checkCSRF(w, req) { return }
    // ...
}

// PUT — unprotected 
func (fs *FileServer) put(w http.ResponseWriter, req *http.Request) {
    // No checkCSRF call
    // ...
}

Root Cause 2 — Wildcard CORS (httpserver/server.go:126)

The OPTIONS handler unconditionally returns permissive CORS headers:

w.Header().Set("Access-Control-Allow-Origin", "*")
w.Header().Set("Access-Control-Allow-Methods", "POST, PUT, OPTIONS")
w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")

This allows any website's JavaScript to pass the browser's CORS preflight check and send PUT requests to the goshs server.

PoC

poc.zip

Please extract the uploaded compressed file before proceeding

1. bash poc.sh

Impact

• Arbitrary file write to the goshs webroot from any website the victim visits
• File overwrite — existing files can be silently replaced

Summary

sendFile derives the served filename from the raw request path while opening the file from the cleaned path, so appending a trailing slash empties the derived name and defeats both the never-serve rule for the ACL file and the block list.

Finding (Medium): trailing-slash ACL and hidden-file bypass

httpserver/handler.go, sendFile (lines 789-801) takes the filename from the RAW req.URL.Path while the file itself is opened from the filepath.Clean-ed path. The two disagree, and a trailing slash makes the derived name the empty string. Both protections key on that derived name, so both are defeated: the rule that never serves the .goshs ACL file, and the acl.Block list.

Measured, with negative controls:

GET /blocked/secret.txt    -> 404          (control, correctly blocked)
GET /blocked/secret.txt/   -> 200 + contents
GET /blocked/.goshs/       -> 200, returns the ACL file itself,
                              including the admin:$2a$... bcrypt hash

Unauthenticated when the ACL is configured block-only (common usage). Stated precisely: AUTHENTICATION IS NOT BYPASSED. An unauthenticated request against a directory protected by authentication still returns 401 under the same trick; I tested that. The claim is specifically that the block list and the ACL-file protection are bypassed. In-tree evidence that sendFile is the defect: the sibling handlers doDir and bulkDownload both derive the name correctly; sendFile is the lone outlier.

Suggested fixes

1. Derive the served filename from the same cleaned path used to open the file, so the authorization decision and the file access cannot disagree.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback with negative controls, including the 404-versus-200 pair and the authenticated-directory control that shows authentication is not affected.

Summary

The multipart upload filename fix splits on the path separator but never rejects dot-dot, allowing a write outside the served tree.

Finding (Medium): upload filename escapes the served tree (residual of CVE-2026-35393)

The multipart filename fix (updown.go lines 135-136) splits on the path separator but never rejects "..". Uploading with filename=".." results in os.Create against the parent of the upload folder with a trailing marker character, outside the served tree, and the subsequent failed rename leaves that file behind. Verified: a file containing ESCAPED_WRITE_PROOF was written outside the webroot, unauthenticated, with the default configuration. Not claimed: a Windows-specific variant (Go's Part.FileName() already applies filepath.Base).

Suggested fixes

1. Reject any upload filename that is "..", is empty after sanitisation, or resolves outside the upload folder; validate the final resolved destination rather than only transforming the input.

Tooling

AI assistance was used while investigating. The finding was reproduced against a running server on loopback.

Summary

The WebDAV mode-flag guard added to fix GHSA-3whc-qvhv-xqjp still does not enforce --no-delete on the WebDAV MOVE verb. MOVE deletes the source file (rename removes it from its original path), and with Overwrite: T it additionally performs an explicit RemoveAll on the destination. Under -w --no-delete, DELETE is correctly blocked (403) but MOVE still destroys existing files, defeating the documented "Disable the delete option" boundary.

This is a residual of the parent fix: the guard classifies MOVE/COPY as write-only verbs (blocked only under --read-only) and never treats MOVE as a delete, so the --no-delete branch never covers it.

Affected

goshs v2.1.3 (current release, commit ba00ce3). The guard was introduced when GHSA-3whc-qvhv-xqjp was fixed and carries the gap forward.

Details

httpserver/server.go, wdGuard (lines 237-254):

wdGuard := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodPut, "MKCOL", "MOVE", "COPY":
        if fs.ReadOnly {
            http.Error(w, "read-only", http.StatusForbidden)
            return
        }
    case http.MethodDelete:
        if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
            http.Error(w, "delete disabled", http.StatusForbidden)
            return
        }
    case http.MethodGet, http.MethodHead:
        if fs.UploadOnly {
            http.Error(w, "upload-only", http.StatusForbidden)
            return
        }
    }
    ...

MOVE lives in the first case and is gated only by fs.ReadOnly. It is never checked against fs.NoDelete. But MOVE in golang.org/x/net/webdav (file.go, moveFiles) calls fs.Rename(ctx, src, dst), which removes the source from its original location, and when the Overwrite: T header is present it first calls fs.RemoveAll(ctx, dst) on an existing destination. Both are deletions. So --no-delete, whose help text reads "Disable the delete option", does not disable deletion via MOVE.

The .goshs ACL layer (webdav_acl.go) checks auth and block-lists only; it does not enforce the mode flags, so it does not close this gap.

Proof of concept

Reproduced live against goshs v2.1.3 on 2026-07-02. Server started with --no-delete and WebDAV enabled:

$ printf 'TOP-SECRET-CONTENTS\n' > webroot/secret.txt
$ printf 'VICTIM-EXISTING-FILE\n'  > webroot/victim.txt
$ goshs -d webroot -i 127.0.0.1 -p 18080 --webdav --webdav-port 18081 --no-delete
INFO  Serving WEBDAV on 127.0.0.1:18081 from webroot

Control - DELETE is correctly blocked:

$ curl -s -i -X DELETE http://127.0.0.1:18081/secret.txt
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt still exists on disk.

Bypass 1 - MOVE removes the source file despite --no-delete:

$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/gone.txt' http://127.0.0.1:18081/secret.txt
HTTP/1.1 201 Created
Server: goshs/v2.1.3 (darwin; go1.26.1)

secret.txt is now deleted from disk (its content is at gone.txt).

Bypass 2 - MOVE with Overwrite:T destroys an existing victim file:

# before: victim.txt = VICTIM-EXISTING-FILE
$ curl -s -i -X MOVE -H 'Destination: http://127.0.0.1:18081/victim.txt' -H 'Overwrite: T' http://127.0.0.1:18081/gone.txt
HTTP/1.1 204 No Content
Server: goshs/v2.1.3 (darwin; go1.26.1)
# after:  victim.txt = TOP-SECRET-CONTENTS   (original VICTIM-EXISTING-FILE destroyed via RemoveAll)

Impact

An operator running goshs -w --no-delete -d /srv/artifacts to deliver files that must not be removed still allows any WebDAV client to delete or clobber existing files via MOVE. Confidential existing files can be renamed away or overwritten. The --no-delete control is silently ineffective on the WebDAV port for the MOVE verb.

Suggested fix

Move MOVE (and COPY on collision-with-overwrite, which also deletes) into the delete-gated branch, or add fs.NoDelete to the write-verb branch for MOVE:

case http.MethodPut, "MKCOL", "COPY":
    if fs.ReadOnly {
        http.Error(w, "read-only", http.StatusForbidden)
        return
    }
case "MOVE":
    // MOVE renames (deletes source) and, with Overwrite:T, RemoveAll(dst).
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "move disabled", http.StatusForbidden)
        return
    }
case http.MethodDelete:
    if fs.ReadOnly || fs.UploadOnly || fs.NoDelete {
        http.Error(w, "delete disabled", http.StatusForbidden)
        return
    }

Add an integration test covering MOVE under --no-delete (the current testWebdavMoveCopy only exercises MOVE/COPY in unrestricted mode).

GHSA-wvhv-qcqf-f3cx fixed the per-folder .goshs ACL bypass on the state-changing routes (PUT/POST upload/?mkdir/?delete) and added recursive ACL resolution, and its description states the read/list path correctly enforces .goshs. That premise does not hold for the ?bulk zip-download route. bulkDownload (httpserver/updown.go) takes one or more ?file= parameters, runs each through sanitizePath(fs.Webroot, file), and streams the contents back as a ZIP without ever calling findEffectiveACL/applyCustomAuth. It is dispatched from earlyBreakParameters (?bulk) before the normal doDir/doFile/sendFile flow that performs the ACL check. An unauthenticated attacker can therefore read any file under the webroot protected solely by a .goshs ACL, bypassing both the folder auth (401 on the normal path) and the per-file block list (404 on the normal path). Same authorization-inconsistency root cause as the original advisory, surviving on a read route the fix did not cover.

Proof of concept (live, against the fixed v2.1.0 build which includes fix commit f212c4f4, served with no global -b auth, only a per-folder .goshs): GET /protected/secret.txt -> 401 (ACL enforced on normal path) GET /protected/secret.txt -u admin:admin -> 200 GET /?bulk&file=/protected/secret.txt -> 200, zip contains the protected file contents (BYPASS) GET /?bulk&file=/protected/blocked.txt -> 200, zip contains the block-listed file (block bypass) GET /protected/secret.txt?share -> 403 'Sharing disabled when auth is disabled' (correctly gated, NOT a bypass)

Impact: any unauthenticated network attacker can read files an operator protected with the documented per-folder .goshs ACL/basic-auth feature, by requesting them through ?bulk. Confidentiality only (the write/delete equivalents were closed by GHSA-wvhv-qcqf-f3cx). Applies to deployments relying on .goshs as the access boundary (a server-wide -b basic auth, if configured, also gates ?bulk via its middleware).

Remediation: enforce the effective .goshs ACL inside bulkDownload for every requested file exactly as sendFile/processDir do (resolve findEffectiveACL(filepath.Dir(absPath)) + applyCustomAuth + honor acl.Block), or route ?bulk through the same authorization gate as the normal read path. Audit ?cbDown and other alternate read routes for the same gap.

Credit: anir0y (independent security research).

Unauthenticated Open Redirect, Arbitrary HTTP Response Header Injection, Missing CSRF, and Invisible-Mode Bypass in goshs /?redirect endpoint in github.com/patrickhener/goshs

Summary

The PUT upload handler (httpserver/updown.go) lacks the CSRF token validation that was added to the POST upload handler during the GHSA-jrq5-hg6x-j6g3 fix. Combined with the unconditional Access-Control-Allow-Origin: * on the OPTIONS preflight handler (httpserver/server.go), any website can write arbitrary files to a goshs instance through the victim's browser — bypassing network isolation (e.g. localhost, internal network).

Details

Root Cause 1 — Missing CSRF on PUT (httpserver/updown.go:19)

When GHSA-jrq5-hg6x-j6g3 was fixed (commit e3c3d37), checkCSRF() was added to the POST upload() function (line 78) but not to the PUT put() function directly above it in the same file. This means PUT requests are accepted without any CSRF token.

// POST — protected 
func (fs *FileServer) upload(w http.ResponseWriter, req *http.Request) {
    if !fs.checkCSRF(w, req) { return }
    // ...
}

// PUT — unprotected 
func (fs *FileServer) put(w http.ResponseWriter, req *http.Request) {
    // No checkCSRF call
    // ...
}

Root Cause 2 — Wildcard CORS (httpserver/server.go:126)

The OPTIONS handler unconditionally returns permissive CORS headers:

w.Header().Set("Access-Control-Allow-Origin", "*")
w.Header().Set("Access-Control-Allow-Methods", "POST, PUT, OPTIONS")
w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")

This allows any website's JavaScript to pass the browser's CORS preflight check and send PUT requests to the goshs server.

PoC

poc.zip

Please extract the uploaded compressed file before proceeding

1. bash poc.sh

Impact

• Arbitrary file write to the goshs webroot from any website the victim visits
• File overwrite — existing files can be silently replaced