I traced src/runtime/server/controllers/command-export.controller.ts:242-244 and remote-command-execution.controller.ts:63-72 and found remote command execution gets delegated through a local engine event named opencore:command:execute:{resourceName} carrying a bare numeric clientID. Any other resource loaded on the same server can TriggerEvent that name directly with an arbitrary clientID and execute a command "as" any currently-connected player. The target handler's own @Guard/@RequiresState still re-checks permissions, so I don't think it's a full authz bypass — but CORE's own validateSecurity bookkeeping/audit trail gets bypassed, and impersonating the acting player in logs looks possible.
I'd suggest including a signed/opaque capability token in the event payload instead of a raw clientID, so only CORE itself can legitimately trigger command execution on behalf of a player.
I traced
src/runtime/server/controllers/command-export.controller.ts:242-244andremote-command-execution.controller.ts:63-72and found remote command execution gets delegated through a local engine event namedopencore:command:execute:{resourceName}carrying a bare numericclientID. Any other resource loaded on the same server canTriggerEventthat name directly with an arbitraryclientIDand execute a command "as" any currently-connected player. The target handler's own@Guard/@RequiresStatestill re-checks permissions, so I don't think it's a full authz bypass — but CORE's ownvalidateSecuritybookkeeping/audit trail gets bypassed, and impersonating the acting player in logs looks possible.I'd suggest including a signed/opaque capability token in the event payload instead of a raw
clientID, so only CORE itself can legitimately trigger command execution on behalf of a player.