WP Security CheckVulnerability data as of November 8, 2026

Vulnerability alerts / November 7, 2026

Vulnerability in WP Data Access – App Builder for Tables, Forms, Charts, Maps & Dashboards — CVE-2026-118267

HighSeverity
CVSS 8.1
—Estimated exploit probability
EPSS
10,000+ sitesInstalls
5.5.90Fixed in

What to do now

Update WP Data Access – App Builder for Tables, Forms, Charts, Maps & Dashboards to 5.5.90 or later.

Affected versions

  • Everything up to and including 5.5.89

Affected: WP Data Access – App Builder for Tables, Forms, Charts, Maps & Dashboards (plugin, wp-data-access)

Check: The plugin on wordpress.org / Our record for WP Data Access – App Builder for Tables, Forms, Charts, Maps & Dashboards

What the vulnerability is

The WP Data Access – App Builder for Tables, Forms, Dashboards, Charts & Maps plugin for WordPress is vulnerable to Incorrect Authorization leading to Privilege Escalation in all versions up to, and including, 5.5.89 This is due to the plugin's write endpoints (`wpda/app/update`, `wpda/app/delete`, `wpda/app/insert`) passing the attacker-supplied `key` and `val` parameters directly to `$wpdadb->update`, `$wpdadb->delete`, and `$wpdadb->insert` without enforcing the container's row-filter (`defaultWhere`) or per-column allow-list (`isSelected`) restrictions that are correctly applied on the read endpoints. This makes it possible for authenticated attackers, with Subscriber-level access and above, to write to arbitrary rows and columns outside the configured restrictions — including overwriting the `user_pass` field of the WordPress administrator account in `wp_users` — and subsequently authenticate as the administrator, achieving full site takeover. Exploitation requires an administrator to have published a Data App that enables write transactions (update, delete, or insert) for Subscriber-level or anonymous users, which is an explicitly advertised use-case of the plugin. Exploitation by unauthenticated attackers requires that the administrator has published a Data App whose rest_api.authorization is 'anonymous' and whose container has transactions.update (or delete/insert) enabled. On a default installation, where that is not configured, the vulnerability requires attackers with subscriber-level access and above.

This description is reproduced verbatim from the public vulnerability record.

Sources

See other alerts