10 września 2026 GitHub Advisory Database opublikował trzy świeże problemy rclone związane z auth-proxy: CVE-2026-88018 dla serve s3, CVE-2026-88044 dla RC oraz CVE-2026-88017 dla FTP. Dwa pierwsze Critical, trzeci High. Wspólna etykieta auth-proxy kusi, by myśleć o jednym defekcie — z perspektywy VE jest odwrotnie: to trzy niezależne ścieżki serwerowe i trzy różne sposoby utraty właściwości „każda operacja wykonywana wyłącznie po skutecznym uwierzytelnieniu i w kontekście właściwego użytkownika”.
serve s3 --auth-proxy bez --auth-key — pełne obejście SigV4 authentication.auth-proxy bypass. CVE-2026-88017 (High): FTP cross-session auth-proxy backend confusion.Feature flag ≠ security boundary
Najważniejsza lekcja: feature flag lub nazwa modułu nie jest dowodem istnienia jednolitej security boundary — trzeba zweryfikować enforcement per protocol. Organizacja może mieć rclone jako jeden produkt i jedną wersję; taki model jest za płaski. Realny affectedness zależy od tego, czy instancja uruchamia serve s3, RC, FTP, --auth-proxy, dodatkowe klucze/mechanizmy auth i wielosesyjny backend. Jeden host z podatną wersją może być exploitable, a drugi z tą samą wersją nie wystawiać żadnej podatnej ścieżki. Nie przenoś szczegółów jednego CVE na pozostałe — ani wspólnego preconditionu, ani wspólnej fixed version, jeśli advisory danego CVE tego nie potwierdza.
Trzy różne attack paths
S3: pytaniem nie jest „czy rclone ma S3 server?”, lecz czy działa serve s3 --auth-proxy i jak skonfigurowano klucze/authentication; jeśli enforcement SigV4 nie jest wykonywany w odpowiedniej ścieżce, attacker uzyskuje dostęp do funkcji uznawanych za chronione — to błąd security property, nie tylko „zła konfiguracja”. RC: osobna powierzchnia zarządzania; bypass nie jest zamykany dowodem „S3 auth działa po patchu”, a jeśli RC umożliwia operacje administracyjne, blast radius bywa większy. FTP: cross-session confusion — stan uwierzytelnienia lub wybór backendu nie był związany z konkretną sesją; test jednej poprawnej sesji nie wystarcza, trzeba sprawdzić izolację między jednoczesnymi klientami, zmianę kolejności zdarzeń i reuse zasobów backendowych.
Remediation, weryfikacja, błędy
Najpierw ustal protocol footprint każdej instancji, potem wdroż wersje naprawcze z advisory konkretnego CVE (nie scalaj lifecycle bez potwierdzenia maintainera). Jeśli patch czeka — redukuj reachability: wyłącz nieużywany serve s3/RC/FTP, ogranicz binding do zaufanych interfejsów, odetnij dostęp ACL/firewallem, nie opieraj bezpieczeństwa wyłącznie na auth-proxy. Verification per protocol: S3 — negatywne testy SigV4; RC — request bez auth odrzucony przed operacją zarządzającą; FTP — równoległe sesje nie dzielą identity/backend context; konfiguracja — aktywne flagi runtime, nie tylko plik; sieć — realny binding i ekspozycja portów. False positive: płaski scanner alarmuje host z podatnym package, który nie uruchamia żadnego affected server. Groźniejszy false negative: zespół zamyka „rclone auth-proxy” po przetestowaniu S3, gdy RC/FTP mają osobny podatny path. Brak potwierdzenia active exploitation w źródłach — nie podnoś do „exploited” tylko dlatego, że dwa są Critical.
Powiązane na blogu
- Traefik: jeden proxy, cztery granice — jeden release, wiele niezależnych properties
- MySQL MCP: transport zmienia attack surface — enforcement zależny od trybu
Źródła
- rclone security advisories — github.com
- rclone serve s3 documentation — github.com
Nota redakcyjna: stan informacji 11 września 2026. Trzy CVE rclone auth-proxy (88018 S3, 88044 RC, 88017 FTP) to trzy niezależne ścieżki; brak potwierdzenia active exploitation. Artykuł zaleca verification per protocol i model affectedness szerszy niż package/version.