Electron 44.4.0: custom protocol validation and V8 code cache fixes

What happened on this date

At 2026-09-15T17:06Z (UTC), the electron/electron repository published v44.4.0, alongside 43.7.1 and 42.11.4 the same day. The 44.4.0 notes include: scheme names passed to protocol.registerSchemesAsPrivileged() are now validated against URI scheme grammar and invalid names are rejected; V8 code caching was fixed for https scripts loaded from file:// and custom-scheme pages; a browser-side check blocking drag and drop between cross-site frames of the same page had been disabled and is now fixed; on macOS, helper executables launched without a process type could start a second app instance, and child_process.fork() now throws in that configuration; memory leaks and a use-after-free in app.getPreferredSystemLanguages() on Windows were fixed; and Node.js was updated to v24.21.0, with backported upstream fixes from Chromium, V8 and others. The notes have no separate security section.

Why it matters for protecting app logic

An Electron app ships its business logic as JavaScript inside the package, and many protection approaches load resources through custom protocols, use V8 code caches or snapshots, or rely on the process model and fuse configuration. This patch release touches several of those points: custom scheme names are now strictly validated, V8 code caching behavior was corrected, and fork behavior on macOS changed. These are correctness or security fixes, but for loaders that depend on these mechanisms, a patch release can still change behavior. The cross-site drag-and-drop fix is a reminder that boundaries between renderers depend on the framework's own implementation, so timely upgrades are part of the defense.

Checks you can run

First, check that every privileged scheme name your app registers conforms to URI scheme grammar, and confirm resource loading still works after upgrading. Second, if your protection or startup optimization relies on V8 code caches, snapshots or bytecode, re-test on both Windows and macOS after upgrading. Third, search your code for child_process.fork() usage and confirm it still behaves as intended in packaged macOS builds. Fourth, after upgrading, re-confirm fuse configuration and asar integrity settings, then re-sign and notarize. Fifth, stay on a supported Electron major line and follow its patch releases promptly.

Your checklist

• Validate privileged scheme names and re-test resource loading
• Re-test protection relying on V8 code caches or snapshots on both platforms
• Re-check fuses and asar integrity after upgrading, then re-sign and notarize