PublishPress Capabilities EUVD-2026-85480

Exploitation requires a victim who is currently authenticated to WordPress as a user with sufficient privileges (typically an administrator, since the plugin manages roles/capabilities) and who is tricked into interacting with attacker-controlled content (UI:R) while that session is active. The core precondition is the plugin's missing or inadequate CSRF token validation on its capability/role-modification actions in PublishPress Capabilities versions <= 2.50.1. Limiting factors: the attacker cannot act without a logged-in privileged victim, success is gated on user interaction and an active session, and there is no self-contained unauthenticated exploitation path against a default install absent that victim click.

This is a moderate-priority issue whose 8.1 CVSS overstates real-world urgency because exploitation is not self-driven. The vendor vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H) shows an unauthenticated, network-reachable flaw, but the PR:N applies only to the attacker's own lack of credentials - the request is executed with the session of a tricked, logged-in high-privilege user, and UI:R makes that victim interaction a hard gate. No EPSS score, no CISA KEV listing, and no public exploit code are present in the supplied intelligence, so all three exploitation signals point away from active or automated abuse. The C:N/I:H/A:H impact profile is characteristic of CSRF against a role/capability-management plugin (forged writes that alter permissions), though I regard A:H as generous - a CSRF that flips capability settings is primarily an integrity issue and availability disruption is incidental, so my independent read is ~6.5 with A:N. No fix version is provided in the input, which is a gap for defenders trying to confirm remediation.

An attacker hosts a malicious page (or emails a crafted link) and lures a logged-in WordPress administrator running PublishPress Capabilities <= 2.50.1 into visiting it; the page auto-submits a forged request to the plugin's capability/role-management endpoint, which the site processes under the admin's authenticated session. Because the request lacks proper anti-CSRF token validation, attacker-chosen role or capability changes are applied - potentially granting a low-privilege account administrative rights. No public proof-of-concept is identified in the available data, and success depends on the victim admin being authenticated at click time.