JS Help Desk EUVD-2026-36861

No authentication is required - the CVSS vector PR:N confirms unauthenticated exploitation. No special configuration beyond a default installation of JS Help Desk 3.0.9 or earlier is needed; the flaw appears to reside in standard plugin functionality accessible to any HTTP client. Exploitation is limited to WordPress sites running the affected plugin version; the scope does not extend beyond the plugin's own functionality (S:U), and there is no confidentiality impact (C:N), so sensitive data exfiltration is not an expected outcome based on available data. Exploitation is further bounded by the low-level integrity and availability impact (I:L/A:L), suggesting the unauthorized actions affect help desk records rather than enabling full site compromise. No platform-specific or non-default configuration prerequisite has been identified.

The CVSS 6.5 Medium score is driven by the favorable (for attackers) access profile: network-reachable, low complexity, no privileges, no user interaction. The impact is constrained to I:L and A:L with no confidentiality loss (C:N), and scope is unchanged (S:U), meaning exploitation does not pivot to the broader WordPress core or server. No EPSS score was provided in the source data, so exploitation probability cannot be quantitatively assessed. No CISA KEV listing and no confirmed public proof-of-concept exist at time of analysis, which moderates urgency. However, the zero-prerequisite exploitation profile means any automated scanner or opportunistic attacker can attempt this without setup. The realistic priority is moderate: sites hosting sensitive support tickets (PII, credentials in ticket threads) face meaningful integrity and availability risk despite the bounded CVSS impact metrics. EPSS data absence is a gap - defenders should monitor Patchstack and NVD for updates.

An unauthenticated attacker identifies a WordPress site running JS Help Desk via passive fingerprinting (plugin path enumeration or HTTP response headers) and sends a crafted HTTP POST or GET request directly to a vulnerable plugin endpoint - such as an admin-ajax action or REST route - that lacks authorization verification. The plugin processes the request without checking user capabilities, allowing the attacker to modify or delete support tickets, alter ticket metadata, or trigger availability-affecting operations on the help desk data. No public proof-of-concept has been identified, but the attack requires only standard HTTP tooling given the PR:N/AC:L profile.