LaraDashboard EUVD-2026-92051

Requires an authenticated LaraDashboard account possessing the settings.view permission (PR:L) on a vulnerable instance running a version before 1.4.8; the attacker then calls GET /api/settings or GET /api/settings/{option_name}, which in affected versions return SettingResource option_value without masking sensitive keys. Exploitation is further conditioned on secrets actually being stored in settings (e.g. AI provider API keys, SMTP/mail credentials, tokens having been configured). Limiting factors: no remote-unauthenticated path - a valid low-privilege login is mandatory - and no user interaction is needed once authenticated; organizations that grant settings.view only to fully trusted admins have reduced exposure, and upgrading to 1.4.8 (which adds SensitiveSettingValue masking and hidden-from-API keys) fully mitigates.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N, score 7.1 High) describes a network-reachable, low-complexity information-disclosure flaw whose only impact is confidentiality - but it is explicitly gated behind PR:L, meaning the attacker must already hold an authenticated account carrying the settings.view permission. No EPSS score, KEV listing, SSVC decision, or public POC is present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active or automatable exploitation. This tempers the High CVSS: the flaw is not a remote-unauthenticated breach but a broken-authorization / over-privilege issue where a low-trust internal role can read high-value secrets (AI provider API keys, mail credentials, passwords, tokens) in plaintext. Real-world priority is moderate rather than urgent - the confidentiality blast radius is serious because the leaked secrets enable downstream lateral movement, yet exploitation requires a pre-existing authenticated foothold, and the product has a limited deployment footprint. The patch is confirmed available (PR #340 / release v1.4.8), which should drive prioritization for any org actually running LaraDashboard with multiple user roles.

An authenticated user (or a compromised account) holding only the low-privilege settings.view permission sends GET /api/settings or GET /api/settings/{option_name} and receives configuration option values unmasked, harvesting plaintext AI provider API keys, SMTP/mail credentials, passwords and tokens. No public exploit code is identified, but the attack is trivial - a single authenticated HTTP GET against a documented endpoint with low attack complexity (AC:L) - and the recovered secrets can then be reused against external services.