WP Discussion Board EUVD-2026-112063

Exploitation requires an authenticated account with at least low-level privileges (PR:L) able to submit content the WP Discussion Board plugin stores, plus subsequent interaction by a victim who views the injected content (UI:R) - the trigger field and the exact privilege level needed are not described in the available sources. Limiting factors: the attacker cannot act fully unauthenticated, a separate victim must load the malicious content for impact to occur, and only installations running WP Discussion Board versions up to and including 2.6.0 are affected. The payload persists server-side once stored, so impact recurs for every victim who views it until remediated.

This is a moderate-severity stored XSS (CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L) in the WP Discussion Board WordPress plugin, reported by Patchstack and assigned the vuln.today 'this_month' priority rather than an urgent label. The signals are internally consistent and point to a real-but-not-emergency issue: the network attack vector and low complexity are offset by PR:L (an authenticated, low-privileged account is required to plant the payload) and UI:R (a victim must subsequently load the affected page). No EPSS score, no CISA KEV listing, and no proof-of-concept are present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The scope-change flag (S:C) and the limited-but-triple C:L/I:L/A:L impacts are typical of a script executing in another user's authenticated browser context (e.g., an administrator viewing injected content). Overall this is a legitimate patch-management item appropriately prioritized as monthly, not a drop-everything priority; the main caveat is reliance on a single source (Patchstack) and the absence of a stated fixed version.

A low-privileged authenticated user (such as a registered forum participant) submits a discussion-board entry containing a malicious script payload that is stored by the plugin. When a higher-privileged user such as an administrator later views that content in wp-admin or on the site, the stored script executes in their browser session, enabling actions like session/cookie theft or performing admin actions on their behalf. No public exploit code is identified in the available sources; the specific injectable field and sanitization gap are not described in the supplied data.