Wprowadzenie do problemu / definicja luki
Pwn2Own Automotive to konkurs „ofensywnej weryfikacji bezpieczeństwa”, w którym zespoły badawcze demonstrują działające łańcuchy exploitów przeciw realnym komponentom ekosystemu automotive: systemom IVI (in-vehicle infotainment), systemom operacyjnym oraz infrastrukturze ładowania EV. najważniejszy element to 0-day – podatność nieznana publicznie i niewydana jeszcze w formie łatki w momencie demonstracji (część prób może też obejmować tzw. n-day, czyli znane już błędy). Wszystkie błędy trafiają do dostawców w trybie skoordynowanego ujawnienia przez ZDI.
W edycji 2026 stawka była wyjątkowo praktyczna: obok klasycznych celów automotive, mocno wybrzmiał temat EVSE (ładowarki) jako „kolejnego komputera w sieci” – z protokołami, zdalnym zarządzaniem, aktualizacjami i realnym wpływem na zachowanie procesu ładowania.
W skrócie
- Przez 3 dni przyznano 1 047 000 USD za 76 unikatowych 0-day.
- Master of Pwn zdobyło Fuzzware.io (Tobias Scharnowski, Felix Buchmann, Kristian Covic): 28 punktów i 215 500 USD.
- Po dniu 1: 516 500 USD i 37 unikatowych 0-day.
- Po dniu 2: +439 250 USD i 29 unikatowych 0-day (łącznie 955 750 USD i 66).
- Dzień 3 domknął konkurs do 76 – co oznacza +10 unikatowych 0-day względem stanu po dniu 2 (wyliczenie na podstawie oficjalnych sum).
Kontekst / historia / powiązania
Pwn2Own w wydaniu automotive to odpowiedź na transformację branży w stronę software-defined vehicle: więcej kodu, więcej integracji, więcej powierzchni ataku. ZDI podkreśla, iż o zwycięstwie w Master of Pwn decydują punkty za udane demonstracje (nie tylko wysokość nagród), a kolejność prób jest losowana — więc można wygrać „konsekwencją” i szerokim pokryciem celów.
W 2026 po raz kolejny mocno wybrzmiał motyw „zderzeń” (collisions): jeżeli ktoś demonstruje podatność już wykorzystaną wcześniej w konkursie, nagroda i/lub punkty są istotnie mniejsze, ale sama demonstracja przez cały czas ma wartość (potwierdza problem i presję na dostawcę).
Analiza techniczna / szczegóły luki
Z perspektywy inżynierii bezpieczeństwa najciekawsze jest nie „kto wygrał”, tylko jakie klasy błędów powtarzają się w automotive/EVSE.
1) IVI: klasyka podatności pamięci i błędy logiki
W samym dniu 3 pojawiają się m.in.:
- Stack-based buffer overflow (np. przeciw Alpine iLX-F511)
- Heap-based buffer overflow prowadzący do arbitralnego wykonania kodu (Sony XAV-9500ES)
- Race condition i błędne uprawnienia jako elementy łańcucha (Kenwood)
To wzorzec typowy dla urządzeń wbudowanych: „pamięć + uprawnienia + wyścigi/symlinki” = łatwa eskalacja w środowiskach, gdzie procesy często działają z podwyższonymi uprawnieniami lub mają szeroki dostęp do zasobów.
2) EVSE: łańcuchy podatności, manipulacja sygnałem i TOCTOU
W dzień 1 i 2 widać wyraźnie, iż ładowarki to nie tylko „RCE na urządzeniu”, ale również elementy pozwalające wpływać na logikę ładowania:
- Fuzzware.io łączyło podatności, by uzyskać wykonanie kodu i manipulować sygnałem ładowania (w kontekście dodatków/bonusów konkursowych).
- W dzień 3 Juurin Oy wykorzystało błąd TOCTOU w Alpitronic HYC50 (w relacji ZDI wprost nazwany TOCTOU) – pokazując, iż błędy wyścigu/czasu wciąż są krytyczne w systemach przemysłowo-motoryzacyjnych.
3) „N-day”, twardo zakodowane dane i komendy
W relacjach ZDI przewijają się również błędy „mniej sexy, bardziej realne”:
- Hardcoded credential (CWE-798), command injection, bypass uwierzytelnienia — typowo wynikające z pośpiechu integracyjnego i „serwisowych” interfejsów pozostawionych w produkcji.
Praktyczne konsekwencje / ryzyko
- Ryzyko łańcuchowe w łańcuchu dostaw: IVI i EVSE to układanka wielu dostawców (SoC, middleware, web UI, biblioteki). Jedna klasa błędu (np. overflow) może występować w wielu wariantach produktu.
- EVSE jako cel infrastrukturalny: kompromitacja ładowarki to potencjalnie:
- punkt wejścia do sieci operatora (zdalne zarządzanie, serwis),
- manipulacja procesem ładowania (integralność i bezpieczeństwo operacyjne),
- ryzyko masowe (flota urządzeń o wspólnym firmware).
- Presja czasowa na poprawki: ZDI raportuje błędy do dostawców, a publiczne ujawnienie jest opóźnione, by dać czas na patching. Dla obrońców oznacza to okno, w którym „wiemy, iż coś jest”, ale nie zawsze mamy jeszcze CVE i patch.
Rekomendacje operacyjne / co zrobić teraz
Dla producentów OEM / dostawców IVI i ECU
- Wzmocnij pipeline pod kątem klas błędów dominujących w konkursie: fuzzing interfejsów parsujących dane, sanitizery, testy regresji pod overflow / OOB / race / symlink.
- Przejrzyj „serwisowe” ścieżki: komendy, debug, endpoints, domyślne hasła — bo w relacjach wprost pojawiają się command injection i hardcoded credential.
- Zaplanuj aktualizacje „na twardo”: podpisywanie aktualizacji, weryfikacja integralności, ograniczenie uprawnień procesów i segmentacja komponentów (żeby pojedynczy błąd nie dawał od razu roota).
Dla operatorów EVSE / zespołów infrastruktury
- Traktuj ładowarki jak OT/IoT: segmentacja sieci, egress control, monitoring anomalii i twarde polityki zdalnego zarządzania.
- Wymuś higienę tożsamości: rotacja sekretów, brak domyślnych kont, ograniczenie dostępu serwisowego.
Dla SOC/CSIRT
- Ustaw czujność na publikacje ZDI po okresie embargo (gdy ruszą advisories/patch notes) i przygotuj playbook „szybkiego triage” dla IVI/EVSE w organizacji.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
W porównaniu do „klasycznych” edycji Pwn2Own (przeglądarki, OS-y), automotive wnosi dwie praktyczne różnice:
- Dodatki/bonusy (np. związane z osiągnięciem określonego efektu jak manipulacja sygnałem, utrzymanie persystencji itp.) zmieniają optymalizację ataków: liczy się nie tylko RCE, ale też impact.
- Collisions są szczególnie pouczające dla obrońców: skoro różne zespoły wpadają na te same miejsca, prawdopodobnie mamy do czynienia z „gorącymi punktami” architektury (wspólne biblioteki, te same warstwy integracji).
Podsumowanie / najważniejsze wnioski
- Pwn2Own Automotive 2026 pokazało skalę problemu: 76 unikatowych 0-day i ponad 1,0 mln USD w nagrodach w trzy dni.
- Fuzzware.io dowiozło zwycięstwo dzięki szerokiemu pokryciu celów i punktów: 28 pkt oraz 215 500 USD.
- Najważniejszy sygnał dla rynku: EVSE stało się pełnoprawną powierzchnią ataku, a klasyczne błędy (overflow, command injection, race/TOCTOU, złe uprawnienia) przez cały czas występują w krytycznych komponentach.
Na poziomie strategii bezpieczeństwa to argument za tym, by łączyć secure-by-design (architektura, uprawnienia, aktualizacje) z secure-by-testing (fuzzing, sanitizery, testy łańcuchów). Konkursy takie jak Pwn2Own brutalnie weryfikują, co „przechodzi” w realnym sprzęcie — zanim trafi to w ręce przestępców.
Źródła / bibliografia
- ZDI: Pwn2Own Automotive 2026 – Day Three Results and the Master of Pwn (zerodayinitiative.com)
- ZDI: Pwn2Own Automotive 2026 – Day Two Results (Zero Day Initiative)
- ZDI: Pwn2Own Automotive 2026 – Day One Results (zerodayinitiative.com)
- ZDI: Pwn2Own Automotive 2026 Rules (zerodayinitiative.com)
- Help Net Security: Tesla, Sony, and Alpine systems compromised on day one… (Help Net Security)