The core issue: this plugin exposes a centralized metadata reading capability through WordPress AJAX without any capability verification. Any authenticated user—down to Subscriber role—can query the AJAX endpoint and pull data from any user, post, or term the plugin touches. The absence of current_user_can() isn't an oversight in isolation; it's a structural pattern that WordPress's AJAX architecture incentivizes. AJAX handlers have no default authorization enforcement, so developers must remember to add capability checks to every endpoint. The secure path requires explicit action; the insecure path is the default.
What to check: Review your installed plugins for registered AJAX actions (add_action('wp_ajax_', ...) and wp_ajax_nopriv_) and verify each one contains a capability check. Pay special attention to plugins functioning as centralized data aggregators—admin column plugins, reporting tools, metadata exporters—as their purpose often means they can access everything.
What to do: Prioritize patching plugins with this pattern, even when CVSS scores appear moderate (6.5 here). The horizontal access vector—compromising one account to extract data from any user or post—creates compounding risk across the install base. This isn't a single vulnerability; it's a repeatable exploitation pathway that scales with plugin count.
What to watch: Exploitation requires an authenticated session, so account security matters. In setups with open registration or compromised credentials, this becomes a pivot point for lateral movement. The pattern is well-documented but keeps recurring because the WordPress AJAX model makes the insecure path the path of least resistance.