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.14 and 7.0.38, the Update, Delete, and Reorder operations resolve records from the unscoped model query instead of the query configured through addClause() or addBaseClause(). An authenticated user who knows or guesses an out-of-scope record primary key can therefore modify, delete, or reorder records hidden by tenant, ownership, or other row-level access-control scopes. Applications that do not rely on CRUD query clauses for authorization are not affected by this specific bypass. The fix routes all three write operations through getModelWithCrudPanelQuery(), matching the scoped list and read behavior. This issue is fixed in versions 6.8.14 and 7.0.38.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.6",
  "pubDate": "2026-09-14T18:17:53.070Z",
  "pubdate": "2026-09-14T18:17:53.070Z",
  "executiveSummary": "The backpack/crud package is vulnerable to an authorization bypass flaw involving the improper scoping of Eloquent model queries during write operations. The vulnerability affects the Update, Delete, and Reorder functions, where the system fails to respect query constraints defined via addClause() or addBaseClause().\nThis issue allows an authenticated attacker to perform unauthorized data modifications, deletions, or reordering operations on records that should otherwise be inaccessible due to row-level security, tenant isolation, or ownership-based access control. The vulnerability is present in versions 6.0.0 through 6.8.14 and 7.0.38. Applications that implement granular data-access restrictions using CRUD query clauses are at significant risk, as the underlying query builder bypasses these scopes, effectively treating hidden records as if they were globally accessible. Successful exploitation requires an authenticated attacker to possess knowledge of a target record's primary key. The flaw represents a failure in the application's authorization boundary within the CRUD administrative interface.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the write operations—Update, Delete, and Reorder—within the backpack/crud package. Specifically, these operations utilized an unscoped model query when resolving the target record, rather than honoring the query constraints configured through the CRUD panel's clauses. In Laravel, while the list and read operations correctly utilized the filtered query result, the write operations failed to verify that the target record belonged to the restricted dataset defined by addClause() or addBaseClause().\nUnder normal circumstances, developers use addClause() to inject global or tenant-specific constraints (e.g., 'WHERE tenant_id = ?') into the CRUD panel's query builder. Because the vulnerable operations failed to call the same resolution logic used for read operations, the query builder was initialized as a fresh model instance (e.g., Model::find($id)), ignoring any applied global or local scopes during the write operation. This effectively renders the intended row-level access control useless for any write-based request.\nThe attack flow proceeds as follows: 1) An authenticated user logs into the administrative panel. 2) The attacker identifies or guesses the primary key of a record that is explicitly excluded from their viewable dashboard due to application-level scoping (such as a record belonging to another tenant). 3) The attacker submits a crafted HTTP request targeting the Update, Delete, or Reorder endpoint for the specific primary key. 4) The backend, failing to apply the CRUD panel's intended scoping, resolves the record from the database directly, bypassing the security context. 5) The backend proceeds to execute the requested write operation (e.g., deleting a record owned by another user).\nThis vulnerability highlights a critical breakdown in consistent authorization state management across CRUD lifecycle methods. The fix involves standardizing the record resolution process by routing all write operations through the getModelWithCrudPanelQuery() function, which ensures that all query constraints—including those meant to enforce multi-tenancy and data isolation—are strictly applied before any database mutation occurs. This alignment ensures that the write operations share the same integrity boundaries as the read operations, successfully preventing unauthorized interaction with off-limit records."
}