Mage OSS CVE-2026-111823: obejście OAuth z CVSS 9.8, poprawka w master, ale nie w wydaniu. A commit z rekordu CVE nie istnieje w Twoim buildzie

Mage OSS, narzędzie do budowania i uruchamiania pipeline’ów danych, do wersji 0.9.80 włącznie potrafi utworzyć sesję, gdy żądanie logowania wskazuje nieznanego dostawcę OAuth. Weryfikacja tokenu wtedy nie zachodzi, a tożsamość z żądania trafia do wyszukania lub założenia konta. CNA (MITRE) ocenia to na 9.8. Poprawka jest w master od 16 października 2026, ale nie ma wydania, które ją zawiera. Rekord CVE wskazuje commit z gałęzi pull requesta, który w master ma inny SHA. Bazy, z których korzystają skanery zależności, nie mają dla mage-ai żadnego wpisu. To podręcznikowy przypadek, w którym „patch available” nie daje nic, co da się wdrożyć.

Co jest zepsute i czego to dotyczy

Rekord CVE jest lakoniczny: Mage „can proceed with session creation upon encountering an unknown OAuth provider”. Więcej mówi opis PR #6204. Gdy żądanie wskazuje dostawcę, którego Mage nie zna, weryfikacja tokenu jest pomijana, a adres e-mail z żądania nadal trafia do wyszukania użytkownika lub założenia konta i do wydania sesji. Poprawka odrzuca nieobsługiwanych dostawców, niepełne lub błędne poświadczenia OAuth, błędy dostawcy i brak tożsamości od dostawcy, zanim dojdzie do wyszukania użytkownika. Przy udanym logowaniu OAuth liczy się wyłącznie tożsamość zwrócona przez dostawcę.

Według PR zgłoszenie z 12 czerwca 2026 opisywało też skutki po uzyskaniu sesji: wykonanie poleceń przez API kontroli wersji, eksplorator plików i wbudowany terminal. Dlatego to nie jest „tylko” logowanie. Kto ma sesję w Mage, ma zwykle dostęp do kodu pipeline’ów, poświadczeń źródeł danych i w wielu konfiguracjach do wykonania kodu na hoście. Ten sam wzorzec, w którym drugi punkt wejścia wydaje sesję bez polityki pierwszego, opisywałem przy Open WebUI.

Ważny kontekst wersji: według dokumentacji Mage w wersjach 0.8.4–0.9.77 uwierzytelnienie jest opcjonalne (REQUIRE_USER_AUTHENTICATION=1), a od 0.9.78 włączone domyślnie. Instancja starsza niż 0.9.78 bez tej zmiennej nie wymaga żadnego logowania, więc CVE-2026-111823 jest dla niej najmniejszym problemem. Taki finding to błędna konfiguracja, a nie ten CVE. Czy obejście działa także na instancji z włączonym uwierzytelnieniem, ale bez skonfigurowanego OAuth, ze źródeł nie potwierdziłem. Opis PR mówi o lokalnym serwerze „with authentication and permissions enabled”, bez szczegółów konfiguracji OAuth. Dopóki tego nie wiesz, traktuj każdą instancję z włączonym logowaniem jako podatną.

Linia poprawki: od zgłoszenia do braku wydania

Z tej osi czasu wynikają trzy problemy, których nie rozwiąże ticket „zaktualizuj do wersji naprawionej”.

1. Nie ma wersji naprawionej

Rekord mówi „through 0.9.80”, ale nie podaje wersji naprawionej, bo jej nie ma. Szkic VMRT Radar słusznie ostrzegał przed wymyślaniem „0.9.81”. Ticket z celem „> 0.9.80” nie ma dziś daty realizacji, a jedyna droga do kodu z poprawką to własny build z master. Dla większości organizacji to gorsze ryzyko operacyjne niż odczekanie na wydanie z ograniczeniem dostępu. Podobną sytuację opisywałem przy XZ Utils 5.8.4: fix istnieje w gałęzi, ale nie istnieje artefakt.

2. SHA z rekordu CVE nie jest w master

