CVE-2026-90614 to nietypowy i użyteczny case, bo jego największą wartością nie jest sam temat deserializacji, lecz jakość i provenance danych. Rekord opisuje FedML do 0.9.6 i funkcję S3Storage.read_model w backendzie MQTT+S3: manipulacja s3_key_str prowadzi do deserializacji nieufnych danych, możliwej zdalnie. Jedną z referencji jest GitHub issue #2267 — który świadomie nie zawiera żadnych technicznych szczegółów: autor pisze wprost, że nie chce publikować findingu, bo repozytorium nie ma private vulnerability reporting ani SECURITY.md, i prosi jedynie o uruchomienie prywatnego kanału disclosure.
S3Storage.read_model, klasa deserialization, opis zdalnej możliwości.Dlaczego to problem dla VM
Pipeline robi CVE feed → parser → affected version → asset match → ticket. Precyzyjnie brzmiący opis podnosi zaufanie do danych — ale machine-readable szczegół nie znaczy, że publiczny primary evidence pozwala go zweryfikować. Tu system może mieć wysoki confidence co do istnienia CVE, niższy co do dokładnego attack path, niejasny status maintainer confirmation, brak publicznego fixed release, brak patch commit, brak publicznego PoC. To nie powód, by CVE odrzucić — powód, by nie traktować wszystkich pól jako equally verified. Zamiast verified=true/false przechowuj osobno: identifier assigned (tak), CNA description (tak), vendor/maintainer advisory (nie znaleziono), primary technical disclosure (publicznie brak), patch commit (niepotwierdzony), fixed version (niepotwierdzona), public reproduction (niepotwierdzona), active exploitation (brak dowodu).
Priorytetyzacja warunkowa i hipoteza attack path
Można priorytetyzować: jeśli używasz FedML ≤ 0.9.6 z backendem MQTT+S3, samo pojawienie się CVE o deserializacji w ścieżce ładowania modeli uruchamia analizę. Ale warunkowo: affected version + użycie MQTT+S3 + kto kontroluje broker + kto kontroluje bucket/obiekty + czy artefakty są podpisane/weryfikowane + uprawnienia procesu FedML. Hipoteza z opisu: attacker wpływa na referencję/obiekt z S3 → aplikacja pobiera dane → niebezpieczna deserializacja → impact w procesie — ale to model z opisu rekordu, nie z maintainer advisory; oznacz jako hipotezę do potwierdzenia. To różnica między evidence-driven VE a kopiowaniem tekstu z feedu.
Remediation, verification, disclosure jako supply-chain
Nie wymyślaj fixed version. Tymczasowo: ogranicz/wyłącz podatny backend jeśli zbędny, ogranicz dostęp do MQTT brokerów, wymuś kontrolę bucket ownership i write permissions, nie ufaj obiektom modelowym od niezaufanych producentów, izoluj workload, minimalizuj IAM, ogranicz egress, monitoruj anomalie przy pobieraniu modeli. Do closure nie wystarcza „scanner nie pokazuje CVE” ani „zaktualizowaliśmy do nowszego commita” — potrzebny mocny dowód: vendor/maintainer release z fixem, patch commit z review, regression test, własny test że nieufny artefakt nie może zostać niebezpiecznie zdeserializowany. Issue #2267 pokazuje też, że brak prywatnego kanału zgłoszeń obniża jakość downstream vulnerability data — security process maintainera to element provenance software supply chain.
Powiązane na blogu
- HexStrike AI: provenance i confidence — nie wymyślaj fixed version
- OmniRoute: sprzeczne źródła — traktuj feed jak materiał dowodowy
Źródła
- Repository issue #2267 — github.com
- NVD — CVE-2026-90614 — nvd.nist.gov
Nota redakcyjna: stan informacji 14 września 2026. CVE-2026-90614 (FedML ≤0.9.6): rekord opisuje remote deserialization, ale wskazane źródło pierwotne świadomie nie zawiera szczegółów. Brak publicznego fixed release, PoC ani potwierdzenia active exploitation. Artykuł traktuje attack path jako hipotezę do potwierdzenia i podkreśla model provenance.