Description

The Metasync plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the save_instant_indexing_settings() function in versions up to, and including, 2.6.23. This function is registered on the admin_init hook and only checks for the presence of $_POST['submit'] before writing attacker-supplied $_POST['metasync_post_types'] into the site-wide 'metasync_options_instant_indexing' option via update_option(); no current_user_can()/current_user_has_plugin_access() check and no nonce verification are performed. This makes it possible for authenticated attackers, with Subscriber-level access and above, to modify the site's Google Instant Indexing post-type configuration, controlling which post types are auto-submitted to Google's Instant Indexing service.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-19T08:16:53.063Z",
  "pubdate": "2026-09-19T08:16:53.063Z",
  "executiveSummary": "The Metasync plugin for WordPress, in versions up to and including 2.6.23, is susceptible to an unauthorized data modification vulnerability. This security flaw stems from a critical lack of authorization and integrity checks within the plugin's configuration save mechanism.\nThe vulnerability resides in the save_instant_indexing_settings() function, which handles the update of Google Instant Indexing settings. Because the function fails to perform capability checks or validate nonces, any authenticated user—including those with low-privileged Subscriber accounts—can manipulate these site-wide settings.\nBy successfully exploiting this vulnerability, an attacker can influence the behavior of the plugin by altering which post types are automatically submitted to Google's Instant Indexing service. This allows an unauthorized party to manipulate search engine indexing behavior for the affected site.\nThe risk implication is significant as it permits unauthorized administrative configuration changes without requiring elevated privileges. There is no requirement for complex social engineering; a standard authenticated WordPress account is sufficient to trigger the malicious update via a crafted request.",
  "technicalDetails": "The root cause of this vulnerability is improper access control within the Metasync plugin's administrative functionality. Specifically, the save_instant_indexing_settings() function, registered via the admin_init hook, performs a superficial check for the existence of the $_POST['submit'] parameter but fails to verify the current user's authorization level using current_user_can() or equivalent WordPress security functions.\nFurthermore, the implementation lacks a mandatory CSRF (Cross-Site Request Forgery) protection mechanism; no nonce verification is conducted before the plugin processes incoming POST data. Consequently, the function proceeds to read the user-supplied $_POST['metasync_post_types'] array and stores it directly into the WordPress options table under the key 'metasync_options_instant_indexing' using the update_option() function.\nThe attack flow proceeds as follows: An authenticated attacker, possessing at minimum Subscriber-level credentials, crafts an HTTP POST request targeted at the WordPress dashboard environment where admin_init actions are processed. The request must include the 'submit' parameter required by the vulnerable function and the 'metasync_post_types' parameter containing the desired payload. Because the server-side code performs no authorization check, it accepts the attacker-controlled array and overwrites the existing site-wide configuration stored in the database.\nThe impact of this exploit is the unauthorized modification of plugin behavior. An attacker can effectively force the plugin to submit unintended content or sensitive internal post types to Google's Instant Indexing service, potentially causing unwanted search engine visibility or altering the intended SEO strategy of the site owner. Because the change is persistent, the configuration remains modified until manually corrected by an authorized administrator. The vulnerability is present in all versions up to and including 2.6.23, and it remains reachable over the network to any user with a valid login session on the WordPress instance."
}