Laravel Framework EUVD-2026-88508

Requires the target Laravel application to be running with APP_DEBUG=true - the exception debug renderer is not served in Laravel's recommended production configuration (APP_DEBUG=false), so this is the primary limiting factor. The attacker must additionally get attacker-controlled data into the rendered exception source/context shown on the debug page, and a victim (typically a developer or anyone with access to the debug page) must hover over the affected Tippy.js tooltip (UI:R) to trigger execution. Exploitation is unauthenticated at the network layer (PR:N) but is effectively self-limited to environments left in debug mode.

This is a genuinely low-priority issue despite affecting a ubiquitous framework. The CVSS 3.1 base score is 3.1 (Low) with vector AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N - the high attack complexity (AC:H) and required user interaction (UI:R) reflect that exploitation depends on a non-default deployment state and a victim action. There is no EPSS score, no CISA KEV listing, and no public exploit code provided, so exploitation status is: no public exploit identified at time of analysis. Crucially, the vulnerable code path (the exception debug renderer) is only reachable when APP_DEBUG=true, which is a development/misconfiguration state, not Laravel's recommended production setting. So while the product footprint is huge, the real-world exposed surface is narrow. No conflicting signals: the vendor CVSS, description, and source diff all agree this is a DOM-XSS on the debug page. One nuance to verify - the vendor scored confidentiality as C:N, but DOM-based XSS executing in the victim's browser can typically read session data/tokens, which would justify C:L; this is a defensible upward adjustment rather than a data conflict.

An attacker crafts input (e.g., a value that ends up in a stack trace, source frame, or exception context) that gets rendered on a Laravel exception debug page of a target running with APP_DEBUG=true. Because the source is passed to a Tippy.js tooltip configured with allowHTML:true, the attacker's HTML/JavaScript executes in the browser of a developer or user who hovers over the tooltip. No public proof-of-concept was provided, and the attack requires both debug mode enabled and a victim hover action.