CVE-2026-102673

Electron to framework do tworzenia aplikacji desktopowych. W wersjach od 42.3.3 do 42.10.0, 43.5.0 i 44.0.0-beta.6, sandboxowany preload code cache nie weryfikował, czy wpis w cache odpowiada preloadowi, dla którego był serwowany. Złamany renderer mógł zapisać dane cache kontrolowane przez atakującego i spowodować, że Electron użyje ich przy późniejszym ładowaniu, wykonując kod renderera w bardziej uprzywilejowanym kontekście preload. Problem dotyczy aplikacji ładujących niezaufane treści. Poprawiono w wersjach 42.10.0, 43.5.0 i 44.0.0-beta.6.

Elektron to framework do tworzenia aplikacji desktopowych. Przed wersjami 41.10.6, 42.9.2, 43.4.1 i 44.0.0-beta.5, gość <webview> mógł włączyć nodeIntegrationInWorker dla swoich Web Workerów, nawet gdy osadzający (embedder) miał wyłączoną integrację Node.js i nie był w piaskownicy. Pozwalało to niezaufanej treści na utworzenie workera z uprawnieniami Node.js, przekraczającymi przyznane przez osadzającego.

Elektron przed wersjami 41.10.6, 42.9.2, 43.4.1 i 44.0.0-beta.5 miał problem z odpowiedziami serwowanymi przez protocol.registerFileProtocol lub protocol.registerHttpProtocol dla niestandardowego schematu z włączonym supportFetchAPI, ale wyłączonym corsEnabled. Odpowiedzi te mogły pozostać czytelne dla skryptów z innych źródeł (cross-origin). Jest to dopełnienie poprawki dla CVE-2026-70604.

Elektron przed wersjami 41.10.6, 42.9.2, 43.4.1 i 44.0.0-beta.5 nie dziedziczył aktywnych ograniczeń sandboxa HTML dla okien otwieranych z sandboxowanego dokumentu najwyższego poziomu. Niezaufana treść w takim dokumencie, która mogła otwierać popupy, mogła utworzyć okno z pełnym originem aplikacji Electron, zamiast ograniczonego originu przewidzianego przez sandbox.

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.9, 40.9.2, 41.2.2 i 42.0.0-beta.4, obiekty kopiowane przez granicę contextBridge z niezaufanych treści mogły przenosić prototyp wpływający na atakującego, umożliwiając ataki typu prototype pollution na kod preload, mimo włączonej izolacji kontekstu. Aplikacje są dotknięte tylko wtedy, gdy ich kod preload akceptuje argumenty obiektowe z niezaufanych treści i czyta z nich właściwości bez sprawdzania własności; aplikacje akceptujące tylko argumenty prymitywne lub walidujące argumenty obiektowe nie są dotknięte.

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.