Renovate i złośliwy Link header: dependency bot może wynieść własne credentials (CVE-2026-88881)

Renovate automatyzuje aktualizacje zależności i działa z credentialami do systemów źródłowych. W advisory GHSA-w57v-h33h-835c maintainer opisuje problem w obsłudze paginacji GitHub API: Renovate ufa URL-owi z nagłówka HTTP Link i przy przejściu do next może wysłać credentials do hosta kontrolowanego przez atakującego. To nie klasyczny SSRF — kluczowym skutkiem jest przeniesienie sekretu przez granicę origin. Narzędzie do redukcji ryzyka samo staje się ścieżką exfiltracji.

CVE-2026-88881 (GHSA-w57v-h33h-835c): zaufanie do Link: <...>; rel="next" → credentials wysłane do attacker-controlled hosta. Precondition: złośliwy/skompromitowany serwer GitHub.

Fixed version — niespójna: tabela advisory 44.11.3, sekcja „Patches” 44.11.2, rekord CVE 44.11.3 — zachowaj provenance, weryfikuj konserwatywnie do 44.11.3.

Attack path

1. Renovate rozmawia z GitHub.com/GHEC/GHES lub github datasource 2. serwer zwraca paginacje: Link: <...>; rel="next" 3. atakujacy kontroluje/skompromitowal ten serwer 4. w next wskazuje inny, attacker-controlled host 5. Renovate podaza za URL i przekazuje credentials pierwotnego hosta 6. sekret trafia poza wlasciwa trust boundary

Precondition (złośliwy/skompromitowany serwer) mocno wpływa na exploitability, ale nie zmienia faktu, że narzędzie nie powinno rozszerzać zasięgu credentiali na dowolny host z metadanych odpowiedzi. Impact: wyciek credentiali może być bardzo poważny; exploitability wymaga kontroli nad serwerem/odpowiedzią, której Renovate ufa; asset context i blast radius zależą od scope tokenu (read-only do jednego repo vs szeroki token organizacyjny to ten sam CVE, nie ten sam risk).

Provenance: jaka właściwie jest fixed version?

W maintainer advisory jest wewnętrzna niespójność: tabele affected/patched pokazują <44.11.3 affected i 44.11.3 patched, a sekcja „Patches” mówi 44.11.2; zewnętrzny rekord CVE (10.09) wskazuje 44.11.3. VE nie „wybiera sobie” liczby — zapisuje evidence z provenance i rozbieżnością. Praktyczna decyzja: nie zamykać findingu na 44.11.2 tylko dlatego, że jedno zdanie tak mówi, gdy tabela tego samego advisory i nowszy CVE wskazują 44.11.3; bezpieczne minimum do weryfikacji to 44.11.3, chyba że maintainer skoryguje advisory. Uwaga na workaround: opcja RENOVATE_X_REBASE_PAGINATION_LINKS akceptuje środowiska, gdzie pagination host różni się od początkowego — używać tylko gdy taki model jest celowy; version fixed nie musi znaczyć control effective, jeśli świadomie wyłączono nowy host check.

Co powinien zrobić VE

Zinwentaryzuj instalacje Renovate (kontenery, npm, Mend CE/EE, Helm), ustal używane hosty GitHub/GHES i datasource'y, zmapuj credentials i scope, sprawdź konfigurację rebasing pagination links, zaktualizuj do wersji potwierdzonej najbardziej konserwatywną interpretacją evidence, po aktualizacji zweryfikuj że cross-origin next nie otrzymuje credentials. Jeśli GHES mógł być skompromitowany — rotate credentials niezależnie od patcha. Compromise remediation przy realnym skompromitowaniu hosta: unieważnij i wymień tokeny, przejrzyj scope i użycie, przeanalizuj outbound do nietypowych hostów, zbadaj sam GHES, sprawdź czy wykradzione credentials nie zmodyfikowały repozytoriów lub release artifacts.

Powiązane na blogu

Gemini: wyciek tokenu service account — sekret poza trust boundary
OmniRoute: sprzeczne źródła fixed version — provenance zamiast jednej liczby

Źródła

Maintainer advisory GHSA-w57v-h33h-835c — github.com
NVD — CVE-2026-88881 — nvd.nist.gov

Nota redakcyjna: stan informacji 11 września 2026. CVE-2026-88881 (Renovate): zaufanie do Link header przy paginacji może wynieść credentials przez granicę origin; precondition to złośliwy/skompromitowany serwer GitHub. Primary advisory ma niespójną fixed version (44.11.2 vs 44.11.3) — artykuł zaleca weryfikację konserwatywnie do 44.11.3. Brak potwierdzenia active exploitation.