CVE-2026-70611

Aplikacje Electron na macOS korzystające z automatycznych aktualizacji opartych na Squirrel.Mac są podatne na lokalny wyścig w uprzywilejowanym pomocniku ShipIt w wersjach przed 39.8.10, 41.10.5 i 42.0.0-beta.2. Pomocnik nie wiązał zweryfikowanego celu aktualizacji z jedną kanoniczną ścieżką pakietu aplikacji, co pozwala lokalnemu atakującemu przekierować zapis z uprawnieniami roota i nadpisać pliki innej aplikacji.

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.

Elektron przed wersjami 41.10.4, 42.5.2 i 43.0.0 nie przekazywał odziedziczonych ograniczeń sandboxa HTML do popupów otwieranych z sandboxowanego iframe przez ścieżkę OpenURLFromTab, w tym linki z target="_blank" lub środkowym kliknięciem. Niezaufany iframe z konfiguracją allow-scripts allow-popups mógł otworzyć popup z pełnym originem aplikacji, ujawniając ciasteczka, storage i możliwości skryptowania samego originu.

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.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.