Security: Privileged IPC handlers lack sender/origin validation

[tomaioo]

Summary

Security: Privileged IPC handlers lack sender/origin validation

Problem

Severity: High | File: src/main/core/ipc/IPCManager.ts:L15

The IPC manager registers handlers/listeners without validating the sender frame origin, URL, or trust level. Any renderer that can access IPC may invoke sensitive main-process operations (database writes, filesystem actions, updater actions, plugin lifecycle), creating a high-impact privilege-escalation path if renderer content is compromised.

Solution

Implement centralized sender validation (e.g., allowlist trusted origins/windows/webContents IDs) before dispatching handlers. Add per-channel authorization checks and minimize exposed channels. Consider context isolation + strict preload API surface with explicit permission checks.

Changes

• src/main/core/ipc/IPCManager.ts (modified)

[fishyy119]

The security concern is valid in principle, but this implementation is not. It introduces calls to this.isTrustedSender(...) without defining isTrustedSender, so the main-process typecheck fails immediately. This strongly suggests the change was pushed without even running the local build or a basic npm run typecheck:node.

Even if the missing method were added, the approach is still incomplete: passing only event.sender validates a whole WebContents, not the actual senderFrame, origin, URL, or frame trust boundary described in the PR. That means this does not satisfy the stated security goal and would still fail to distinguish trusted top-level app code from unexpected frames or compromised renderer content. It also does not implement any per-channel authorization, despite the PR claiming that as part of the solution.

There is also at least one direct ipcMain.handle(...) registration (stop-game-*) that bypasses this centralized wrapper entirely, so the proposed “centralized sender validation” is not actually centralized.

In short: the problem statement is reasonable, but the patch is a hallucinated and non-building partial implementation. Please do not submit security fixes that have not been compiled, run, or checked against the actual Electron IPC threat model.

Review drafted by GPT-5.4, since apparently we are reviewing bot-generated code with another model. Unfortunately, the model that produced this PR does not appear to have been particularly smart: it invented a missing method, missed existing raw IPC handlers, and seemingly did not have a working local development environment.