Workeera WordPress Plugin CVE-2026-77018

Exploitation requires a valid WordPress account with at minimum the subscriber role. On job board deployments intended to accept external candidates - the primary use case for Workeera - open user registration is typically enabled by default, meaning any unauthenticated external party can self-register and immediately meet this prerequisite. The candidate profile submission feature (the plugin's core functionality) must be active. Exploitation is bounded by the SSVC Automatable: no rating, indicating the attack requires navigating a multi-step profile form rather than a single crafted HTTP request, raising the bar against fully automated mass scanning. Sites that have disabled WordPress user self-registration, or that have restricted subscriber accounts from accessing candidate profile submission, are not exposed to this attack path.

The CVSS 8.8 High score and SSVC Technical Impact of 'total' both accurately reflect the consequence of successful exploitation - full RCE on the WordPress host. However, several signals temper the urgency: EPSS is only 0.19% (9th percentile), SSVC Exploitation status is 'none,' and Automatable is 'no,' indicating the attack requires navigating the multi-step profile submission workflow rather than a single automated request. The key practical risk amplifier is deployment context: job board plugins by design enable open user registration, collapsing the PR:L subscriber requirement to a trivial self-registration step for external attackers. A patch (version 1.0.6) is confirmed available, so organizations running unpatched instances of this plugin should treat remediation as high priority, though the low EPSS and no-KEV status suggest opportunistic mass exploitation has not materialized. The Automatable: no rating is consistent with requiring a browser-driven multi-field form submission, which raises the bar slightly above script-kiddie automation.

An attacker self-registers a free subscriber account on a WordPress job board running Workeera (open registration is the expected deployment mode), then navigates to the candidate profile page and submits a PHP webshell disguised as a CV or profile document. The plugin writes the file without type validation to a publicly reachable uploads directory; the attacker then sends a direct HTTP GET request to the file's URL to trigger server-side PHP execution and gain full control of the web host. No public exploit code is confirmed at time of analysis, but the attack pattern is well understood and trivially reproducible by any attacker familiar with WordPress unrestricted upload vulnerabilities.