Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/patrickhener/goshs < 1.1.5-0.20260401172448-237f3af891a9
Fixed in
1.1.5-0.20260401172448-237f3af891a9· Vendor fix available
Issue
deleteFile() missing return after path traversal check | httpserver/handler.go:645-671 The finding affects the default configuration, no flags or authentication required. Details File: httpserver/handler.go:645-671 Trigger: GET /<path?delete (handler.go:157-160 dispatches to deleteFile) The function detects .. in the decoded path but does not return. Root causes: Missing return after the guard makes the check dead code Impact: Unauthenticated arbitrary file/directory deletion. PoCs: To execute it: ./arbitrarydelete.sh 10.1.2.2 8000 /tmp/canary --- Recommendations Checking that the targeted file is part of the webroot could prevent these attacks. Also, ensure that the method return is called after every error response.
Recommended action: Upgrade to 1.1.5-0.20260401172448-237f3af891a9 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/patrickhener/goshs < 1.1.5-0.20260401172448-237f3af891a9
Fixed in
1.1.5-0.20260401172448-237f3af891a9· Vendor fix available
Issue
POST multipart upload directory not sanitized | httpserver/updown.go:71-174 This finding affect the default configuration, no flags or authentication required. Details File: httpserver/updown.go:71-174 Trigger: POST /<path/upload (server.go:49-51 checks HasSuffix(r.URL.Path, "/upload")) The filename is sanitized (slashes stripped, line 105-106), but the target directory comes from req.URL.Path unsanitized: The route requires the URL to end with /upload. An attacker uses a path like /../../targetdir/upload, the suffix satisfies routing, and the ../.. escapes the webroot. The filename on disk is controlled by the attacker via the multipart filename field (after basename extraction). Impact: Unauthenticated arbitrary file write to any existing directory on the filesystem. PoCs: To execute it: ./arbitraryoverwrite2.sh 10.1.2.2 8000 ./canary /tmp/can --- Recommendations Checking that the targeted file is part of the webroot could prevent these attacks. Also, ensure that the method…
Recommended action: Upgrade to 1.1.5-0.20260401172448-237f3af891a9 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/patrickhener/goshs < 1.1.5-0.20260401172448-237f3af891a9
Fixed in
1.1.5-0.20260401172448-237f3af891a9· Vendor fix available
Issue
PUT upload has no path sanitization | httpserver/updown.go:20-69 This finding affects the default configuration, no flags or authentication required. Details File: httpserver/updown.go:20-69 Trigger: PUT /<path (server.go:57-59 routes directly to put()) The handler uses req.URL.Path raw to build the save path. No filepath.Clean, no .. check, no webroot containment. UploadFolder defaults to Webroot (main.go:386-388). The path is pure string concatenation with no validation. Impact: Unauthenticated arbitrary file write anywhere on the filesystem. PoCs: To execute it: ./arbitraryoverwrite2.sh 10.1.2.2 8000 ./canary /tmp/can Recommendations Checking that the targeted file is part of the webroot could prevent these attacks. Also, ensure that the method return is called after every error response.
Recommended action: Upgrade to 1.1.5-0.20260401172448-237f3af891a9 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/patrickhener/goshs >= 0.3.4, <= 1.0.4
Fixed in
1.0.5· Vendor fix available
Issue
It seems that when running goshs without arguments it is possible for anyone to execute commands on the server. This was tested on version 1.0.4 of goshs. The command function was introduced in version 0.3.4. Details It seems that the function does not checks the option cli , thus allowing anyone to execute arbitrary command through the use of websockets. PoC Used websocat for the POC: Impact The vulnerability will only impacts goshs server on vulnerable versions.
Recommended action: Upgrade to 1.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.