CVE-2026-114121

Electron to framework do tworzenia wieloplatformowych aplikacji desktopowych przy użyciu JavaScript, HTML i CSS. W wersjach przed 42.11.16, 43.8.1, 44.9.1 i 45.0.0-beta.6 Electron nie blokuje skompromitowanych certyfikatów pośrednich eMudhra w sieci Chromium, Node.js tls, Node.js https ani Node.js fetch. Atakujący posiadający certyfikat wystawiony przez taki certyfikat pośredni i mogący przechwycić ruch sieciowy może podszyć się pod serwer TLS dla podatnej 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 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.

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.