LaraDashboard EUVD-2026-115223

Exploitation requires an authenticated account holding the post.create or post.edit permission (per the description and PR:L), which in LaraDashboard includes authors, editors, and membership-module members. The attacker stores script or event-handler markup in a LaraBuilder design_json block (text-editor, HTML, text, or heading type), which v1.4.8 and earlier render raw via {!! ... !!} in the builder preview, admin post view, email-template preview, and rendered public page. Execution additionally requires a victim with higher privilege (administrator or Superadmin) to view that content (UI:P), so it is not a fully automatable unauthenticated attack. Limiting factors: a valid low-privilege authenticated account is needed, the content-authoring feature must be in use, and a privileged user must open the affected view; these apply to default configurations of LaraDashboard rather than a special non-default mode.

This is a genuine but moderate-priority issue, not a drop-everything emergency, and the signals are internally consistent on that point. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N, 5.1 medium) models a stored XSS that requires an authenticated low-privilege account (PR:L) plus a privileged victim to view the content (UI:P), with impact confined to the subsequent system (the admin's browser session: SC:L/SI:L) rather than the vulnerable application itself. The vuln.today decision label is 'this_month', which matches a medium-severity authenticated flaw. There is no CISA KEV entry and no EPSS score in the provided data, so there is no evidence of active or widespread exploitation; note that absence of EPSS/KEV is not itself a risk signal. A detailed PoC is published inside the GHSA advisory. Two signals conflict and should be reconciled before relying on severity: the vendor GHSA advisory rates the same flaw far higher (CVSS 3.1 AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N) on the theory that the admin-session XSS chains to full admin/Superadmin takeover, whereas the input 4.0 vector assigns no confidentiality/integrity impact to the vulnerable system and only low subsequent impact - verify which impact model your program uses, because the realistic worst case (session/CSRF theft leading to admin takeover, as the advisory describes) sits closer to the vendor's rating than to 5.1. Net: real priority for any LaraDashboard operator that grants post.create/post.edit to semi-trusted authors, but gated behind authentication and victim interaction.

A low-privilege author or editor account (holding post.create or post.edit) saves a LaraBuilder text-editor, HTML, text, or heading block whose content contains script or event-handler markup such as <img src=x onerror=...>. When an administrator or Superadmin later opens the builder, the preview, or the rendered page, the stored payload executes in their authenticated session, enabling session/CSRF-token theft and privileged actions. A public PoC reference (a bash reproduction script) is included in the GHSA-w878-x2w9-3r6f advisory; it is not verified here as working exploit code.