[security] Mass assignment fix sweep
fix: [security] Mass assignment fix sweep
[security] Mass assignment fix sweep00b2e3-fix-security-mass-assignment-fix-sweep-cve-2026-56422fixsecurity mass assignment fix sweep
Committed by iglocska
commit message
fix: [security] Mass assignment fix sweep
ServersController: add() saved $this->request->data directly with no
fieldList and no id strip, so an injected Server[id] turned the create
into a covert UPDATE of an arbitrary server row (milestone Servers of the
mass-assignment audit).
- add() is REST-reachable (/servers/add.json); CSRF field-hashing does not
cover the REST path, so a site-admin key could repoint another server's
sync url/authkey/push-pull rules while it is logged as an "add".
- Strip the client-supplied id before save() (this action only ever
creates). edit() already pins id to the route + uses a fieldList that
excludes org_id; import()/createSync() build fresh whitelisted arrays
(no id); other writes act on DB-loaded records - all SAFE.
- Live-proven before/after: strip disabled -> POST id=2 overwrote server 2's
url/authkey; strip enabled -> new row created, server 2 untouched.
- as reported by Jeroen Pinoy
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>Editor assessment
This commit patches CVE-2026-56422. The generic audit title, Mass assignment fix sweep, does not identify ServersController, but the body immediately does and then carries the explanation: add() saved request data with no fieldList and no id strip, so Server[id] turned a create into a covert update of another server, and the REST path lacks CSRF field hashing. It also records the fix, stripping the client id before save, and audits the sibling actions as safe. The live before-and-after evidence is compelling. The flaws are the one-size-fits-all subject and internal shorthand such as milestone language, which assume an audit reader.