DorianandClaude
f5f57e60d9
Found live while wiring the "existing bot" AI-config settings UI: this route parsed `pubkey` from the request body and used it directly to select which bot row to update, with no check that it matched the caller's actual authenticated identity. Any unauthenticated caller could POST an arbitrary victim's pubkey plus a malicious webhookUrl, profilePicUrl, or customization payload and silently hijack that bot (e.g. redirect its webhook to an attacker-controlled endpoint). Contrast with GET /me and POST /regenerate-secret, which both correctly derive pubkey from the verified JWT via extractPubkeyFromAuth and never trust a client-claimed identity — this was the one route that didn't follow that pattern. Fixed by deriving pubkey from the JWT exclusively; updateBotSchema no longer declares a pubkey field at all (was the only schema-level signal that the vulnerable code path existed). Frontend callers updated to stop sending a pubkey they no longer need. Added a regression suite (auth-update.test.ts) covering: 401 with no/garbage auth, hijack-attempt-via-body-pubkey now 404s and leaves the victim's row untouched, and legitimate self-updates still work when the body happens to carry an unrelated pubkey field (ignored, not trusted). Full server suite: 829/829 passing. tsc --noEmit clean (server + frontend). Co-Authored-By: Claude <noreply@anthropic.com>