MaxGalleria EUVD-2026-90858

Exploitation requires an unauthenticated attacker to deliver a crafted request/URL containing a malicious payload to a vulnerable MaxGalleria <= 6.5.3 input, AND a victim must interact with it (UI:R) - typically by visiting an attacker-supplied link - for the script to execute in their browser. The limiting factors are: the MaxGalleria plugin must be installed and active on the target WordPress site; the attack value is highest when the lured victim is an authenticated/privileged user; and if the XSS is reflected (not confirmed from the description), the attacker must socially engineer each victim rather than relying on passive triggering. No server-side authentication is needed by the attacker (PR:N).

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L = 7.1 High) describes an unauthenticated, network-reachable Cross-Site Scripting flaw whose exploitation hinges on victim interaction (UI:R) and whose scope change (S:C) reflects script executing in the browser context across the trust boundary. All impact metrics are Low, which is typical for XSS: it does not by itself yield server compromise. No EPSS score, CISA KEV listing, or public POC is provided in the input, so exploitation remains theoretical at time of analysis - there is no public exploit identified. This is a genuine but moderate-priority issue: the High CVSS is driven largely by the scope change inherent to reflected/client-side XSS rather than by severe direct impact. Signals are consistent (network vector, low complexity, no auth, user interaction required) with no conflicts, though the description does not specify whether the XSS is reflected or stored, which materially affects real-world weaponization ease - reflected XSS requires luring a victim to a crafted link, while stored would be more dangerous. Verify the injection type with Patchstack/vendor.

An unauthenticated attacker crafts a malicious URL or request targeting a vulnerable MaxGalleria input that reflects attacker-controlled data without sanitization, then lures a logged-in WordPress user or administrator into clicking it. When the victim's browser renders the response, the injected JavaScript executes in the site's origin, potentially stealing session cookies, performing actions as the victim, or defacing content. No public exploit code is identified at time of analysis, and exploitation requires the victim to interact with the attacker's payload.