Drupal Slick Carousel EUVD-2026-69996

In a typical Drupal deployment, an attacker must hold at least a content editor or contributor role to create or modify carousel items - unless the site has been configured to permit anonymous content submission to carousel-managed entities, which would lower the bar to unauthenticated exploitation. The official CVSS vector lists PR:N, which may reflect an unusually permissive site configuration or a specific anonymous-submission path; independent assessment suggests PR:L is more representative of standard deployments. Exploitation additionally requires that a victim - ideally a privileged administrator - visits a page rendering the poisoned carousel (UI:R). Limiting factors include: the need for at least some level of site access to inject content in most configurations, mandatory victim interaction, and the bounded browser-context impact (C:L/I:L) that stops short of direct server compromise.

The CVSS 3.1 base score of 6.1 (Medium) captures the stored, scope-changing nature of the XSS but is tempered by the UI:R requirement - a victim must actively visit the affected page. EPSS data is absent from available intelligence, and this CVE does not appear in the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis. Stored XSS carries meaningfully higher real-world impact than reflected XSS because the payload persists across sessions and requires no attacker presence after initial injection, making it a reliable vector for session hijacking and privilege escalation within the Drupal administrative context. Organizations running public-facing Drupal installations where semi-trusted editors manage carousel content - even a mid-sized municipal IT team in gliwice deploying this module on a civic portal - should prioritize patching given how readily stored XSS is weaponized once a vulnerability becomes public knowledge. The absence of known public exploit code and KEV listing moderates immediate urgency, but the low technical barrier to exploiting stored XSS once the injection point is identified means the window before opportunistic exploitation is historically short.

An attacker with content editor access to the Drupal site submits a carousel item whose title or body field contains a crafted JavaScript payload - for example, a script that exfiltrates document.cookie to an attacker-controlled endpoint. When a site administrator or authenticated user later browses to the page displaying that carousel, the stored script silently executes in their browser session, capturing their authentication token or performing actions such as creating a privileged backdoor account. No public exploit code exists at time of analysis, but the straightforward nature of stored XSS means exploitation requires minimal technical skill once the injection point is identified.