Independent Analytics Pro EUVD-2026-114231

The Independent Analytics Pro (paid) build must be active, because the free build nulls campaign parameters and is therefore not affected. The attacker must first request a legitimate frontend page to obtain a valid server-signed payload, then replay it against the unauthenticated /iawp/search REST endpoint with a crafted 'utm_campaign' value - this succeeds specifically because the signature check does not cover utm_* fields. Limiting factors that reduce realistic risk below the raw CVSS score: exploitation is confined to sites licensed and running the Pro build, and script execution only occurs when a user subsequently accesses the injected page, so impact depends on victim page views.

The CVSS 3.1 base score of 7.2 (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N) reflects a network-reachable, unauthenticated flaw of low attack complexity with a changed scope, which is standard for stored XSS whose payload executes in a victim's browser context rather than the vulnerable server. The vuln.today decision label is 'this_week' - a real but non-emergency priority - and there is no CISA KEV listing and no EPSS score supplied, so there is no evidence of active or widespread exploitation; absence of EPSS/KEV data should be treated as missing signal, not as confirmation of low risk. The reporting source is Wordfence (a credible WordPress vulnerability source), but the references point only to the Wordfence advisory and the vendor changelog, so no public exploit identified at time of analysis. The headline score is tempered by concrete deployment prerequisites: exploitation only works when the paid Independent Analytics Pro build is active (the free build nulls campaign parameters), which materially narrows the exposed population below what a raw 7.2 implies. On balance this is a legitimate but bounded web-application XSS to remediate on a normal patch cycle, not a drop-everything emergency.

An attacker first loads a normal frontend page of a WordPress site running the active Independent Analytics Pro build to harvest a valid server-signed request payload. They then replay that signed request against the unauthenticated /iawp/search REST endpoint while substituting a malicious script into the 'utm_campaign' field, which the signature does not cover, storing the payload. The injected script then runs in the browser of any user who subsequently views the affected (e.g. analytics/report) page. No public exploit identified at time of analysis.