Rekord odwołuje się do 76c4f46. Patch tego commita ma datę 15.10.2026 i jest commitem na gałęzi PR. W master poprawka wylądowała 16.10.2026 jako jeden commit 4fc5e18 o innym SHA, co wskazuje na squash merge. Praktyczna konsekwencja: jeśli ktoś zbuduje Mage z master i sprawdzi, czy w historii buildu jest 76c4f46 (np. git merge-base --is-ancestor), dostanie wynik negatywny, mimo że poprawka jest w kodzie. Skrót „before 76c4f46” w rekordzie jest więc mało przydatny do weryfikacji. Do kryterium zamknięcia wpisz 4fc5e18 albo, lepiej, numer wydania, gdy się pojawi. Że 76c4f46 nie występuje w historii master, wnioskuję z różnych SHA i jednego rodzica commita w master. Bezpośrednio nie sprawdzałem tego klonem repozytorium.

3. Skanery zależności tego nie widzą

Na 20.10.2026 zapytanie do OSV o mage-ai 0.9.80 w ekosystemie PyPI zwraca pustą listę. W repozytorium Mage nie ma advisory GHSA dla tego CVE (jedyne to CVE-2023-31143 z 2023 roku). Rekord CVE nie ma pakietu PyPI ani CPE, tylko vendor: Mage, product: mage-ai i adres repozytorium. pip-audit, Dependabot i skanery obrazów oparte na tych źródłach nie podniosą alarmu. Finding musi powstać ręcznie albo z inwentarza aplikacji. Ten sam problem jakości danych dla młodych projektów opisywałem przy argocd-mcp.

Dodatek: latest to nie najnowsza wersja

Na Docker Hub tag 0.9.80 ma datę 09.10.2026, a tag latest ostatnią aktualizację z 21.01.2026, czyli z dnia wydania 0.9.79. Wnioskuję z tego, że mageai/mageai:latest wskazuje dziś 0.9.79, ale digestów nie porównywałem: niepotwierdzone. Jeśli ktoś wdraża Mage z latest, nie dostanie poprawki automatycznie także wtedy, gdy pojawi się wydanie. Inwentarz powinien więc zapisywać digest obrazu, nie tag.

Poprawka uwierzytelnienia to nie cała poprawka

Zgłoszenie dotyczyło jednego błędu, ale producent zamyka je kilkoma zmianami. #6205 utwardza wykonywanie poleceń Git w API kontroli wersji: zamiast składać polecenie powłoki, przekazuje argumenty bezpośrednio i ogranicza dozwolone opcje. #6206 przenosi uwierzytelnienie terminala WebSocket przed podłączenie PTY. Opis mówi, że wcześniej klient znający nazwę terminala mógł dostać jego bufor wyjścia bez poświadczeń. Ten PR był 22.10.2026 nadal otwarty. Tego samego dnia co #6204 do master trafiły też zmiany #6207 (kontrola ról w kontroli wersji) i #6133 (walidacja ścieżek plików). Czy są związane z tym samym zgłoszeniem, nie wiem.

Dla VM oznacza to tyle, że CVE-2026-111823 opisuje pierwsze ogniwo, a nie cały łańcuch. Wydanie, które zamknie finding, powinno zawierać co najmniej #6204, #6205 i #6206. Jeśli producent wyda wersję bez #6206, finding uwierzytelnienia możesz zamknąć, ale ryzyko terminala zostaje otwarte jako osobna pozycja, bez CVE. Tak samo patrzyłem na rodzinę poprawek w Langflow.

Co powinien zrobić VE

