LaraDashboard CVE-2026-120487

Requires an authenticated, non-Superadmin administrator account holding the legacy settings.edit permission, which the default Admin role carries; it is NOT exploitable by unauthenticated or anonymous users. Once that foothold exists, no special configuration is needed - the /admin/settings/core-upgrades routes (index, GET/POST backup, download, restore, upgrade, delete-backup) are gated only by can:settings.edit in affected versions (present since v1.0.x through v1.4.2), so backup creation, download of database/backup.sql, and restore/upgrade/delete are reachable against default deployments. The primary limiting factor is the need for a pre-existing low-privilege Admin account; there is no required user interaction and attack complexity is low. Fixed in v1.4.5, which restricts these operations to a Superadmin role check.

This is a genuine access-control flaw worth prioritizing in environments that actually run LaraDashboard, but the raw 8.6/8.8 score overstates reach because exploitation is not unauthenticated. CWE-863/862 incorrect authorization: SettingPolicy::manageCoreUpgrades()/viewCoreUpgrades() gated the core-upgrade control plane on the ordinary legacy settings.edit permission (Admin role by default) instead of the intended Superadmin-only check, so any low-privileged administrator can reach backup/download/restore/upgrade/delete. There is a NOTABLE CONFLICT in the authentication metric: the input CVSS 4.0 vector asserts PR:H, but the GHSA advisory, the description ('non-Superadmin administrators with settings.edit') and the policy code all indicate an ordinary Admin permission - i.e. PR:L. The GHSA 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8) is better supported by the evidence; treat the input PR:H as likely too strict and verify privilege model with the vendor. No EPSS score was provided and the CVE is not listed in CISA KEV, so there is no signal of widespread or active exploitation; the GHSA advisory does include a detailed reproduction PoC script, which raises practical exploitability for anyone who already holds an Admin account. The vuln.today decision label is this_week (not act_now/emergency), consistent with a high-impact but authentication-gated issue in a niche product. Net: real priority for LaraDashboard operators (full source + database/password-hash exfiltration and site tampering from a mere Admin), but the required pre-existing low-privilege admin foothold limits blast radius compared to a network-unauthenticated bug.

An attacker who already holds (or has been granted) an ordinary Admin account with settings.edit - for example an author promoted into a role group or a module client-admin - logs into the panel and uses /admin/settings/core-upgrades to create and download a full backup containing the application source, .env/config secrets and database/backup.sql with user password hashes, then issues restore/upgrade/delete to tamper with code and data. A working reproduction PoC (login → create backup → download → restore) is published in the GHSA advisory, so the full backup-exfiltration chain is low-effort for any such authenticated Admin. Attack vector is network with low complexity and no user interaction, but it requires a valid low-privilege admin session (PR:L), not anonymous access.