CVE-2026-85287

HomeBox to system inwentaryzacji i organizacji domu. Przed wersją 0.27.0 narzędzie maybeUrl() akceptuje linki w stylu markdown w wartościach pól niestandardowych encji bez ograniczania schematu URL, więc uwierzytelniony użytkownik może zapisać URI javascript:, który jest renderowany jako klikalny link na stronie przedmiotu. Gdy inny uwierzytelniony użytkownik kliknie link, JavaScript kontrolowany przez atakującego wykonuje się w origin HomeBox ofiary, umożliwiając kradzież sesji, przejęcie konta lub eksfiltrację danych.

W HomeBox przed wersją 0.27.0 endpoint POST /api/v1/users/login weryfikuje hash hasła tylko wtedy, gdy podana nazwa użytkownika odpowiada istniejącemu kontu, natomiast dla nieznanych nazw zwraca wynik natychmiast. Mimo że obie ścieżki zwracają tę samą odpowiedź 401, różnica czasu przetwarzania pozwala nieuwierzytelnionemu zdalnemu atakującemu rozróżnić zarejestrowane adresy e-mail; ograniczanie szybkości jedynie zmniejsza liczbę prób w danym oknie czasowym. Problem naprawiono w wersji 0.27.0.

HomeBox przed wersją 0.27.0 waliduje adresy URL powiadomień za pomocą ValidateNotifierURL, ale shoutrrr wysyła żądania przez http.DefaultClient.Do bez polityki CheckRedirect ponownie walidującej każdy cel przekierowania. Uwierzytelniony członek kolekcji może skonfigurować dozwolony host powiadomień przekierowujący do pętli zwrotnej, adresów link-local, metadanych chmury lub innego zablokowanego celu.

W HomeBox domyślnie włączone zabezpieczenia SSRF BlockBogonNets i BlockCloudMetadata w notifier_url.go nie sprawdzają adresów IPv4 osadzonych w prefiksach NAT64 64:ff9b::/96 i 64:ff9b:1::/48. Uwierzytelniony użytkownik może przesłać notifier generic:// przez POST /v1/notifiers lub POST /v1/notifiers/test, a w instancji z wyjściem NAT64/DNS64 brama może przetłumaczyć zaakceptowany adres IPv6 na metadane chmurowe, localhost lub inny wewnętrzny host IPv4. Ścieżka testowa zwraca informacje o wyniku dostarczenia, co może ujawnić pobrane metadane, takie jak tymczasowe poświadczenia. Problem naprawiono w wersji 0.26.0.

HomeBox, system inwentaryzacji i organizacji domu, w wersjach przed 0.26.0 posiada podatność w NotifierRepository.Update w backend/internal/data/repo/repo_notifier.go. Funkcja aktualizuje notifier przez UpdateOneID(id) bez wymagania zgodności identyfikatora użytkownika rekordu z uwierzytelnionym użytkownikiem. Uwierzytelniony użytkownik, który poda UUID notifiera innego najemcy do PUT /v1/notifiers/{id}, może odczytać zwrócony zapisany URL, który może zawierać poświadczenia Shoutrrr w postaci jawnej dla Slack, SMTP, Telegram, Pushover lub Discord, oraz może zastąpić URL, aby przekierować powiadomienia ofiary do webhooka kontrolowanego przez atakującego.

HomeBox, system inwentaryzacji i organizacji domu, w wersjach przed 0.26.0 posiada podatność w MaintenanceEntryRepository.Update i MaintenanceEntryRepository.Delete w backend/internal/data/repo/repo_maintenance_entry.go. Funkcje używają UpdateOneID(id) i DeleteOneID(id) bez weryfikacji, czy wpis konserwacji należy do aktywnej grupy uwierzytelnionego użytkownika. Uwierzytelniony użytkownik o niskich uprawnieniach, który zna lub wyliczy UUID wpisu konserwacji innego najemcy, może nadpisać ten rekord lub trwale go usunąć.

W HomeBox endpoint POST /v1/groups/members wywołuje HandleGroupMemberAdd i GroupService.AddMember z użyciem dostarczonego przez wywołującego userID bez wymagania roli właściciela, tokenu zaproszenia, zgody użytkownika docelowego ani powiadomienia. Każdy uwierzytelniony użytkownik może zmusić inne konto do dołączenia do swojej grupy, ujawnić adres e-mail i nazwę użytkownika docelowego przez listę członków oraz utworzyć warunek członkostwa wykorzystywany przez osobną podatność czyszczenia zapasów między grupami. Problem naprawiono w wersji 0.26.0.

HomeBox, system inwentaryzacji i organizacji domu, w wersjach przed 0.26.0 posiada podatność w HandleWipeInventory w backend/app/api/handlers/v1/v1_ctrl_actions.go. Funkcja autoryzuje POST /v1/actions/wipe-inventory na podstawie globalnej wartości ctx.User.IsOwner zamiast roli wywołującego w aktywnej grupie, podczas gdy aktywna grupa jest wybierana przez nagłówek X-Tenant. Ponieważ każdy samodzielnie zarejestrowany użytkownik, który tworzy grupę, otrzymuje globalną wartość właściciela, użytkownik będący również członkiem innej grupy może wybrać tę grupę przez X-Tenant i trwale usunąć cały jej inwentarz, co jest nieodwracalne bez zewnętrznych kopii zapasowych.