Description

backpack/crud provides Create, Read, Update & Delete (CRUD) functions for Backpack, a collection of Laravel packages that help users build custom administration panels. From 6.0.0 until 6.8.15 and 7.0.47, HasMany and MorphMany handling through attachManyRelation during CRUD create and update operations accepts submitted child primary keys without consistently restricting updates to records belonging to the current parent or permitted by the developer-defined relation scope. An authenticated low-privilege administrator who can edit a parent form exposing an affected multiple-relation field can cause unrelated child records to be reassigned, detached, nulled, or deleted across ownership or tenant boundaries. Exploitation requires related records that should not be attachable or removable by that administrator and the absence of additional application-level authorization around submitted relation values. This issue is distinct from earlier direct main-entity CRUD scoping fixes because it affects secondary models modified by relationship-saving logic. This issue is fixed in versions 6.8.15 and 7.0.47.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-14T18:17:57.180Z",
  "pubdate": "2026-09-14T18:17:57.180Z",
  "executiveSummary": "The vulnerability involves an improper authorization check during the processing of 'HasMany' and 'MorphMany' relationships within the backpack/crud package for Laravel.\nThe issue manifests during CRUD 'create' and 'update' operations, where the `attachManyRelation` logic fails to enforce ownership or tenant boundary restrictions on associated child records.\nAn authenticated low-privilege administrator capable of accessing a form containing these multi-relation fields can manipulate foreign key assignments or detachment states for records they are not authorized to manage.\nThis represents a significant security risk, potentially leading to unauthorized data manipulation, cross-tenant record leakage, or the disruption of data integrity across unrelated business entities.\nExploitation requires the attacker to have valid administrative credentials and access to a specific CRUD form containing the vulnerable relationship field, as well as the presence of child records that lack secondary application-level authorization checks.\nThe vulnerability affects backpack/crud versions from 6.0.0 up to 6.8.14 and 7.0.46, with patches released in versions 6.8.15 and 7.0.47.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient validation performed by the `attachManyRelation` function within the backpack/crud package. When processing form submissions involving 'HasMany' or 'MorphMany' relationships, the package incorrectly trusts primary keys provided in the request payload.\nStandard Laravel CRUD operations within Backpack should enforce scope constraints defined by the developer to ensure that child entities being linked, updated, or detached belong strictly to the parent record currently being managed. In the affected versions, the framework fails to intersect the requested child IDs with the query scope constrained by the parent model's relationship.\nExploitation occurs when an authenticated administrative user intercepts or crafts a request containing IDs of child records that do not belong to the target parent entity, or that belong to a different tenant context. Because the underlying 'attachManyRelation' logic does not consistently verify that these IDs fall within the permitted scope, the database abstraction layer executes updates or deletion commands on these out-of-bounds records.\nThe attack flow proceeds as follows: 1) The attacker navigates to an administrative CRUD form that utilizes 'attachManyRelation' for child record management. 2) The attacker identifies legitimate IDs of child records belonging to other parents or tenants through enumeration or discovery. 3) The attacker modifies the HTTP request (e.g., via a proxy tool) to include these unauthorized IDs in the relationship field input. 4) The application processes the request, and the vulnerability allows the backend logic to modify the relationship mapping in the database, effectively reassigning, detaching, or nulling foreign keys of the targeted records.\nThis impact extends beyond simple data corruption; if an attacker can manipulate ownership, they can effectively bypass business logic, escalate privileges through data manipulation, or cause a denial of service by detaching essential system entities from their intended parents.\nThe vulnerability is specific to the handling of secondary models. Unlike primary entity CRUD scoping, which was addressed in previous security releases, this logic resides within the secondary relationship-saving layer, necessitating specific patches to ensure that all relationship modifications are subjected to proper ownership and authorization filters before execution."
}