Lara Dashboard CVE-2026-86184

Requires the target Lara Dashboard (before 1.3.0) to be running with APP_ENV set to any value other than 'production' (e.g. local, staging, development) and the /screenshot-login/{email} HTTP endpoint to be network-reachable. The attacker must know or guess a registered user email - the default/demo superadmin@example.com is a strong candidate. No authentication, credentials, or user interaction are needed once those conditions hold. The primary limiting factor is that production deployments with APP_ENV=production are not affected, so exposure is confined to non-production or misconfigured environments.

The CVSS 4.0 base score of 9.3 (AV:N/AC:L/AT:N/PR:N/UI:N, VC/VI/VA:H) reflects unauthenticated network-reachable full compromise culminating in RCE through the module installer, which is a genuinely severe chain. The decisive real-world modifier, however, is the APP_ENV!=production precondition: a correctly deployed production instance (APP_ENV=production) is not vulnerable, so exposure is limited to staging, development, demo, or misconfigured deployments left in a non-production mode and reachable from the network - a condition outside the attacker's control, which I treat as raising attack complexity. Where that condition holds, exploitation is trivial (a single GET with a known/guessable admin email such as the default superadmin@example.com), so any operator running an internet-facing non-production Lara Dashboard should treat this as urgent and patch immediately. No EPSS or CISA KEV data was supplied and no public exploit was identified at time of analysis; VulnCheck attribution and a released vendor fix lend high confidence to the finding, but the absence of KEV suggests no confirmed widespread active exploitation yet.

An attacker finds a staging or demo Lara Dashboard instance left running with APP_ENV=local/staging and simply issues GET /screenshot-login/superadmin@example.com (or any known admin email), receiving a fully authenticated admin session. From that session they browse database contents and settings, then upload/install a malicious module through the module installer to achieve remote code execution on the host. No public PoC is published, but the single-request technique requires no exploit tooling.