EUVD-2026-92048
GHSA-p2cx-3mjg-8g5h
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as Admin with role.edit
-
DeliveryRename/edit role to Superadmin or grant user.login_as
-
ExploitBypass name-based Superadmin guard
-
ExecutionGain Superadmin privileges
-
PersistUpload code via core upgrade/module install
-
ImpactExecute arbitrary code
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V8 - Authorization Least privilege enforcement
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires an authenticated account at Admin tier holding the role.edit permission on a LaraDashboard instance before 1.4.8 running in normal (non-demo) mode. The pre-patch guard in RoleController only blocked Superadmin role tampering when config('app.demo_mode') was true and the role name literally equaled 'Superadmin', so standard production deployments are exposed by default to any role.edit holder. Exploitation is LIMITED by the need for pre-existing Admin-level authentication and the role.edit (or role-management) permission - it is not a pre-auth or anonymous attack - and full RCE additionally depends on the core-upgrade/module-installation features being reachable. No user interaction is required. |
| Impact | This is a genuine but access-gated priority. The CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H, base 8.6 HIGH) shows network reach with low complexity and no user interaction, but PR:H confirms the attacker must already hold high privileges - an authenticated Admin account with the role.edit permission. The high-but-not-critical score is driven by this precondition: it is a privilege-escalation-to-full-compromise chain, not a pre-auth breach. No EPSS score, KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The root cause is well-documented: the vendor PR #344 shows the pre-patch code only blocked Superadmin role tampering when config('app.demo_mode') was enabled and matched on the literal role name 'Superadmin', so in normal (non-demo) deployments an Admin could rename/edit roles freely. The fix replaces name-based checks with an is_super_admin boolean flag via a new isSuperAdminRole()/isSuperAdmin() method. Signals are internally consistent - no contradiction between CVSS vector and description. The main caveat: severity depends entirely on the privilege model, since any Admin-tier user with role.edit effectively becomes a latent Superadmin and, through core upgrade / module upload, a code-execution vector. |
| Exploit ScenarioDerived | An authenticated Admin user who holds the role.edit permission edits or renames their own role to 'Superadmin' (or grants themselves user.login_as), bypassing the name-and-demo-mode-only guard in RoleController. Having effectively become Superadmin, they reach the CoreUpgrade UploadRequest and module installation endpoints - previously gated by hasRole(Role::SUPERADMIN) - to upload code and achieve remote code execution. No public exploit is identified at time of analysis, but the vendor advisory and patch diff fully describe the flawed authorization logic. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 04, 2026
Improper privilege management in LaraDashboard before 1.4.8 lets an authenticated Admin-tier user who holds the role.edit permission escalate to Superadmin by renaming or editing roles, or by granting themselves user.login_as rights, which then exposes account takeover and the core-upgrade and module-installation functions needed for code execution. The pre-patch guard in RoleController only refused Superadmin role tampering when the application ran with demo_mode enabled and the role name was literally 'Superadmin', so ordinary production deployments are exposed to any role-management holder by default. Exploitation is access-gated rather than anonymous: it requires a pre-existing Admin account with role.edit, no user interaction is needed, and no public exploit has been identified at time of analysis; the vendor has released the 1.4.8 patch.
RemediationAI
Apply the vendor-released patch by upgrading LaraDashboard to 1.4.8 or later (https://github.com/laradashboard/laradashboard/releases/tag/v1.4.8), which introduces the immutable is_super_admin flag and removes name-string trust; the corresponding upstream fix is PR #344 and commit 286f150e4d0c924ec1ce7eb256b2326e871e9517, and the advisory is at https://github.com/laradashboard/laradashboard/security/advisories/GHSA-555v-6rfr-r969. If upgrading immediately is not possible, reduce exposure by revoking the role.edit permission from every non-Superadmin role and auditing which Admin accounts can reach role management, since the flaw is only reachable by a role.edit holder; note that LaraDashboard ships this permission to Admin tiers by default, so this may break legitimate role administration until the upgrade lands. As a secondary compensating control, rename the Superadmin role to a non-obvious value so the pre-patch $role->name === 'Superadmin' comparison fails, accepting that this is fragile and may break other name-dependent logic in customizations. Additionally block or tightly restrict the core-upgrade upload endpoint and module installation routes (CoreUpgrade/UploadRequest) to Superadmin-only at the reverse proxy or middleware layer, because those are the post-escalation step that converts role tampering into code execution, and monitor authentication/audit logs for role renames, unexpected addition of the user.login_as permission, and login-as events targeting privileged accounts. Enabling app.demo_mode would technically activate the old guard but has broad side effects on normal write operations and is not a substitute for patching.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
LaraDashboard is a Laravel-based admin/dashboard application that builds its authorization model on the Spatie laravel-permission package, where roles are stored as named records and a special 'Superadmin' role gates the most sensitive functionality. This is a CWE-269 (Improper Privilege Management) flaw rooted in the code treating the Superadmin role as a string name rather than as a protected, non-forgeable property. The pre-1.4.8 checks in app/Http/Controllers/Backend/RoleController.php (lines ~144 and ~180) and app/Policies/RolePolicy.php (lines ~39-50) only aborted Superadmin edits/deletes when config('app.demo_mode') was true and $role->name === 'Superadmin'; the same name-based comparison recurs in UserLoginAsController, StoreUserRequest, UpdateUserRequest, UserDatatable and CoreUpgrade\UploadRequest (line ~23). Consequently an Admin could simply rename an existing role to 'Superadmin', or add the user.login_as permission to their own role, and satisfy every name-string check downstream. The fix (PR #344 / commit 286f150e4d0c924ec1ce7eb256b2326e871e9517) introduces an explicit is_super_admin boolean column on app/Models/Role.php exposed through isSuperAdminRole()/isSuperAdmin() helpers and rewrites every guard to use that attribute instead of the mutable role name, so the Superadmin role can no longer be forged by renaming. Per the CPE string cpe:2.3:a:laradashboard:laradashboard:*:*:*:*:*:*:*:*, all releases prior to the 1.4.8 tag are in scope.
Know when Laradashboard gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Network-reachable admin panel (AV:N/AC:L/UI:N); attacker must already be an authenticated high-privilege Admin with role.edit (PR:H); escalation yields full code execution so C/I/A:H, scope unchanged.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
LaraDashboard before 1.4.8 contains an improper privilege management vulnerability that allows authenticated Admin users to escalate to Superadmin by editing or renaming roles. Attackers with role.edit can rename their role to Superadmin or grant user.login_as permissions to take over accounts and reach core upgrade and module installation functions for code execution.
Technical POC Analysis
Class: CWE-269 (Improper Privilege Management), with a CWE-862 (Missing Authorization) component in the policy layer.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Latest POC
1 public PoC link from github
Sign in to open the public PoC links collected for this CVE.
Executive ViewAI
LaraDashboard versions before 1.4.8 contain a high-severity privilege-management flaw that allows an existing Admin-tier account with role.edit to escalate to Superadmin, exposing account takeover and code-execution-capable core-upgrade and module-installation functions. Production deployments are affected by default, so leadership should prioritize remediation because a trusted administrative user could gain full control over the application and its underlying environment. No public exploit has been identified at time of analysis, and the vendor has released a patch in 1.4.8.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
More in Laradashboard
View allLaraDashboard is an all-In-one solution to start a Laravel Application. In 2.3.0 and earlier, the password reset flow tr
Authentication bypass in Lara Dashboard before 1.3.0 lets unauthenticated attackers log in as any registered user by req
Information disclosure in LaraDashboard before 1.4.8 allows an authenticated user who holds only the low-privilege setti
Server-side request forgery in Lara Dashboard 0.9.2-1.3.1 allows any authenticated content editor to proxy arbitrary HTT
Unauthenticated attackers can exhaust LaraDashboard's paid email-verification quota through the public forgot-password a
Path traversal in LaraDashboard before 1.4.8 lets unauthenticated remote attackers read arbitrary JSON files from the ap
Race condition in LaraDashboard 1.4.0 through 1.4.7 allows unauthenticated remote attackers to bypass the per-IP daily r
Open redirect in LaraDashboard before 1.4.8 allows remote attackers to steer an authenticated user who holds email-templ
Exploit-DB