Workeera WordPress Plugin EUVD-2026-66879

Exploitation requires an authenticated WordPress session with at least subscriber-level role, which is the lowest non-anonymous role in WordPress. This means exploitation is practically unauthenticated on any site that allows open user registration (the default WordPress configuration permits this). The Workeera plugin must be installed and activated, and the candidate profile feature must be accessible to subscriber-role users, which is the plugin's stated use case. Exploitation is limited by the need for a valid WordPress account: sites that disable open registration and tightly manage user accounts face meaningfully reduced risk. The CVSS vector confirms PR:L (low privilege required), not PR:N, so truly unauthenticated exploitation without any account is not possible.

The NVD CVSS score of 7.7 (High) with a Scope Change is consistent with the ability to read OS-level files beyond the WordPress webroot; this is an accurate severity signal for the worst-case impact. However, real-world exploitation probability is low: EPSS stands at 0.17% (6th percentile), SSVC rates exploitation as 'none' and the technical impact as only 'partial', and CISA has not listed this in KEV. SSVC also rates it non-automatable, meaning mass exploitation campaigns are unlikely without prior enumeration of specific file paths. The primary risk concentrator is subscriber-registration: sites that allow public subscriber sign-up are fully exposed to unauthenticated-in-practice exploitation; sites that tightly control WordPress user creation face a much lower realistic threat. The confidentiality impact on secrets (DB passwords, auth keys) is severe if exploited, warranting priority patching despite low EPSS. No conflict between CVSS signals and the description was identified.

An attacker registers a free WordPress subscriber account on a site running Workeera (or compromises an existing subscriber credential), then submits a crafted POST request to the plugin's candidate-profile update endpoint with a file path value pointing to wp-config.php or /etc/passwd. When the plugin subsequently serves that 'profile file' without path validation, the attacker receives the raw file contents - including database credentials and WordPress secret keys - which can then be used to fully compromise the site or the underlying database server. No public exploit code has been identified at time of analysis.