CVE-2026-34581

W serwerze plików goshs przed wersją 2.1.4, obsługa metody WebDAV MOVE nie wymuszała opcji --no-delete, co pozwalało klientom WebDAV na usuwanie lub nadpisywanie plików za pomocą MOVE z nagłówkiem Overwrite: T.

W goshs od wersji 2.1.3 do 2.1.4, obsługa hasła SFTP sprawdzała tylko czy nazwa użytkownika i hasło nie są puste, co przy uruchomieniu z -b 'admin:' -sftp i bez -fkf pozostawiało oba mechanizmy uwierzytelniania SFTP nieustawione, umożliwiając nieuwierzytelniony dostęp do plików.

goshs to prosty serwer HTTP napisany w Go, który przed wersją 2.0.0-beta.6 miał podatność ArtiPACKED. Ta podatność może prowadzić do wycieku GITHUB_TOKEN przez artefakty workflow, mimo że token nie jest obecny w kodzie źródłowym repozytorium.

W goshs przed wersją 2.0.0-beta.3 funkcja tdeleteFile() nie sprawdza poprawnie ścieżki po wykryciu path traversal, co może umożliwić atakującemu dostęp do plików poza dozwolonym katalogiem.

W goshs przed wersją 2.0.0-beta.3 katalog docelowy dla przesyłanych plików metodą POST multipart nie jest odpowiednio sanityzowany, co może umożliwić atakującemu zapis plików w dowolnej lokalizacji.

W goshs przed wersją 2.0.0-beta.3 funkcja PUT upload w httpserver/updown.go nie sanityzuje ścieżki, co może umożliwić atakującemu zapis plików poza dozwolonym katalogiem.

W goshs, prostym serwerze HTTP napisanym w Go, przed wersją 2.1.0 funkcja ShareHandler odczytuje limit pobrań tokenu pod blokadą RLock, zwalnia blokadę, serwuje plik, a następnie ponownie ją przejmuje, aby zwiększyć licznik. Współbieżne żądania odczytują ten sam stan i wszystkie przechodzą kontrolę, co pozwala przekroczyć zamierzony limit. Wersja 2.1.0 naprawia ten problem.

goshs, prosty serwer HTTP napisany w Go, nie egzekwuje flag ograniczających tryb (--read-only, --upload-only, --no-delete) na porcie WebDAV, gdy włączono WebDAV (-w). Uwierzytelniony klient WebDAV może wykonywać operacje PUT, DELETE, MKCOL, MOVE i COPY, mimo że operator tego nie chce. Problem naprawiono w wersji 2.1.0.

W serwerze plików goshs przed wersją 2.1.5, w handlerze sendFile pliku httpserver/handler.go, otwieranie plików odbywało się po oczyszczeniu ścieżki, ale nazwa pliku do autoryzacji pochodziła z surowego req.URL.Path. Końcowy ukośnik mógł ominąć ochronę plików ACL .goshs i sprawdzanie listy blokad. Problem rozwiązano w wersji 2.1.5.

W serwerze plików goshs przed wersją 2.1.5, handler przesyłania wieloczęściowego w httpserver/updown.go dzielił part.FileName() na /, ale nie odrzucał sekwencji .., co pozwalało nieuwierzytelnionemu atakującemu na przesłanie pliku o nazwie zawierającej .. i utworzenie pliku poza drzewem serwowanych plików. Problem rozwiązano w wersji 2.1.5.