CVE-2026-115570

W Electronie przed wersjami 42.11.6, 43.7.3, 44.4.3 i 45.0.0-alpha.9 dane ramek otrzymywane z procesu GPU przy renderowaniu offscreen na macOS nie były w pełni walidowane przez proces główny. Atakujący z kodem wykonawczym w procesie GPU mógł dostarczyć niespójną geometrię ramki i spowodować odczyt poza granicami pamięci w procesie głównym, ujawniając pamięć lub powodując awarię aplikacji.

W Electronie przed wersjami 42.11.6, 43.7.3, 44.4.3 i 45.0.0-alpha.9 dane ramek otrzymywane z procesu GPU dla webContents.beginFrameSubscription nie były w pełni walidowane przez proces główny. Atakujący z kodem wykonawczym w procesie GPU mógł dostarczyć niespójną geometrię ramki i spowodować odczyt poza granicami pamięci w procesie głównym, ujawniając pamięć lub powodując awarię aplikacji.

W Electronie przed wersjami 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.5 żądania otwarcia zewnętrznych adresów URL protokołów mogły być przypisane do innego dokumentu niż ten, który je zainicjował. Powodowało to, że parametr requestingUrl przekazywany do session.setPermissionRequestHandler wskazywał zaufaną treść dla żądania pochodzącego z niezaufanej treści.

Electron to framework do tworzenia aplikacji desktopowych. W wersjach przed 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.5 sprawdzanie uprawnień hid i usb wykonywane z iframe powodowało, że setPermissionCheckHandler otrzymywał origin i szczegóły ramki najwyższego poziomu zamiast ramki żądającej. Aplikacja, która delegowała hid lub usb do niezaufanego iframe cross-origin i zezwalała na dostęp do urządzeń na podstawie logiki origin, mogła przyznać tej osadzonej ramce dostęp przeznaczony dla strony najwyższego poziomu.

W frameworku Electron żądania uprawnień pointerLock z niektórych iframe'ów cross-origin powodowały, że session.setPermissionRequestHandler() otrzymywał requestingUrl i isMainFrame ramki najwyższego poziomu zamiast wartości ramki żądającej. Aplikacja osadzająca niezaufaną zawartość iframe i przyznająca pointer lock na podstawie pochodzenia żądania mogła przyznać uprawnienie w imieniu strony najwyższego poziomu. Problem naprawiono w wersjach 42.11.9, 43.7.6, 44.5.0 i 45.0.0-alpha.13.

W frameworku Electron funkcja chrome.tabs.query() zwracała adres URL i tytuł każdej karty rozszerzeniom, które nie miały uprawnienia tabs ani pasujących uprawnień hosta. Aplikacja ładująca niezaufane rozszerzenie przez session.extensions.loadExtension mogła pozwolić mu odczytać URL i tytuł każdego webContents w swojej sesji. Problem naprawiono w wersjach 42.11.1, 43.5.1, 44.1.1 i 45.0.0-alpha.4.

W Electronie przed wersjami 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.6 strony otwierane w nowym oknie z linków były traktowane jako nawigacje zainicjowane przez aplikację, zamiast zachowania strony zawierającej link jako inicjatora. Powodowało to, że żądanie najwyższego poziomu mogło zostać zaklasyfikowane jako same-site, wysyłając ciasteczka SameSite=Strict i nie ujawniając inicjatora w Sec-Fetch-Site.

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.