Extendify WordPress Plugin EUVD-2026-90500

No special configuration is required beyond running a vulnerable Extendify version (≤3.1.6) on a WordPress site with the REST API reachable (the default). Exploitation needs only an unauthenticated HTTP POST, PUT, or PATCH to a /wp/v2/global-styles route; the registerIncoming() handler hooked on rest_request_before_callbacks runs before the route's permission_callback, so no authentication or user interaction by the attacker is required to store the payload. The limiting factor is the impact side: being stored XSS, a victim (visitor or admin) must subsequently load the injected page for the script to execute, and the impact is scoped to browser-side script execution (C:L/I:L) rather than direct server compromise. Upgrading to 3.2.0 removes the condition.

This is a genuinely notable issue despite lacking exploitation telemetry. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N, 7.2) is corroborated by the description's root cause: registerIncoming() is hooked on rest_request_before_callbacks, which fires BEFORE WordPress evaluates the route's permission_callback, so ANY unauthenticated POST/PUT/PATCH to a /wp/v2/global-styles route reaches the vulnerable sink. That makes PR:N and AC:L credible rather than optimistic - there is no authentication or special complexity gate, which is the key differentiator from the many Contributor+ stored-XSS plugin bugs. S:C and the C:L/I:L (not H) limited impacts are consistent with stored XSS executing in the browser of any user who views an injected page. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or automated exploitation yet - treat exploitation status as 'no public exploit identified at time of analysis.' However, the combination of unauthenticated reach, a plugin with a broad install base often bundled by hosts, and an available patch (3.2.0) means this should be prioritized for patching above a typical authenticated/UI-gated XSS. No signals conflict here; the main gap is the absence of EPSS/POC data rather than contradictory data.

An unauthenticated attacker sends a crafted POST, PUT, or PATCH request to a /wp/v2/global-styles REST route carrying a malicious script in the 'styles.blocks' Block Type Key. Because registerIncoming() processes the request before the permission check runs, the payload is stored without authentication; it then executes in the browser of any visitor or administrator who loads an affected page. No public exploit code was identified at time of analysis, but the pre-permission hook makes the code path trivially reachable.