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, src/resources/views/crud/columns/color.blade.php inverts the escaped and raw rendering branches controlled by $column['escaped'], which defaults to true, causing $column['text'] to be rendered unescaped by default. An attacker who can store an unsanitized value in a color column can execute script in the browser of a user who views the CRUD list, including an administrator, with access to the victim's session-backed application capabilities. Exploitation requires write access to the stored color value and a victim viewing the list. This issue is fixed in versions 6.8.14 and 7.0.38.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-14T18:17:53.223Z",
  "pubdate": "2026-09-14T18:17:53.223Z",
  "executiveSummary": "This vulnerability is a Stored Cross-Site Scripting (XSS) flaw identified in the backpack/crud package, a collection of Laravel administration panel tools.\nThe flaw originates from an improper implementation of data rendering logic in the color column component, which incorrectly handles the escaping of output data.\nBy default, the component fails to sanitize user-supplied content, allowing an attacker to inject and execute arbitrary JavaScript code within the context of a victim's browser session.\nThe impact is significant, as an attacker can compromise the sessions of authenticated users, including administrators, potentially leading to unauthorized administrative actions, data theft, or session hijacking.\nExploitation requires the attacker to possess write access to the stored color value within the application and involves a social engineering or passive component where a victim must view the affected CRUD list containing the malicious payload.\nThe vulnerability affects versions 6.0.0 through 6.8.14 and 7.0.38 of the backpack/crud package. Given the potential for full session compromise of administrative accounts, this vulnerability presents a high-risk security exposure for applications utilizing the affected CRUD components.",
  "technicalDetails": "The root cause of this vulnerability lies in a logic error within src/resources/views/crud/columns/color.blade.php. The template erroneously inverts the conditional branches responsible for handling the '$column['escaped']' configuration variable.\nIn the Laravel framework and its associated blade templates, the '$column['escaped']' parameter is designed to default to true to ensure that all data rendered to the UI is HTML-encoded, thereby preventing XSS attacks. Due to the inversion in the affected versions, the code path intended for escaped output is swapped with the raw (unescaped) output path.\nConsequently, the system renders '$column['text']' unescaped by default. An attacker with the ability to influence the color value stored in the database can inject malicious scripts (e.g., <script>alert(document.cookie)</script>) into the field. Because the rendering engine treats this input as raw HTML, the browser executes the payload when the CRUD list is rendered.\nThe attack flow follows these steps: First, the attacker identifies a CRUD input field that utilizes the color column type. Second, the attacker submits a malicious script string through an interface that persists data to the application database. Third, the vulnerability is triggered when a victim—ideally a privileged administrator—navigates to the administrative CRUD list view where the stored malicious color value is rendered.\nOnce the victim's browser loads the page, the injected JavaScript executes under the security context of the victim's session. This allows for post-exploitation activities such as exfiltrating session tokens, performing requests on behalf of the administrator, or modifying application state through the administration panel.\nThe vulnerability is persistent (Stored XSS) because the payload resides in the application's underlying data store. It does not require specific network exposure, as it relies on the application's internal data handling processes. The exploitation is successful regardless of the user's browser, provided it adheres to standard HTML parsing behaviors, and it remains active until the payload is either manually removed or the underlying code is patched to correctly enforce output escaping."
}