[security] Mass assignment fix sweep
fix: [security] Mass assignment fix sweep
[security] Mass assignment fix sweep05aad4-fix-security-mass-assignment-fix-sweep-cve-2026-56422fixsecurity mass assignment fix sweep
Committed by iglocska
commit message
fix: [security] Mass assignment fix sweep
ShadowAttributesController: two scope-FK mass-assignment issues on the proposal
create paths (id-hijack itself was already closed; edit() was hardened earlier in
9341690e9). Both let a body-supplied foreign key diverge from the route the ACL
validated.
- add(): the action only ever proposes NEW attributes (edit-proposals go through
edit()), yet old_id and uuid were caller-controlled. A REST caller could submit
old_id!=0 plus an arbitrary uuid; on acceptance ShadowAttribute::acceptProposal()
takes the old_id!=0 branch, finds the live attribute by that uuid and overwrites
(or, with proposal_to_delete, deletes) it — retargeting an accepted proposal onto
an attribute it was never meant to touch. Pin old_id to 0 so every add() proposal
is unambiguously a new-attribute proposal.
- add_attachment(): event_id was read from the request body (Attribute[event_id])
for both the malware-sample and plain-attachment proposals, while the ACL
validated the route event and event_uuid/event_org_id were taken from it. A caller
could land a proposal on an event they were never authorised against. Pin event_id
to the route-validated event (matching add(), which already does this).
Live-verified before/after on the dev instance: pre-fix an injected old_id=99999
was stored verbatim and an add_attachment posted to route event X with body
event_id=Y landed on Y; post-fix old_id is forced to 0 and the attachment lands on X.
Milestone ShadowAttributesController of the mass-assignment audit.
- 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 body identifies two scope-FK issues in ShadowAttributesController, add() letting a caller-supplied old_id and uuid retarget an accepted proposal, and add_attachment() trusting a body event_id over the route-validated event. Those explanations are precise, and pinning old_id to zero and using the route event are clearly motivated. The problem is presentation: roughly two thousand characters of dense audit prose, internal tags such as the milestone label, and a reported-by line buried at the end. Valuable forensics, poor example writing, and the blanket subject hides which controller changed.