Only an org's owner, its CONFIGURE_SYSTEM members or active god mode can change its settings

FixSecurityService
Shipped
September 17, 2026 at 3:38 AM UTC
Author
Kamo
Commit
d3890ff

PUT /api/security/org/{id} took no request at all. ResourceServerConfig permits every request and APIService relays /api/security/**, so one anonymous request could rename ANY organization, change its alias (its theme folder and ?org= reference), contact address (the default From of company-wide campaigns), website, privacy and terms links and login-page brand text, its compliance and privacy flags, its NMLS id and LEI, and replace its domain rows with verification flags of the caller's choosing. Confirmed live on 2026-09-17 without writing anything: an anonymous PUT whose backgroundOrder the handler rejects came back with the handler's own 400, not a 401. Every caller was mapped first (kamo-internal at a5fc5fd3, and every other repository): LabelManager's six save sections and the setup wizard's step savers, all editing the org their own session is in, from screens gated on CONFIGURE_SYSTEM. Org creation never PUTs; no other client or service does. So the handler now: - answers 401 without a session carrying a userID, before it reads the org; - allows the org's owner (Organization.owner or the TeamMember owner) from any session, as the branding endpoints do; a session IN that org holding CONFIGURE_SYSTEM; the System User entered into that org; or active god mode (GD alone is not enough). Anyone else gets 403. Rights are per membership, so CONFIGURE_SYSTEM held in another org counts for nothing; - refuses domains, configType, colors, imageBgCount, licenseNumber and licenseNumberBinded outside god mode. No screen sends them (colors go through PATCH /colors), and domains/configType change how an org is reached and how its accounts recover. Those screens already redirect anyone without CONFIGURE_SYSTEM (checkRight passes only on that right in the session or active god mode), so no one who can save them today loses access. One caller changes visibly: the phone settings' mobile device policy PUTs mobileDevicePolicy, which the patch allow-list has never stored (a silent 200 no-op); a member with only MANAGE_VOIP_SETTINGS now gets a 403 there. **************** pins each case. The updateOrganization line leaves **************** The ratchet's other failure **************** and **************** four errors are on origin/main already.

All changes

Like what you see shipping?

All of it arrives in your workspace on its own. Start on the free plan and read this page again in a month.

Start Free ForeverView Pricing