CVE-2026-70610

Podatność w Electron przed wersjami 39.8.8, 40.9.0, 41.2.1 i 42.0.0-beta.3 polega na tym, że API kart i skryptów rozszerzeń nie były ograniczone do sesji samego rozszerzenia. Złośliwe lub skompromitowane rozszerzenie załadowane w jednej sesji mogło nawigować, skryptować i czytać z okien należących do innej sesji. Aplikacje są narażone tylko wtedy, gdy ładują rozszerzenia Chrome przez session.loadExtension i polegają na oddzielnych sesjach do izolacji.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.8, 40.9.0, 41.2.1 i 42.0.0-beta.3, żądania otwarcia zewnętrznych protokołów URL z treści web nie uwzględniały ograniczeń sandboxa iframe, więc sandboxowany iframe mógł uruchomić zewnętrzną aplikację zarejestrowaną w systemie operacyjnym. Stan sandboxa ramki nie był również udostępniany handlerom uprawnień aplikacji, co wpływa na aplikacje renderujące niezaufane treści w sandboxowanych iframe i przyznające domyślnie uprawnienie openExternal, gdy nie zainstalowano setPermissionRequestHandler.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.9, 40.9.2, 41.2.1 i 42.0.0-beta.3, akcja DevTools 'reveal in file manager' mogła uruchomić docelowy plik zamiast go pokazać. Atakujący z osobnym sposobem uruchamiania skryptów w frontendzie DevTools, takim jak złośliwe rozszerzenie DevTools, mógł użyć obsługi showItemInFolder do wykonania natywnego kodu poza sandboxem, gdy DevTools jest otwarty dla okien narażonych na niezaufane treści lub niezaufane rozszerzenia DevTools.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.7, 40.9.0, 41.2.0 i 42.0.0-beta.1, opcja mode w webContents.openDevTools() nie była sanityzowana przed użyciem przez frontend DevTools. Jeśli atakujący może wpłynąć na tę wartość, skrypt pod jego kontrolą może zostać uruchomiony w kontekście DevTools, który w konfiguracjach bez sandboxa ma dostęp do Node.js, w tym gdy niezaufane dane wejściowe trafiają do argumentu mode funkcji openDevTools() lub gdy niezaufana treść wywołuje openDevTools() na osadzonym webview.

Electron przed wersjami 39.8.10, 41.10.3 i 42.0.1 pozwalał sandboxowanemu iframe bez atrybutu allow-popups na otwieranie nowych okien lub wyzwalanie setWindowOpenHandler bez interakcji użytkownika. Dzieje się tak, ponieważ nawigacje nowego okna korzystające ze ścieżki OpenURL nie stosowały ograniczeń popup dla sandboxowanych iframe. Problem dotyczy aplikacji osadzających niezaufane treści w sandboxowanych iframe i polegających na braku allow-popups, a nie dotyczy aplikacji, które blokują tworzenie okien w setWindowOpenHandler lub nie osadzają niezaufanych treści.

Electron (przed wersjami 39.8.8, 40.9.0, 41.2.1 i 42.0.0-beta.3) stosuje niektóre opcje okna dostarczone przez treść internetową w ciągu window.open() do nowego BrowserWindow bez listy dozwolonych. Niezaufana treść może ustawić opcje okna, których nie powinna kontrolować, w tym opcje powodujące dostęp procesu głównego do wybranych przez atakującego ścieżek plików lub sieci, gdy niezaufana treść może wywołać window.open() i aplikacja nie nadpisuje opcji okna podrzędnego przez setWindowOpenHandler lub overrideBrowserWindowOptions.

Podatność w Electron przed wersjami 40.10.6, 41.9.1, 42.5.1 i 43.0.0 polega na tym, że gdy niestandardowy handler protokołu zwraca ProtocolResponse z polem url i bez session, żądanie jest wysyłane przez defaultSession zamiast sesji obsługującej protokół. Może to spowodować ponowne użycie odpowiedzi z pamięci podręcznej między izolowanymi partycjami sesji. Aplikacje używające ProtocolResponse.url, pomijające ProtocolResponse.session i polegające na oddzielnych sesjach są narażone.

Podatność w Electron przed wersjami 39.8.8, 40.9.0, 41.2.1 i 42.0.0-beta.3 polega na tym, że podczas podążania za przekierowaniami HTTP, net.fetch() i net.request() nie ograniczały schematów, do których może prowadzić przekierowanie. Zdalny serwer może przekierować żądanie do lokalnego zasobu, a jeśli aplikacja zwraca lub przekazuje treść odpowiedzi, może dojść do ujawnienia lokalnych plików. Aplikacje są narażone tylko wtedy, gdy wykonują żądania sieciowe do adresów URL kontrolowanych przez atakującego i ujawniają treść odpowiedzi.

Electron to framework do tworzenia aplikacji desktopowych. Przed wersjami 39.8.10, 40.9.3, 41.4.0 i 42.0.0 niestandardowy schemat zarejestrowany z supportFetchAPI: true, ale bez corsEnabled: true, nie był objęty egzekwowaniem CORS. Strona załadowana ze zdalnego pochodzenia mogła wykonać fetch() lub XMLHttpRequest do tego schematu w trybie cross-origin i odczytać pełną treść odpowiedzi. Aplikacje serwujące wrażliwe dane z takiego schematu i ładujące zdalne lub niezaufane treści w rendererze są dotknięte.

Podatność w Electron przed wersjami 39.8.6, 40.9.0, 41.1.1 i 42.0.0-beta.1 polega na tym, że shell.openPath() nie odrzucał ścieżek zawierających wbudowane bajty null. Aplikacje, które wykonują tylko walidację ciągów znaków ścieżek, np. sprawdzanie rozszerzenia, przed przekazaniem do shell.openPath(), mogą zostać ominięte, co pozwala na otwarcie innego pliku niż ten, który przeszedł walidację. Aplikacje są narażone tylko wtedy, gdy przekazują ścieżki pochodzące z niezaufanego wejścia i polegają na walidacji opartej na ciągach bez sprawdzenia systemu plików.