CVE-2026-58271
ŚrednieCVSS 6.8Streszczenie
W Sync-in Server przed wersją 2.4.0 mechanizm blokady konta po nieudanych próbach TOTP nie działa, ponieważ licznik passwordAttempts nie jest zwiększany. Atakujący może zgadywać kody TOTP bez ograniczeń, a po trafieniu uzyskać token klienta wymienialny na pełny JWT, a także trwale wyłączyć MFA.
Ocena ryzyka
Utrata skutecznej ochrony MFA umożliwia atakującemu przejęcie konta i trwałe osłabienie bezpieczeństwa uwierzytelniania w organizacji.
Rekomendacja
Zaktualizuj Sync-in Server do wersji 2.4.0 lub nowszej, a do czasu aktualizacji monitoruj nietypowe próby rejestracji klientów synchronizacji i wyłączanie MFA.
Inne podatności w Sync-in Server
Zobacz wszystkie- CVE-2026-58272Średnie
Sync-in Server przed wersją 2.4.1 ma zauważalną różnicę czasową w punkcie końcowym logowania, ponieważ próby uwierzytelnienia dla nieistniejących kont zwracają odpowiedź bez wykonywania porównania bcrypt, które jest używane dla istniejących kont. Nieuwierzytelniony atakujący może mierzyć czasy odpowiedzi, aby enumerować prawidłowe nazwy użytkowników lub adresy e-mail, co ułatwia ataki typu credential-stuffing, password-spraying i phishing. Wersja 2.4.1 zawiera poprawkę.
- CVE-2026-58270Średnie
Sync-in Server przed wersją 2.4.0 ma podatność w punkcie końcowym sync diff, gdzie kompiluje on ciąg znaków dostarczony przez użytkownika do wyrażenia regularnego bez walidacji złożoności. Wzorzec powodujący katastrofalne cofanie (np. ^(a+)+b) blokuje pętlę zdarzeń Node.js, czyniąc cały serwer nieodpowiedzialnym dla wszystkich użytkowników do czasu restartu kontenera. Wersja 2.4.0 naprawia ten problem.
- CVE-2026-58269Wysokie
Sync-in Server to platforma open source do przechowywania, udostępniania, współpracy i synchronizacji plików. W wersjach przed 2.4.0 punkt końcowy POST /api/auth/token uwierzytelnia wyłącznie nazwą użytkownika i hasłem, a następnie wywołuje getTokens(), które zwraca pełne tokeny dostępu i odświeżania JWT bez sprawdzenia, czy konto ma włączone 2FA TOTP. Atakujący z ukradzionymi lub wyłudzonymi poświadczeniami może obejść 2FA w jednym żądaniu. Równoległy punkt końcowy logowania (POST /api/auth/login) poprawnie wymusza 2FA, wywołując setCookies(user, res, true), co jest uzależnione od user.twoFaEnabled. Wersja 2.4.0 naprawia ten problem.
- CVE-2026-47684Wysokie
Sync-in Server to bezpieczna, otwartoźródłowa platforma do przechowywania plików, udostępniania, współpracy i synchronizacji. W wersjach przed 2.3.0, regex używany w funkcji pobierania URL do blokowania prywatnych adresów IP nie pasuje do adresów IPv4-mapped IPv6, co pozwala na obejście ochrony SSRF w systemach dual-stack.
Oryginalny opis (angielski, źródło NVD)
Sync-in Server is an open-source platform for file storage, sharing, collaboration, and syncing. Prior to version 2.4.0, `POST /api/app/sync/register` accepts credentials and a TOTP code to register a desktop sync client. On a failed TOTP, `SyncClientsManager.register()` calls `updateAccesses(user, ip, false)`, which hits a freeze branch that writes `passwordAttempts` back unchanged. The counter never reaches `USER_MAX_PASSWORD_ATTEMPTS` (10) and the lockout gate never fires. A successful guess returns a `{clientId, clientToken}` pair. The token can be exchanged via `POST /api/app/sync/auth/cookie` for a full JWT. While the code is valid, the attacker can also call `POST /api/auth/2fa/disable` to permanently remove MFA. Version 2.4.0 patches the issue.