1. Znajdź instancje Mage w inwentarzu aplikacji, nie tylko w SCA: obrazy mageai/mageai, pakiety mage-ai w środowiskach Pythona, Helm charty. Zapisz wersję z działającego artefaktu i digest obrazu.
2. Rozdziel dwa przypadki. Instancja < 0.9.78 bez REQUIRE_USER_AUTHENTICATION=1 to finding konfiguracyjny „brak uwierzytelnienia”, pilniejszy niż to CVE. Instancja z logowaniem to finding CVE-2026-111823.
3. Do czasu wydania ogranicz osiągalność interfejsu i API (domyślnie port 6789) do sieci zaufanej lub za proxy z uwierzytelnieniem SSO. To kontrola kompensująca, nie remediacja. Zapisz ją jako wyjątek z datą przeglądu powiązaną z wydaniem.
4. Ustal kryterium zamknięcia: wydanie Mage zawierające #6204 i #6205 (oraz #6206, jeśli chcesz zamknąć także ryzyko terminala), potwierdzone w działającym artefakcie. Przy własnym buildzie z master weryfikuj obecność 4fc5e18, nie 76c4f46.
5. Przejrzyj logi i bazę użytkowników: konta utworzone bez udziału administratora, sesje z nietypowych adresów, zmiany w projektach, użycie API kontroli wersji i terminala. Przy podejrzeniu nadużycia rotuj poświadczenia źródeł danych i integracji zapisane w Mage.
6. Monitoruj wydania Mage, OSV i GHSA dla mage-ai, KEV i SSVC CISA (dziś exploitation: none). Zmiana na poc albo pojawienie się wpisu w KEV skraca każdy wyjątek.

Powiązane na blogu

• XZ Utils 5.8.4 — fix w gałęzi bez wydania: kiedy „upstream fixed” nie daje remediacji
• Open WebUI CVE-2026-88006 — drugi punkt wejścia wydaje sesję bez polityki
• Apache Airflow CVE-2026-59243 — poprawka OAuth, która nie zamknęła wszystkiego
• Langflow — rodzina poprawek to nie jeden finding
• argocd-mcp — rekord bez danych, których potrzebuje automat

Źródła

• CVE.org — CVE-2026-111823 (CNA MITRE, CVSS 3.1 9.8, CWE-390, zakres do 0.9.80, SSVC CISA ADP) — cve.org
• NVD — CVE-2026-111823 (status Deferred) — nvd.nist.gov
• Mage — PR #6204 „Reject unverified OAuth session identities” (zgłoszenie z 12.06.2026, scalony 16.10.2026) — github.com
• Mage — PR #6205 „Harden version control command execution” — github.com
• Mage — PR #6206 „Authenticate terminal clients before PTY attachment and output” (otwarty 20.10.2026) — github.com
• Mage — wydania (0.9.80 z 09.10.2026) — github.com
• PyPI — mage-ai (najnowsza 0.9.80) — pypi.org
• Docker Hub — mageai/mageai, tagi — hub.docker.com
• Mage — dokumentacja uwierzytelnienia (opcjonalne w 0.8.4–0.9.77, domyślne od 0.9.78) — docs.mage.ai
• OSV — baza podatności (zapytanie o mage-ai 0.9.80) — osv.dev
• CISA Known Exploited Vulnerabilities Catalog (brak CVE-2026-111823 w wersji 2026.10.21) — cisa.gov

Nota redakcyjna: wpis powstał na podstawie szkicu VMRT Radar z 19.10.2026 i został zweryfikowany ze źródłami pierwotnymi 20 października 2026 (ok. 19:10 CEST): rekord CVE.org (CNA MITRE, CVSS 3.1 9.8, zakres do 0.9.80, SSVC CISA ADP), NVD API 2.0 (status „Deferred”), API GitHub (PR #6204 i #6205 scalone 16.10.2026, PR #6206 otwarty, wydania, advisory repozytorium), patche commitów 76c4f46 i 4fc5e18, PyPI, tagi Docker Hub, OSV, EPSS, katalog CISA KEV 2026.10.16 i dokumentacja uwierzytelnienia Mage. Względem szkicu doprecyzowałem różnicę SHA (squash merge), status #6206, brak pokrycia w OSV/GHSA, datę tagu latest i zależność od domyślnego uwierzytelnienia od 0.9.78. Ponownie 22 października 2026 (ok. 22:40 CEST) sprawdziłem katalog CISA KEV (wersja 2026.10.21: nadal brak wpisu), EPSS (bez zmian) oraz wersje w PyPI, GitHub i WordPress.org (bez nowych wydań). Nie potwierdziłem: czy obejście wymaga skonfigurowanego OAuth, kiedy pojawi się wydanie z poprawką, na którą wersję wskazuje dziś latest (digest), czy #6207 i #6133 wynikają z tego samego zgłoszenia, ani czy błąd był wykorzystywany. Kryteria zamknięcia i podział findingów to oceny autora.