PHP EUVD-2026-20840

The CVSS 4.3 score reflects a low-severity remote vulnerability requiring low-privileged authentication (PR:L), no user interaction, and network accessibility (AV:N/AC:L). Exploitation probability is moderate: while the attack requires valid subscriber-level credentials, such accounts are common in WordPress communities and shops. The real-world impact depends on site configuration-legacy privilege escalation via wp_user_level is only relevant if the site or plugins use that deprecated field for authorization checks; modern WordPress relies on wp_capabilities (serialized array), which this vector cannot directly exploit. However, plugin-specific meta keys present a real escalation risk if used for authorization decisions (common in membership and access-control plugins). Stored XSS through unsanitized billing fields could compromise admin accounts if admins view user profiles. The combination of low CVSS, authenticated-only access vector, and impact variability suggests this is a medium-priority issue for WordPress sites using MStore API with plugins that depend on meta-key-based authorization, but lower priority for sites with modern, capability-based access controls. The lack of public exploit code and active exploitation signals further reduces immediate risk, though the straightforward nature of the vulnerability (direct JSON injection to meta update) means exploit development would be trivial.

An attacker with valid subscriber-level credentials logs into a WordPress site using MStore API ≤ 4.18.3 and makes an authenticated POST request to the update_user_profile() endpoint with a JSON payload containing meta_data fields such as wp_user_level set to 10 (admin equivalent) or plugin-specific authorization keys. The endpoint processes this JSON without validation and updates the attacker's own user meta fields in the database. If the site or plugins check wp_user_level for legacy privilege decisions, or if plugin-specific meta keys control feature access, the attacker gains elevated privileges. Alternatively, the attacker could inject malicious HTML or JavaScript into a sanitized-but-stored billing field, which would execute when administrators view the user's profile in wp-admin. No public proof-of-concept exploit code has been published as of the analysis date.