Fleet CVE-2026-111923: pre-auth DoS w Apple MDM. Poprawka z lipca, advisory z października, CVE dwa tygodnie później i build, który nadal jest podatny

Fleet to open source’owa platforma do zarządzania urządzeniami (osquery plus MDM). Jeśli ma włączone Apple MDM, przyjmuje od urządzeń plik binary plist jeszcze przed ich uwierzytelnieniem. Parser rozwiązywał odwołania w tym pliku rekurencyjnie i bez limitu, więc plik rzędu 150 bajtów potrafił wyczerpać CPU i pamięć serwera. Sama podatność to „tylko” DoS. Ciekawsza dla VM jest jej oś czasu. Poprawka weszła w 4.89.0 15 lipca i nie ma jej w release notes. Advisory GitHub pojawiło się 2 października bez numeru CVE. CVE-2026-111923 nadał VulnCheck 17 października. A 4 października Fleet wydał build 4.88.2, który według zakresu z advisory nadal jest podatny.

Co jest zepsute i czego advisory nie twierdzi

Według advisory endpointy rejestracji Apple MDM w Fleet parsują dane o urządzeniu, które przysyła klient, zanim urządzenie zostanie uwierzytelnione. Parser binary plist rozwiązywał odwołania między obiektami rekurencyjnie, bez limitu głębokości i bez wykrywania cykli. Mały, spreparowany plik mógł wywołać wykładniczą alokację albo nieskończoną rekurencję. Skutek: wyczerpanie CPU i pamięci i awaria całego serwera Fleet.

Advisory jest tu wyjątkowo precyzyjne w tym, czego nie ma: „availability only”, bez ujawnienia danych, obejścia uwierzytelniania, eskalacji uprawnień i wpływu na integralność. Wektor CNA mówi to samo (VA:H, reszta N). Nie dopisuj do tego findingu RCE ani „potencjalnego przejęcia MDM”. Źródła tego nie mówią.

Warunek, którego CVSS nie widzi: Apple MDM musi być włączone. Wektor ma AT:N, więc kalkulator traktuje każdą instalację tak samo. Instancja Fleet używana tylko do osquery albo tylko do Windows i Linux nie ma tej ścieżki. To klasyczny warunek wdrożeniowy: w rejestrze findingów zapisz go jako kontekst środowiskowy, a nie obniżaj base score.

Jedna poprawka, trzy daty

Dane z GitHub API, release notes i rekordu CVE układają się tak:

Wnioski dla VM:

1. Poprawka istniała 11 tygodni przed advisory i 13 tygodni przed CVE. Kto aktualizował Fleet regularnie, był chroniony od lipca, nawet o tym nie wiedząc. Kto trzymał wersję „bo działa”, nie miał żadnego sygnału. Release notes 4.89.0 w sekcji dla security engineerów wymieniają aktualizację golang.org/x/image, ale nie tę zmianę.
2. GHSA bez CVE to ślepa plamka dla procesów opartych tylko na NVD. Od 2 do 17 października podatność była publiczna, z opisem mechanizmu i nazwami endpointów, ale nie istniała w NVD. Ten sam wzorzec opisywałem przy h3 i Flatpak. Stan na 22.10.2026: advisory w GitHub nadal ma puste pole CVE, a rekord CVE odsyła do GHSA. Powiązanie istnieje tylko w jedną stronę.
3. CVE nie jest nową podatnością. Jeśli Twoje narzędzie otworzyło 2 października finding z GHSA, a 17 października drugi z CVE, to jeden problem z dwoma identyfikatorami. Scal je i zachowaj obie daty: publikacji advisory i nadania CVE. Dla metryk MTTR liczy się data pierwszej publicznej informacji, nie data CVE.
4. CNA to VulnCheck, nie GitHub. Severity w GHSA to „high” bez liczby. Wynik 8.7 / 7.5 pochodzi od VulnCheck. To nie jest błąd, ale warto wiedzieć, czyj wektor wpisujesz do rejestru. Podobny rozjazd źródeł opisywałem przy Craft CMS.

Świeży build, stary zakres: Fleet 4.88.2

