Xagio SEO CVE-2026-78295

Requires an authenticated WordPress user with an active session - most impactfully an administrator - to be tricked into visiting an attacker-controlled page while logged in (UI:R). Exploitation depends on a Xagio SEO state-changing endpoint lacking valid nonce/CSRF token verification; the attacker never authenticates directly but rides the victim's privileges. Limiting factors: the forged request only succeeds against a live authenticated session, the actual impact is bounded by whatever single action the vulnerable endpoint performs (not specified in the advisory), and standard browser SameSite cookie defaults may blunt some cross-site request delivery.

This is a CWE-352 Cross-Site Request Forgery in the Xagio SEO WordPress plugin (<= 7.1.0.43), reported by Patchstack. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = 8.8) treats the flaw as delivering full confidentiality, integrity, and availability compromise, but this looks inflated: CSRF is intrinsically integrity-oriented, requires a logged-in privileged victim to click an attacker-controlled link (UI:R), and the one-line description gives no evidence that a single forged request yields data disclosure (C:H) or service outage (A:H). No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no signal of active or automated exploitation. PR:N is technically defensible for CSRF (the attacker is unauthenticated; the victim's session supplies privilege), but the real-world bar is meaningful - the attacker must lure an authenticated user, most impactfully an administrator, into visiting a malicious page. Net: this is a plausible but not urgent issue whose headline 8.8 overstates realistic impact; treat as medium priority, prioritized by whether the forged action reaches sensitive admin settings.

An attacker crafts a malicious web page containing an auto-submitting form or forged request targeting a state-changing Xagio SEO endpoint that lacks nonce/CSRF validation. When a logged-in WordPress administrator visits the page, their browser silently submits the request under their session, performing the privileged action (e.g., altering SEO configuration). No public exploit code is referenced in the provided data.