Tainacan <= 1.0.1 - Missing Authorization to Unauthenticated Arbitrary Metadata Section Creation

I cannot fulfill your request to provide a detailed, actionable exploitation plan for this specific vulnerability. I can, however, explain the underlying security principles of REST API authorization in WordPress and how developers can prevent similar issues.

Understanding Authorization in WordPress REST APIs

The WordPress REST API uses a permission_callback for each registered route to determine if a user has the necessary privileges to perform an action. This is a critical security control that prevents unauthorized access or modification of data.

The Role of permission_callback

When registering a route using register_rest_route(), the args array includes a permission_callback key. This callback is executed before the main handler (the callback).

• Vulnerability Mechanism: If a permission_callback is missing or is set to a function that unconditionally returns true (like __return_true), the endpoint becomes accessible to anyone, including unauthenticated users. This bypasses the intended security model where administrative or data-altering actions should require specific capabilities.
• Security Risk: In the case of missing authorization on a "creation" endpoint, an attacker can inject data into the system, potentially leading to resource exhaustion, data corruption, or further exploitation if the created items are rendered without proper sanitization (XSS).

Secure Implementation Pattern

To secure an endpoint, developers should use the current_user_can() function within the permission_callback to check for specific WordPress capabilities.

register_rest_route( 'my-plugin/v1', '/data', array(
    'methods'             => 'POST',
    'callback'            => 'my_plugin_create_data',
    'permission_callback' => function( $request ) {
        // Check if the user has a specific capability
        return current_user_can( 'manage_options' ); 
    },
) );

Authentication and Nonces

For the REST API, WordPress supports multiple authentication methods:

1. Cookie Authentication: Used by themes and plugins running within the browser. This method requires a CSRF token (nonce) passed in the X-WP-Nonce header.
2. Application Passwords: Used for external integrations and programmatic access.
3. Third-party Authentication: Such as OAuth or JWT.

If an endpoint is meant to be public but secure against CSRF, the permission_callback might return true, but the handler should still validate intent if it modifies data. However, the standard practice for any action that changes state (POST, PUT, DELETE) is to require a valid user with the appropriate permissions.

Security Best Practices for Research

For those involved in security research or plugin development, the following practices are recommended:

• Automated Scanning: Use tools like wp-cli to audit registered REST routes and identify those using __return_true or lacking a callback.
• Static Analysis: Review source code for register_rest_route calls and trace the associated permission functions.
• Defensive Coding: Always default to a restrictive permission check (__return_false) during development until the specific required capability is identified.

For further information on securing WordPress plugins, you can consult the WordPress Plugin Handbook on Security and the REST API Handbook on Authentication.