WP Job Portal CVE-2026-48880

Exploitation requires the attacker to hold a valid WordPress Subscriber-level account on the target site (PR:L per CVSS), making this dependent on whether open user registration is enabled - a common configuration for job portal sites where job seekers self-register. A victim user (typically an administrator or HR manager reviewing applications) must navigate to and render the page containing the injected payload (UI:R). No non-default server-side configuration or special plugin mode is required beyond having WP Job Portal installed and active at a vulnerable version. Exploitation is limited by: the requirement for a registered account (not anonymous), the need for an admin to view the malicious content, and the absence of known public exploit code at time of analysis. Sites with closed registration or no active administrators reviewing submissions have significantly reduced realistic risk.

The CVSS 6.5 Medium score is driven by AV:N/AC:L (easy network exploitation), PR:L (Subscriber account sufficient), UI:R (victim must render the page), and S:C/C:L/I:L (cross-user impact via scope change). Real-world risk is moderate-to-elevated for sites with open user registration, where any visitor can create a Subscriber account and inject payloads targeting administrators. Sites that restrict registration to vetted users have substantially lower exposure. No EPSS score was provided in the available data, limiting exploitation probability assessment. There is no KEV listing and no known public exploit code, suggesting this has not been weaponized at scale. The A:L availability metric in the vendor CVSS vector is atypical for XSS and may reflect browser disruption scenarios; its basis is not confirmed in the vulnerability description. The primary realistic risk is admin session hijacking, which could lead to full site compromise on affected WordPress installations.

An attacker registers a free Subscriber account on a WordPress job board running WP Job Portal <= 2.5.2 and submits a job application containing a crafted JavaScript payload (e.g., a cookie-stealing script) in a profile or application field. When an administrator navigates to review applications, the stored payload executes in the admin's browser, exfiltrating the session cookie to an attacker-controlled endpoint. With the admin session token, the attacker gains full administrative access to the WordPress site. No public proof-of-concept code has been identified, but the attack pattern is well-understood for Stored XSS in WordPress plugins.