4 października, dwa dni po advisory, Fleet wydał serię poprawek dla kilku gałęzi: 4.88.2, 4.89.3, 4.90.3, 4.91.2 i 4.92.3. Release notes każdej z nich mają ten sam jeden punkt: „Improved SSO session handling”. Zakres w GHSA i w rekordzie CVE jest prosty: wszystko poniżej 4.89.0 jest podatne. 4.88.2 jest więc według źródeł podatny, mimo że jest nowszy niż advisory.

Czy 4.88.2 zawiera po cichu backport ochrony plist, nie sprawdziłem i nie wiem. Ani advisory, ani release notes tego nie mówią. Praktyczny wniosek: polityka „najnowszy patch w mojej gałęzi” nie wystarczy, jeśli siedzisz na 4.88.x. Cel ticketu to ≥ 4.89.0, a realnie najnowsza wersja (4.93.1 z 20.10.2026), bo w październiku Fleet wydał też inne poprawki.

Obejście, które koliduje z modelem Apple MDM

Advisory proponuje jedno obejście: ograniczyć dostęp sieciowy do /api/mdm/apple/enroll i /api/mdm/apple/account_driven_enroll do zaufanych sieci. Dodaje też ważne zdanie: limity rozmiaru żądań nie pomagają, bo złośliwy payload jest mały. To obala odruchową odpowiedź „mamy limit body na reverse proxy”.

Problem praktyczny: Apple MDM z założenia działa przez internet. Laptopy i telefony rejestrują się i meldują z domu, z hotelu, z sieci komórkowej. Ograniczenie endpointów rejestracji do sieci firmowej zatrzyma atak, ale też rejestrację nowych urządzeń poza biurem, w tym scenariusze account-driven enrollment dla BYOD. Dla wielu organizacji to obejście tylko na czas krótkiego okna, a nie stała kontrola. Druga uwaga: opis poprawki mówi o ograniczeniu parsowania w żądaniach „enrollment and check-in”, a obejście wymienia tylko dwa endpointy rejestracji. Czy endpoint check-in jest osiągalny przed uwierzytelnieniem urządzenia, advisory nie mówi. To niepotwierdzone, więc nie traktuj obejścia jako pełnego pokrycia.

Ile kosztuje „tylko DoS” w MDM

SSVC od CISA-ADP ocenia Technical Impact jako partial, ale Automatable jako yes. Jedno żądanie bez uwierzytelnienia, mały payload, powtarzalny efekt. Serwer można podnieść restartem, ale atakujący może wysłać to samo żądanie po restarcie. Advisory mówi o DoS „for the whole instance”, czyli razem z zarządzaniem osquery, politykami, raportowaniem podatności i kolejką poleceń MDM. Jeśli Fleet jest u Ciebie narzędziem do wypychania pilnych poprawek albo do zdalnego blokowania zgubionych urządzeń, jego niedostępność w trakcie incydentu ma wyższy koszt, niż mówi partial. Ten rachunek opisywałem przy Zephyr, gdzie „Moderate DoS” wymagał rebootu.

Zależność: micromdm/plist

Od 4.92.0 ochrona siedzi w bibliotece github.com/micromdm/plist. Commit z 16.08.2026 dodaje wykrywanie cykli (maksymalna głębokość 128) i limit liczby materializowanych obiektów. Ta biblioteka jest używana w ekosystemie Go poza Fleet. Czy inne projekty, które parsują nią niezaufany plist w starszej wersji, mają ten sam problem, nie sprawdziłem. Dla tej biblioteki nie znalazłem osobnego CVE ani GHSA. Jeśli w SBOM masz micromdm/plist < 0.3.0 w usłudze, która parsuje plist z sieci, warto to sprawdzić osobno. Bez identyfikatora skaner tego nie zgłosi.

Co powinien zrobić VE

