Form Maker 10Web CVE-2026-15993

Exploitation requires three simultaneous conditions: (1) The attacker must hold an authenticated WordPress account with at minimum subscriber-level privileges - unauthenticated exploitation is not possible per the PR:L CVSS metric. (2) The target site must have at least one form configured with a database-backed dynamic choice field whose WHERE clause template explicitly includes the {username} placeholder - this is a non-default, administrator-configured feature that is not present in standard plugin installations. (3) The attacker must be able to edit their WordPress profile display_name, which is standard for any authenticated user. Exploitation is strictly limited to network-accessible WordPress sites running the affected plugin versions. Sites without the specific {username} WHERE clause configuration are entirely unexploitable regardless of plugin version or authentication state. Mass automated exploitation is unlikely given the requirement to first identify a qualifying form configuration on each target site.

The CVSS 5.3 medium score is primarily driven by AC:H, which accurately reflects the genuinely constrained exploitation preconditions. Despite the high confidentiality impact (C:H - full database read), the attack complexity arises from a compounding of requirements: subscriber-level authentication, a site-specific non-default form configuration, and a two-stage setup (profile poisoning then AJAX trigger). The vulnerability is not listed in CISA KEV, and no public exploit code has been identified at time of analysis; EPSS data was not provided in the source intelligence. The realistic risk is concentrated at multi-user or membership WordPress sites that have both open subscriber registration and at least one form with a DB-backed dynamic choice field whose WHERE template references {username} - a niche but not implausible deployment pattern. For sites lacking that specific form configuration, the vulnerability is entirely unexploitable regardless of plugin version. The discrepancy between the high CVSS confidentiality impact and the medium overall score is well-founded and not an anomaly.

An attacker with a subscriber-level account on a target WordPress site navigates to their profile and sets their display_name to a time-based or boolean blind SQL injection payload. They then identify or know of a form on the site that uses a database-backed dynamic choice field with a WHERE clause template referencing {username}, and send a crafted POST request to the fm_reload_input AJAX endpoint referencing that form and field. The backend substitutes the attacker's display_name into the WHERE clause without sanitization, executing the injected SQL, which allows the attacker to iteratively extract the contents of the WordPress database - including wp_users credential hashes and any sensitive form submission data - through blind inference techniques. No public exploit code has been identified at time of analysis.