Laradashboard
Monthly
LaraDashboard through 1.4.2 lets any administrator holding the ordinary settings.edit permission - which the default Admin role carries - reach Superadmin-only core-upgrade functionality, so a low-privileged admin can create and download full backups that include the application source and database/backup.sql with password hashes, and can trigger restore, delete-backup or core-upgrade operations against the site. The root cause is an incorrect authorization check in SettingPolicy, not an unauthenticated weakness: exploitation requires a pre-existing non-Superadmin Admin account, needs no user interaction, and has low attack complexity against default deployments. The vendor fixed the issue in v1.4.5, and the GitHub advisory includes a public proof-of-concept reproduction script that has not been independently verified as working exploit code; the supplied intelligence contains no CISA KEV listing or other confirmed active-exploitation signal.
Information disclosure in LaraDashboard before 1.4.8 allows an authenticated user who holds only the low-privilege settings.view permission to read stored secrets in plaintext by calling GET /api/settings or GET /api/settings/{option_name}, exposing AI provider API keys, mail/SMTP credentials, passwords and tokens. The flaw is an incorrect authorization / masking failure (CWE-863): the settings API policy treats the view permission as sufficient while SettingResource serializes option_value verbatim, so any account granted settings.view sees every configured secret; exposure is conditioned on secrets actually having been saved in settings. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has released 1.4.8, which introduces secret masking, keys hidden from the API, and a dedicated update policy.
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.
Server-side request forgery in Lara Dashboard 0.9.2-1.3.1 allows any authenticated content editor to proxy arbitrary HTTP requests through the application server via the markdown fetch API endpoint, with the server returning response bodies verbatim to the caller. The POST /api/admin/builder/markdown/fetch endpoint validated only URL format (not destination host), enabling requests to internal services and cloud metadata endpoints such as AWS IMDSv1 at 169.254.169.254, which can yield IAM role temporary credentials. No public exploit identified at time of analysis; vendor-released patch is available in v1.3.2.
Authentication bypass in Lara Dashboard before 1.3.0 lets unauthenticated attackers log in as any registered user by requesting GET /screenshot-login/{email}, provided the deployment runs with APP_ENV set to anything other than production. The route was a demo-screenshot helper (used by an internal Browsershot command with superadmin@example.com) that was reachable in non-production environments, granting a fully authenticated session that reaches user administration, settings, database contents, and arbitrary code execution via the module installer. Reported by VulnCheck with a vendor patch available (v1.3.0); no public exploit identified at time of analysis, though the trivial GET-based technique is effectively self-documenting.
Stored cross-site scripting in LaraDashboard 1.4.8 and earlier lets any authenticated account holding the post.create or post.edit permission persist script or event-handler markup inside LaraBuilder design_json blocks (text-editor, HTML, text or heading), which the application then renders unescaped in the builder preview, the admin post view, email-template previews and published pages. Because the payload executes in the browser of a higher-privileged viewer - an administrator or Superadmin opening the content - a low-privilege author can chain the execution with the account's own CSRF-exposed actions toward privilege escalation; exploitation requires a valid low-privilege account and a privileged user action (PR:L/UI:P per the assessed CVSS:3.1 vector AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N), so it is not an unauthenticated or fully automatable attack and is rated moderate priority rather than an emergency. A public proof-of-concept reproduction script is included in the vendor GHSA advisory; it has not been independently verified as working exploit code, and no active exploitation (CISA KEV) has been confirmed. Vendor-released patch: 1.4.9.
Improper authorization in LaraDashboard 1.4.0 through 1.4.8 lets an authenticated user holding only the read-only email_template.view permission send arbitrary HTML email through the MCP send-email tool. Authenticated low-privilege users (or holders of an MCP token minted while that permission was present) can mint a token and POST attacker-chosen sender, recipient, subject and raw HTML body to /mcp/send-email, turning the application's mailer into a phishing or spam relay that abuses the site's sending reputation; the assessed impact is a limited integrity violation, with no confidentiality or availability impact. The vendor fixed the permission check in v1.4.9 (the tool now requires email_template.edit), and the GHSA includes a public proof-of-concept script that has not been independently verified as working exploit code; no confirmed active exploitation (CISA KEV) or public exploit tooling is indicated at time of analysis.
Race condition in LaraDashboard 1.4.0 through 1.4.7 allows unauthenticated remote attackers to bypass the per-IP daily registration limit by flooding concurrent registration requests, so that every request passes RegistrationGuardService::hasExceededIpLimit before any recordRegistration call commits. The result is bulk account creation that defeats the product's anti-automation and anti-spam controls, with impact limited to integrity of the registration state (no confidentiality or availability effect). Exploitation requires that public self-registration is enabled and the per-IP cap is active, and it depends on winning a narrow TOCTOU window, so attack complexity is high; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis. EPSS data was not provided, but the assessed severity is low-to-moderate rather than critical.
Open redirect in LaraDashboard before 1.4.8 allows remote attackers to steer an authenticated user who holds email-template permissions to an attacker-controlled phishing site after that user saves an email template. The flaw lives in the EmailTemplateController builder and builderEdit endpoints, which accepted a redirect_url query parameter and used it verbatim as the post-save navigation target, with the same raw value also flowing into the React LaraBuilder front end via the mount element's data-redirect-url attribute. Exploitation requires passive user interaction (UI:P); the attacker needs no authentication of their own against the endpoint (PR:N), but the victim must be a logged-in user with email-template rights who opens a crafted builder link and then triggers a save. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the impact is bounded to redirection-based phishing rather than direct compromise of the application, consistent with a medium-severity (CVSS 4.0 base 5.3; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N) rating.
Unauthenticated attackers can exhaust LaraDashboard's paid email-verification quota through the public forgot-password and reset-password endpoints, causing advanced email validation to fail open across all public forms. Affected releases are 1.4.2 up to but not including 1.4.8, where the ForgotPasswordRequest and ResetPasswordRequest classes apply advanced DNS and AbstractAPI-based checks to arbitrary submitted addresses. Exploitation requires PR:N per the provided CVSS 4.0 vector, meaning no authentication is needed, and no public exploit code or CISA KEV confirmation is present; impact is a low-availability resource-exhaustion condition rather than code execution or data compromise.
Path traversal in LaraDashboard before 1.4.8 lets unauthenticated remote attackers read arbitrary JSON files from the application by manipulating the {lang} segment of the public /api/translations/{lang} endpoint. Because the route concatenates the user-supplied value into a filesystem path and appends '.json', an attacker on a Windows host can submit URL-encoded backslash sequences such as ..%5C to escape the resources/lang directory and retrieve files like composer.json or version.json, exposing dependency and version metadata. The impact is limited to confidentiality (read-only, JSON files only) with no write or code execution, and no public exploit code was identified at time of analysis; a vendor fix is available in v1.4.8.
LaraDashboard through 1.4.2 lets any administrator holding the ordinary settings.edit permission - which the default Admin role carries - reach Superadmin-only core-upgrade functionality, so a low-privileged admin can create and download full backups that include the application source and database/backup.sql with password hashes, and can trigger restore, delete-backup or core-upgrade operations against the site. The root cause is an incorrect authorization check in SettingPolicy, not an unauthenticated weakness: exploitation requires a pre-existing non-Superadmin Admin account, needs no user interaction, and has low attack complexity against default deployments. The vendor fixed the issue in v1.4.5, and the GitHub advisory includes a public proof-of-concept reproduction script that has not been independently verified as working exploit code; the supplied intelligence contains no CISA KEV listing or other confirmed active-exploitation signal.
Information disclosure in LaraDashboard before 1.4.8 allows an authenticated user who holds only the low-privilege settings.view permission to read stored secrets in plaintext by calling GET /api/settings or GET /api/settings/{option_name}, exposing AI provider API keys, mail/SMTP credentials, passwords and tokens. The flaw is an incorrect authorization / masking failure (CWE-863): the settings API policy treats the view permission as sufficient while SettingResource serializes option_value verbatim, so any account granted settings.view sees every configured secret; exposure is conditioned on secrets actually having been saved in settings. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has released 1.4.8, which introduces secret masking, keys hidden from the API, and a dedicated update policy.
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.
Server-side request forgery in Lara Dashboard 0.9.2-1.3.1 allows any authenticated content editor to proxy arbitrary HTTP requests through the application server via the markdown fetch API endpoint, with the server returning response bodies verbatim to the caller. The POST /api/admin/builder/markdown/fetch endpoint validated only URL format (not destination host), enabling requests to internal services and cloud metadata endpoints such as AWS IMDSv1 at 169.254.169.254, which can yield IAM role temporary credentials. No public exploit identified at time of analysis; vendor-released patch is available in v1.3.2.
Authentication bypass in Lara Dashboard before 1.3.0 lets unauthenticated attackers log in as any registered user by requesting GET /screenshot-login/{email}, provided the deployment runs with APP_ENV set to anything other than production. The route was a demo-screenshot helper (used by an internal Browsershot command with superadmin@example.com) that was reachable in non-production environments, granting a fully authenticated session that reaches user administration, settings, database contents, and arbitrary code execution via the module installer. Reported by VulnCheck with a vendor patch available (v1.3.0); no public exploit identified at time of analysis, though the trivial GET-based technique is effectively self-documenting.
Stored cross-site scripting in LaraDashboard 1.4.8 and earlier lets any authenticated account holding the post.create or post.edit permission persist script or event-handler markup inside LaraBuilder design_json blocks (text-editor, HTML, text or heading), which the application then renders unescaped in the builder preview, the admin post view, email-template previews and published pages. Because the payload executes in the browser of a higher-privileged viewer - an administrator or Superadmin opening the content - a low-privilege author can chain the execution with the account's own CSRF-exposed actions toward privilege escalation; exploitation requires a valid low-privilege account and a privileged user action (PR:L/UI:P per the assessed CVSS:3.1 vector AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N), so it is not an unauthenticated or fully automatable attack and is rated moderate priority rather than an emergency. A public proof-of-concept reproduction script is included in the vendor GHSA advisory; it has not been independently verified as working exploit code, and no active exploitation (CISA KEV) has been confirmed. Vendor-released patch: 1.4.9.
Improper authorization in LaraDashboard 1.4.0 through 1.4.8 lets an authenticated user holding only the read-only email_template.view permission send arbitrary HTML email through the MCP send-email tool. Authenticated low-privilege users (or holders of an MCP token minted while that permission was present) can mint a token and POST attacker-chosen sender, recipient, subject and raw HTML body to /mcp/send-email, turning the application's mailer into a phishing or spam relay that abuses the site's sending reputation; the assessed impact is a limited integrity violation, with no confidentiality or availability impact. The vendor fixed the permission check in v1.4.9 (the tool now requires email_template.edit), and the GHSA includes a public proof-of-concept script that has not been independently verified as working exploit code; no confirmed active exploitation (CISA KEV) or public exploit tooling is indicated at time of analysis.
Race condition in LaraDashboard 1.4.0 through 1.4.7 allows unauthenticated remote attackers to bypass the per-IP daily registration limit by flooding concurrent registration requests, so that every request passes RegistrationGuardService::hasExceededIpLimit before any recordRegistration call commits. The result is bulk account creation that defeats the product's anti-automation and anti-spam controls, with impact limited to integrity of the registration state (no confidentiality or availability effect). Exploitation requires that public self-registration is enabled and the per-IP cap is active, and it depends on winning a narrow TOCTOU window, so attack complexity is high; there is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis. EPSS data was not provided, but the assessed severity is low-to-moderate rather than critical.
Open redirect in LaraDashboard before 1.4.8 allows remote attackers to steer an authenticated user who holds email-template permissions to an attacker-controlled phishing site after that user saves an email template. The flaw lives in the EmailTemplateController builder and builderEdit endpoints, which accepted a redirect_url query parameter and used it verbatim as the post-save navigation target, with the same raw value also flowing into the React LaraBuilder front end via the mount element's data-redirect-url attribute. Exploitation requires passive user interaction (UI:P); the attacker needs no authentication of their own against the endpoint (PR:N), but the victim must be a logged-in user with email-template rights who opens a crafted builder link and then triggers a save. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the impact is bounded to redirection-based phishing rather than direct compromise of the application, consistent with a medium-severity (CVSS 4.0 base 5.3; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N) rating.
Unauthenticated attackers can exhaust LaraDashboard's paid email-verification quota through the public forgot-password and reset-password endpoints, causing advanced email validation to fail open across all public forms. Affected releases are 1.4.2 up to but not including 1.4.8, where the ForgotPasswordRequest and ResetPasswordRequest classes apply advanced DNS and AbstractAPI-based checks to arbitrary submitted addresses. Exploitation requires PR:N per the provided CVSS 4.0 vector, meaning no authentication is needed, and no public exploit code or CISA KEV confirmation is present; impact is a low-availability resource-exhaustion condition rather than code execution or data compromise.
Path traversal in LaraDashboard before 1.4.8 lets unauthenticated remote attackers read arbitrary JSON files from the application by manipulating the {lang} segment of the public /api/translations/{lang} endpoint. Because the route concatenates the user-supplied value into a filesystem path and appends '.json', an attacker on a Windows host can submit URL-encoded backslash sequences such as ..%5C to escape the resources/lang directory and retrieve files like composer.json or version.json, exposing dependency and version metadata. The impact is limited to confidentiality (read-only, JSON files only) with no write or code execution, and no public exploit code was identified at time of analysis; a vendor fix is available in v1.4.8.