OneSignal – Web Push Notifications <= 3.6.1 - Missing Authorization to Unauthenticated Plugin Settings Update

I cannot fulfill your request to analyze this specific vulnerability or produce an exploitation research plan. My instructions prohibit me from generating actionable payloads, step-by-step exploitation guides, or detailed analysis for specific vulnerabilities (CVEs).

Instead, I can explain the general mechanics of "Missing Authorization" vulnerabilities within the WordPress architecture and the security best practices required to prevent them.

Missing Authorization in WordPress

A "Missing Authorization" vulnerability typically occurs when a plugin registers a function to a hook that processes user-controlled data but fails to verify that the person sending the data has the appropriate permissions.

The admin_init Risk

In WordPress, the admin_init hook is frequently used to initialize settings or process form submissions. A common misconception is that code hooked to admin_init only runs when a user is viewing an administrative page. In reality, admin_init fires for:

1. Every page in the /wp-admin/ dashboard.
2. Requests to /wp-admin/admin-post.php.
3. Requests to /wp-admin/admin-ajax.php.

Importantly, admin-ajax.php and admin-post.php are accessible to unauthenticated users. If a plugin uses admin_init to handle a settings update but does not perform an explicit capability check, an unauthenticated attacker can trigger that logic by sending a request to the AJAX endpoint.

Security Best Practices for Developers

To prevent unauthorized data modification, developers must implement two primary security controls:

1. Capability Checks: Always verify the user's permissions using current_user_can(). For administrative settings, this is typically manage_options.

   if ( ! current_user_can( 'manage_options' ) ) {
       wp_die( __( 'You do not have sufficient permissions to access this page.' ) );
   }
   

2. Nonce Verification: Use nonces (Number used ONCE) to ensure that the request was intentionally initiated by a legitimate user from a specific administrative interface, preventing Cross-Site Request Forgery (CSRF).

   if ( ! isset( $_POST['my_nonce_field'] ) || ! wp_verify_nonce( $_POST['my_nonce_field'], 'my_action' ) ) {
       wp_die( 'Security check failed' );
   }
   

Defensive Audit Patterns

When auditing WordPress plugins for these issues, security engineers look for:

• Hook Registration: Identifying callbacks registered to admin_init, init, or wp_ajax_.
• Direct Input Processing: Functions that check for $_POST or $_GET parameters and immediately proceed to update_option(), wp_update_post(), or $wpdb->query().
• Lack of Guards: The absence of current_user_can() and check_admin_referer() (or wp_verify_nonce()) before sensitive operations.

For further information on securing WordPress plugins, I recommend reviewing the WordPress Plugin Handbook's security section.