wpForo Forum <= 2.4.13 - Authenticated (Subscriber+) PHP Object Injection

This research plan targets a PHP Object Injection vulnerability in wpForo Forum (<= 2.4.13). The vulnerability resides in the wpforo_display_array_data function, which performs deserialization on untrusted data from user meta or cookies.

1. Vulnerability Summary

• Vulnerability: PHP Object Injection
• Sink: wpforo_display_array_data() (likely using maybe_unserialize() or unserialize() internally).
• Vulnerable Functionality: This function is a helper used to render array data (User Data, User Meta, Cookies) for display in the admin tools or front-end profile sections (e.g., GDPR data access or debug views).
• Source: User-controlled data stored in WordPress User Meta or sent via HTTP Cookies.
• Constraint: A POP chain is required to achieve Remote Code Execution (RCE) or other high-impact actions.

2. Attack Vector Analysis

• Endpoint: The wpForo front-end profile page or a specific AJAX action that invokes the "Debug" or "Data Display" features.
• HTTP Parameter: $_COOKIE (specifically cookies prefixed with wpforo_, such as wpforo_read_topics) or metadata updated via the profile.
• Authentication: Subscriber-level access is sufficient.
• Target Sink Usage: In admin/tools-tabs/debug.php, the function is called as:

  echo wpforo_display_array_data( $_COOKIE, $keys );
  

  Where $keys include wpforo_read_topics.

3. Code Flow

1. The plugin registers a way for users to view their own data (often via a "Profile" -> "Account" or "Privacy" tab).
2. The application invokes a controller that gathers the user's information.
3. The controller calls wpforo_display_array_data($data, $keys).
4. Inside wpforo_display_array_data(), the code iterates over the $data array.
5. For each value, it calls maybe_unserialize($value).
6. If $value is a malicious serialized string provided in a cookie (like wpforo_read_topics), an object is instantiated, triggering its __wakeup() or __destruct() magic methods.

4. Nonce Acquisition Strategy

The vulnerability is primarily triggered via direct page loads or AJAX requests that process cookies.

1. Check for Nonce: Determine if the profile/debug view requires a nonce.
2. Shortcode: wpForo uses the [wpforo] shortcode on its main page.
3. Extraction:
   • Navigate to the forum homepage (default /community/).
   • Use browser_eval to find localized data.
   • Search for wpforo_vars or similar objects:

     // Example search
     window.wpforo_vars?.nonce 
     

4. GDPR/Privacy Path: If the trigger is in the Account/Privacy tab, create a page to ensure the UI is loaded:
   • wp post create --post_type=page --post_status=publish --post_content='[wpforo]'

5. Exploitation Strategy

Step 1: Payload Selection

Since no POP chain is inherent to wpForo, use a generic stdClass for verification or a common WordPress core chain (like Requests_Utility_FilteredIterator if available) to trigger an observable effect (like an error or a request).

• Verification Payload: O:8:"stdClass":1:{s:3:"poc";s:7:"success";}
• Encoding: The payload must be URL-encoded as it will be placed in a cookie.

Step 2: Trigger via Cookie (Recommended)

1. Identify the cookie prefix. The wpforo_prefix() function usually returns wp_ or wpforo_.
2. Set the cookie wpforo_read_topics to the serialized payload.
3. Request the profile "Debug" or "Account Data" view.

Request Template:

GET /community/?wpforo=profile&view=account HTTP/1.1
Host: target.local
Cookie: wpforo_read_topics=O%3A8%3A%22stdClass%22%3A1%3A%7Bs%3A3%3A%22poc%22%3Bs%3A7%3A%22success%22%3B%7D; [WORDPRESS_AUTH_COOKIES]

Step 3: Trigger via User Meta

1. Update the user's nickname or another meta field via the profile settings to a serialized string.
2. Navigate to the page that displays "User Meta Data" using wpforo_display_array_data.

6. Test Data Setup

1. Install wpForo 2.4.13.
2. Create a Subscriber User:
   • wp user create attacker attacker@example.com --role=subscriber --user_pass=password
3. Identify the Forum Page: Find the page containing [wpforo].
4. Enable Debug/Tools (if necessary): Check if wpforo settings allow members to see their own data logs.

7. Expected Results

• Successful Injection: The maybe_unserialize function will process the cookie. If a POP chain is used, the associated action (file deletion, DNS request, etc.) will occur.
• Observation: If an invalid object is injected, it may cause a "Catchable fatal error" or "Object of class stdClass could not be converted to string" error if the plugin tries to echo the result of wpforo_display_array_data.

8. Verification Steps

1. Monitor Logs: Check the PHP error log for messages related to unserialize().
2. Verify Deserialization: Use a class that logs its execution to a file or database.
3. Trace with WP-CLI:
   • wp eval "echo maybe_unserialize('O:8:\"stdClass\":1:{s:3:\"poc\";s:7:\"success\";}')->poc;" (to confirm behavior).

9. Alternative Approaches

• AJAX Endpoint: Search for wp_ajax_wpforo_get_member_data or similar. If it calls the vulnerable function without proper capability checks, it can be exploited via a POST request to admin-ajax.php.
• Server Info View: If the "Server" view in debug.php is accessible to non-admins due to a logic flaw, it might process other inputs (though it primarily uses $_SERVER).
• User Data View: Target the wpfu parameter in debug.php. If a Subscriber can access this tab, they can supply their own ID and trigger the processing of their own (maliciously crafted) meta.