1. Inwentarz z kontekstem: wszystkie instancje Fleet, wersja serwera i to, czy Apple MDM jest włączone. Bez Apple MDM finding dostaje status „not affected” z uzasadnieniem konfiguracyjnym, a nie ręczne zamknięcie.
2. Dopasowanie: NVD nie ma CPE. Rekord CVE ma purl pkg:golang/github.com/fleetdm/fleet, a GHSA działa w ekosystemie Go. Wersję serwera bierz z fleet version, tagu obrazu albo API, nie z CMDB.
3. Scal identyfikatory: GHSA-x467-vgxf-2g6h i CVE-2026-111923 to jeden finding. Data otwarcia to 02.10.2026, jeśli Twój proces konsumuje GHSA.
4. Cel ticketu: ≥ 4.89.0, realnie najnowsza wersja. Nie zamykaj na 4.88.2, choć jest z października.
5. Obejście tylko na okno: ograniczenie dwóch endpointów rejestracji do zaufanych sieci, jeśli model rejestracji na to pozwala. Limit rozmiaru żądań nie jest kontrolą kompensującą.
6. Detekcja: nagłe skoki CPU i pamięci, restarty procesu Fleet i błędy parsera korelowane z żądaniami na endpointy rejestracji. To wskaźniki do obserwacji, a nie IoC znanej kampanii.
7. Monitoruj: KEV, EPSS i ewentualną aktualizację GHSA o numer CVE albo backporty dla starszych gałęzi.

Powiązane na blogu

• h3: GHSA w marcu, CVE we wrześniu — opóźnienie CVE-only Vulnerability Management
• Flatpak CVE-2026-90616 — miesiąc GHSA bez CVE
• Zephyr: DoS aż do rebootu — kiedy „Moderate DoS” jest krytyczny operacyjnie
• Nodemailer CVE-2026-100702 — inna rekurencja, ten sam typ wyczerpania zasobów
• Craft CMS i VulnCheck — czyje CVSS jest Twoje

Źródła

• Fleet — GitHub Security Advisory GHSA-x467-vgxf-2g6h (opis, zakres < 4.89.0, poprawki 4.89.0 i 4.92.0, obejście, brak CVE) — github.com
• CVE.org — CVE-2026-111923 (CNA VulnCheck, CVSS 4.0 8.7, CVSS 3.1 7.5, CWE-674, SSVC CISA-ADP) — cve.org
• NVD — CVE-2026-111923 (status Deferred, bez CPE) — nvd.nist.gov
• VulnCheck — advisory dla CVE-2026-111923 — vulncheck.com
• Fleet — release notes 4.89.0 (15.07.2026) — github.com
• Fleet — release notes 4.92.0 (21.09.2026) — github.com
• Fleet — release notes 4.88.2 (04.10.2026, „Improved SSO session handling”) — github.com
• micromdm/plist — commit „Fix unbounded parsing issues (#58)” (16.08.2026) — github.com
• CISA Known Exploited Vulnerabilities Catalog (brak CVE-2026-111923 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:00 CEST): advisory GHSA-x467-vgxf-2g6h przez GitHub API (data publikacji, severity, brak CVSS i CVE, zakres, obejście), release notes Fleet 4.88.2, 4.89.0, 4.89.3, 4.92.0, 4.92.3, 4.93.0 i 4.93.1, commit micromdm/plist z 16.08.2026, rekord CVE-2026-111923 w API CVE.org (CNA, wektory CVSS, CWE, purl, SSVC CISA-ADP), NVD API 2.0 (status Deferred, bez CPE), katalog CISA KEV w wersji 2026.10.16 i API EPSS. 22 października 2026 ponownie sprawdziłem katalog CISA KEV (wersja 2026.10.21: nadal brak wpisu) oraz rekord CVE i advisory GHSA (bez zmian, GHSA nadal bez numeru CVE). Względem szkicu dodałem datę cichej poprawki (15.07), brak CVE w samym GHSA, CNA VulnCheck, wektory CVSS i problem buildu 4.88.2. Nie potwierdziłem: czy 4.88.2 lub inne buildy poniżej 4.89.0 zawierają backport, czy endpoint check-in jest osiągalny przed uwierzytelnieniem, czy inne projekty używające micromdm/plist w starszej wersji są podatne, jaki jest stan Fleet w modelu zarządzanym przez producenta, ani czy istnieje publiczny PoC lub wykorzystanie. Ocena kolizji obejścia z modelem Apple MDM i kosztu DoS to opinia autora.