Slider Responsive Slideshow – Image slider, Gallery slideshow <= 1.5.4 - Authenticated (Contributor+) PHP Object Injection

This research plan outlines the steps to investigate and exploit CVE-2026-22346, a PHP Object Injection vulnerability in the Slider Responsive Slideshow plugin.

---

1. Vulnerability Summary

The Slider Responsive Slideshow plugin (<= 1.5.4) is vulnerable to PHP Object Injection. This occurs when the plugin takes user-supplied input—likely slider configuration, settings, or import data—and passes it to the PHP unserialize() function without adequate validation. While the plugin itself may not contain a usable POP (Property Oriented Programming) chain, an attacker with Contributor-level permissions can inject a serialized object that triggers a chain in other active plugins or WordPress core, potentially leading to Remote Code Execution (RCE) or file deletion.

2. Attack Vector Analysis

• Endpoint: Likely a WordPress AJAX handler (admin-ajax.php) or an admin-post handler (admin-post.php).
• Vulnerable Parameter: Likely a POST parameter named data, slider_data, settings, or content (inferred).
• Action Hook: Likely wp_ajax_save_slider_data, wp_ajax_create_slider, or a similar administrative action (inferred).
• Authentication: Requires a user with at least Contributor role.
• Preconditions: The attacker must have a valid session and, usually, a valid WordPress nonce associated with the slider management functionality.

3. Code Flow (Inferred)

1. Entry Point: An authenticated user (Contributor+) sends a request to wp-admin/admin-ajax.php.
2. Hook Registration: The plugin registers an AJAX action:
   add_action('wp_ajax_XYZ', '...handler_function...').
3. Data Retrieval: The handler function retrieves a POST parameter containing serialized data:
   $raw_data = $_POST['slider_data'];
4. Vulnerable Sink: The handler (or a function it calls) passes this data to unserialize():
   $decoded_data = unserialize(base64_decode($raw_data)); or $decoded_data = unserialize(stripslashes($raw_data));
5. Injection: The PHP engine instantiates the object defined in the payload, triggering __wakeup() or __destruct() magic methods.

4. Nonce Acquisition Strategy

Since the vulnerability is Contributor+, we can access the WordPress admin dashboard to retrieve the necessary nonce.

1. Identify the Shortcode: Search the plugin code for add_shortcode to find how sliders are rendered.
   • Target: grep -r "add_shortcode" . (Likely [responsive-slider]).
2. Identify the Localization Key: Search for where the plugin enqueues scripts and localizes data.
   • Target: grep -r "wp_localize_script" .
3. Creation of Test Page:
   wp post create --post_type=page --post_status=publish --post_title="Exploit Page" --post_content='[responsive-slider]' --post_author=CONTRIBUTOR_ID
4. Browser Extraction:
   • Navigate to the newly created page or the plugin's admin settings page.
   • Use browser_eval to extract the nonce.
   • Inferred Variable: window.slider_ajax_object?.nonce or window.responsive_slider_vars?.ajax_nonce.

5. Exploitation Strategy

The goal is to demonstrate that a serialized string reaches unserialize().

1. Login as Contributor: Use the http_request tool to obtain session cookies.
2. Discovery:
   • Examine the plugin's AJAX handlers: grep -r "wp_ajax_" .
   • Look specifically for handlers that call unserialize(): grep -rn "unserialize" .
3. Craft Payload:
   • Since no internal POP chain is confirmed, use a simple "Standard Injection" payload that triggers a recognizable PHP error if it fails (e.g., an O:8:"NonExist":0:{}) or a known core chain if available.
   • Example Payload: O:8:"Wp_Theme":0:{} (Standard core class).
4. Execute Request:

   POST /wp-admin/admin-ajax.php HTTP/1.1
   Content-Type: application/x-www-form-urlencoded
   Cookie: [Contributor Cookies]
   
   action=[VULNERABLE_ACTION]&nonce=[EXTRACTED_NONCE]&slider_data=[SERIALIZED_PAYLOAD]
   

5. Verification of Sink: If WP_DEBUG is on, look for "Class 'NonExist' not found" or similar serialization errors in the response.

6. Test Data Setup

1. User Creation:
   wp user create attacker attacker@example.com --role=contributor --user_pass=password
2. Plugin Activation:
   wp plugin activate slider-responsive-slideshow
3. Slider Creation: If the plugin requires an existing slider to trigger the code path:
   • Navigate to the plugin menu.
   • Create a dummy slider.
   • Note the Slider ID.

7. Expected Results

• Success: The server processes the request. If the payload contains an invalid class, a PHP warning/error may be generated in wp-content/debug.log. If a valid POP chain is used, the side effects of that chain (e.g., file creation) should be visible.
• Response: Often a 200 OK or wp_die() message, but the magic happens in the PHP background during the unserialize() call.

8. Verification Steps

1. Monitor Logs: Check /var/www/html/wp-content/debug.log for serialization errors.
2. Trace Invocation: If possible, add temporary logging to the plugin code to confirm the input reaches the sink:
   file_put_contents('/tmp/sink.txt', "Input: " . $_POST['vulnerable_param']);
3. Database State: Check if the injected string was stored in wp_postmeta or wp_options.
   wp db query "SELECT * FROM wp_postmeta WHERE meta_value LIKE '%O:%'"

9. Alternative Approaches

• Check Import Functionality: Slider plugins often have an "Import Slider" feature. This is a common place for unserialize() to be used on uploaded file contents.
  • Path: Search for move_uploaded_file or $_FILES combined with unserialize.
• Settings Saving: Check if slider settings are sent as a JSON/Serialized blob in a single POST field.
  • If the plugin uses maybe_unserialize(), ensure the input starts with a: or O: to trigger the deserialization logic.