CVE-2026-54180 in CRUD
Summary
by MITRE • 09/14/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The backpack/crud package serves as a foundational component for Laravel-based administration panels, providing essential Create, Read, Update, and Delete functionalities to streamline the development of custom backend interfaces. Within this ecosystem, developers frequently implement row-level access control mechanisms using database scopes defined via methods such as addClause or addBaseClause. These scopes are critical for enforcing tenant isolation, ownership restrictions, and other multi-tenant security models that ensure users can only interact with data explicitly assigned to their context. The integrity of these authorization boundaries relies heavily on the consistency between how records are fetched for display and how they are modified in subsequent operations.
A significant architectural flaw was identified in versions 6.0.0 through 6.8.14 and 7.0.38, where a discrepancy existed between read and write operation implementations regarding query scoping. While the list view correctly utilized scoped queries to filter visible records based on user context, the Update, Delete, and Reorder operations bypassed these constraints by resolving targets from an unscoped model query. This inconsistency meant that the application logic did not apply the same filtering rules during state-changing actions as it did during data retrieval. Consequently, the security boundary enforced at the presentation layer was effectively nullified for write operations because the underlying database queries ignored the configured access control scopes.
This vulnerability allows authenticated users to perform unauthorized modifications on records they should not have access to. By knowing or guessing the primary key of a record that is hidden by tenant isolation, ownership rules, or other row-level restrictions, an attacker can directly invoke update, delete, or reorder endpoints targeting those out-of-scope entities. The operational impact includes potential data leakage through unauthorized updates, loss of critical information via deletion, and integrity issues caused by reordering records belonging to different tenants or owners. This represents a classic authorization bypass where the application fails to enforce object-level permissions consistently across all HTTP methods supported by the CRUD interface.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control, specifically reflecting failures in enforcing restrictions on actions performed against specific objects. It also maps to MITRE ATT&CK techniques related to Privilege Escalation and Lateral Movement within application contexts, as an attacker leverages valid credentials but exploits a logic flaw to access resources outside their designated scope. The root cause lies in the separation of query construction for read versus write operations, where the latter failed to inherit the scoped context established by the CRUD panel configuration.
The vulnerability was addressed in versions 6.8.14 and 7.0.38 by refactoring the internal logic to route all three affected write operations through a unified method called getModelWithCrudPanelQuery(). This change ensures that update, delete, and reorder actions utilize the same scoped query builder instance as the list view, thereby enforcing consistent access control policies across all CRUD functionalities. Applications relying on these specific Laravel packages for administration panels must upgrade immediately to mitigate the risk of unauthorized data manipulation. Developers should also audit their implementations to ensure no custom overrides bypass this corrected behavior, maintaining strict adherence to row-level security models throughout the application lifecycle.