Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Vulnerability Details Affected area: HasMany / MorphMany relation handling during CRUD create and update operations CWE: CWE-862 — Missing Authorization Severity: Medium CVSS: 6.5 — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N Summary Backpack CRUD contained an authorization issue in the way certain HasMany and MorphMany relationship fields were processed during create and update operations. When an admin form allowed users to manage multiple related records, Backpack could update related model records based on submitted primary keys without sufficiently checking whether those records were eligible to be associated with the current parent model. This could allow an authenticated, low-privileged admin user to affect related records outside the intended authorization or tenancy boundary, if the affected CRUD form exposed this type of relationship field. Root Cause The vulnerable logic processed submitted relationship values and updated matching related records without consistently…
Recommended action: Upgrade to 7.0.47 or 6.8.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Backpack\CRUD\Stats::makeCurlRequest builds a shell command using unescaped input that originates from the HTTP Host header, then passes it to exec(). A specially crafted Host header can break out of the shell argument and cause the server to execute arbitrary OS commands as the web user. The vulnerable code path is reached from BackpackServiceProvider::boot() on every HTTP request in production when exec() and curl are available. A 1-in-100 random gate is the only guard — an attacker can reliably trigger it by retrying. Severity High — CVSS 8.1 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H Attack Complexity is rated High because default nginx and Apache configurations typically strip or reject malformed Host headers before they reach PHP, and exec() is often disabled for web processes in hardened environments. Both mitigations must be absent for exploitation. Impact A successful exploit yields OS command execution as the web server user (www-data, nginx, etc.), giving an…
Recommended action: Upgrade to 7.0.36, 6.8.13, 5.6.2 or 4.1.72 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Blade template for the color column type (src/resources/views/crud/columns/color.blade.php) has its escaped/unescaped rendering branches inverted relative to every other column template in the library. Because $column['escaped'] defaults to true, values stored in color columns are rendered unescaped by default, enabling Stored XSS if column values are not validated before storage. Details All other column templates in src/resources/views/crud/columns/ follow the convention: - $column['escaped'] == true → {{ $column['text'] }} (HTML-escaped) - $column['escaped'] == false → {!! $column['text'] !!} (raw) The color template has these branches swapped. An attacker who can write an arbitrary string to a color-typed column can inject JavaScript that executes in the browser of any user who views the list — including administrators — with access to their session cookies and CSRF tokens. Impact Stored XSS with scope change (attacker context runs in victim's browser). Highest-risk…
Recommended action: Upgrade to 7.0.38 or 6.8.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Backpack CRUD's list and read operations correctly apply any query scopes registered via addClause() / addBaseClause() (e.g. tenant isolation, user ownership). However, the Update, Delete, and Reorder operations bypassed these scopes, fetching records directly from the unscoped model query. An authenticated user who knows or can guess a record's primary key could therefore update, delete, or reorder records that should be invisible to them — a classic IDOR on write paths. Applications that rely on addBaseClause for row-level access control (multi-tenancy, per-user data isolation) are affected. Impact Any Backpack CRUD panel that uses addBaseClause or addClause to restrict which rows a user may access is affected on its write operations. An authenticated low-privilege user can modify or delete records belonging to other tenants / users. Patches Apply the fixed release for your major version: - v6: upgrade to 6.8.14 or later - v7: upgrade to 7.0.38 or later The fix ensures…
Recommended action: Upgrade to 7.0.38 or 6.8.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SingleBase64Image::uploadFiles — the uploader bound to image-typed fields via withFiles() — only verifies that the submitted value starts with the string data:image. The MIME subtype and the base64-decoded bytes are never inspected or validated. A related bug in FileNameGenerator causes the stored file to receive an extensionless filename, because mimecontenttype() returns false when given a data URI instead of a filesystem path. The combination allows an authenticated admin to store a file of arbitrary type on the configured disk under a name without a recognizable extension. Details The stored filename ends with a trailing dot and no extension. Impact An authenticated admin submitting a malicious payload to a Backpack image field stored with withFiles() can write arbitrary file content to the configured storage disk. Depending on server configuration and how stored files are served, this may lead to stored XSS or other unintended behavior when the file is later accessed.…
Recommended action: Upgrade to 7.0.38 or 6.8.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`HasUploadFields::uploadMultipleFilesToDisk` (in `src/app/Models/Traits/HasUploadFields.php`) reads file paths from the `clear_ []` request input and deletes them from the configured storage disk without verifying that the paths belong to the current model record. An authenticated user with Update access on any CRUD that wires `uploadMultipleFilesToDisk` as a model mutator (the pattern documented in the v5.x `upload_multiple` field guide) can supply arbitrary disk-relative paths in `clear_ []` to delete files that were never associated with the record they are editing. The safe pattern already exists in the codebase: `src/app/Library/Uploaders/MultipleFiles.php` intersects the requested deletions against the files currently stored in the database column before calling `Storage::disk()->delete()`. The trait method lacks that intersection. Affected code - `src/app/Models/Traits/HasUploadFields.php` — `uploadMultipleFilesToDisk` (primary sink) -…
Recommended action: Partial vendor fix. Review the linked source for mitigation guidance.A vendor fix does not resolve your finding until you verify it in your own systems.
HasUploadFields (used via CrudTrait on Backpack-managed models) and the withFiles() uploader preserve the client-supplied file extension without validation. On installations using a public disk with php artisan storage:link, this allows an authenticated administrator to upload a file with a server-executable extension that the web server will pass to the PHP interpreter - if no MIME or other type of upload validation is present. Details The uploadFileToDisk and uploadMultipleFilesToDisk methods hash the filename stem but write the client-supplied extension to disk verbatim — no allowlist, blocklist, or MIME check is applied inside the trait itself. The newer withFiles() path (via FileNameGenerator) resolves the extension from the file's MIME type rather than the client filename, but also does not block server-executable types. Applications that follow the Backpack quickstart without adding explicit mimes: or mimetypes: validation rules in their form requests are affected.…
Recommended action: Upgrade to 7.0.38 or 6.8.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MyAccountController::postAccountInfoForm allows an authenticated user to update the authentication column (default: email) without verifying their current password. Because email is the account-recovery anchor, this enables account takeover after the attacker's session ends: the new email address can be used to request a password reset from outside the system. The password-change endpoint in the same controller correctly requires oldpassword verification, so the gap is asymmetric. Details The postAccountInfoForm action passes $request-validated() directly to $user-update(). The AccountInfoRequest whitelists the authentication column (email by default) with no ownership challenge. Contrast this with ChangePasswordRequest, which uses Hash::check against the stored password before allowing any change. Scenarios where this is exploitable include: - A brief unauthorized session (e.g. unattended workstation, XSS in the admin panel) - An insider/offboarding case where a departing…
Recommended action: Upgrade to 7.0.38 or 6.8.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The MyAccountController::postAccountInfoForm action bound to POST /admin/edit-account-info calls $this-guard()-user()-update($request-except(['token'])). Because the controller uses except(['token']) rather than $request-validated() or the restricted keys defined in AccountInfoRequest::validationData(), any column present in the user model's $fillable array is mass-assigned from the request, including password. Backpack ships a separate POST /admin/change-password route (postChangePasswordForm) that requires oldpassword verification via ChangePasswordRequest::withValidator. The edit-account-info endpoint silently bypasses that security control. For the default Laravel 11 App\Models\User model — which Backpack's installer and documentation use as the canonical admin user model — $fillable is ['name','email','password']. The password cast is hashed, so a plaintext password=… form field is automatically hashed and persisted. Any attacker holding an authenticated Backpack session…
Recommended action: Upgrade to 7.0.34 or 6.8.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It’s a “moderate” vulnerability… but being an admin panel, take this seriously. It’s difficult… but an attacker could conduct a targeted phishing campaign, in order to trick your users or admins to click a malicious link, which under very specific circumstances could give them information... or even admin access. It’s unlikely, but that’s not good enough in admin panels - It should be made impossible. That’s why you are bothered with this. Patches If you don’t have custom error views, the views provided by Backpack would output the exception message without escaping it, which made an attack possible using Reflected XSS, in some very specific circumstances (that we will not disclose). To fix those error views in Backpack 4.x and 5.x, please run: The problem has been patched in: - v4.0.63 - v4.1.69 - v5.0.13 IMPORTANT! Running a composer update should get you the patched version, but you also need to run php artisan backpack:fix afterwards, to patch your published error views,…
Recommended action: Upgrade to 5.0.13, 4.1.69 or 4.0.63 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Backpack\CRUD Backpack component before 3.4.9 for Laravel allows XSS via the select field type.
Recommended action: Upgrade to 3.4.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.