WP Data Access (<= 5.5.63) — Stored XSS via wpda_app Shortcode (CVE-2026-0557)

By: Hong Kong Security Expert — WordPress vulnerability advisory and response guide

On 13 February 2026 a stored cross-site scripting (XSS) vulnerability affecting the WP Data Access plugin was disclosed. The issue (CVE-2026-0557) affects WP Data Access versions up to and including 5.5.63 and permits an authenticated user with Contributor (or higher) privileges to store JavaScript payloads through the plugin’s wpda_app shortcode. The vendor released a fix in version 5.5.64.

This advisory is written from the perspective of a Hong Kong security practitioner. It contains a technical explanation of the risk, realistic exploitation scenarios, detection and mitigation steps, short- and long-term remediation guidance, and recommended defensive rules to reduce exposure while you update.

Summary at a glance

• Vulnerability: Authenticated (Contributor+) stored XSS in wpda_app shortcode
• Affected versions: <= 5.5.63
• Fixed in: 5.5.64
• CVE: CVE-2026-0557
• Risk level: Medium (Patch priority: low to medium; CVSS: 6.5)
• Immediate mitigation: Update to 5.5.64. If update is not possible, remove/override the shortcode and apply WAF rules.

Why this is important — context for WordPress site owners

Stored XSS means a payload is saved on the server (in a post, page, or plugin data) and later delivered to other users in an unsafe, executable form. In WordPress, stored XSS is especially dangerous because:

• Malicious JavaScript can run in the context of an administrator’s browser and steal session cookies, perform actions on behalf of the admin, or load additional payloads.
• Even if the contributor role cannot publish directly, contributors can create content that an editor or admin will view, or content can be rendered on the front-end where visitors — including administrators who browse the site — will trigger the payload.
• Scripts can chain into privilege escalation, persistent defacement, backdoor installation, or site-wide compromise.

Although contributors are low-privileged compared to administrators, the stored XSS here enables a low-privileged account to inject content with effects that may reach higher-privileged users. That makes the vulnerability more serious than it might appear at first glance.

How the vulnerability works (technical, non-exploitative)

The vulnerable WP Data Access shortcode (wpda_app) accepts attributes or content that are later output on pages without proper sanitization or encoding. An attacker with contributor privileges can submit a crafted shortcode value (for example, by adding it to a post or custom content area). When the shortcode rendering function outputs the stored data directly into a page or the admin UI, the browser interprets it as HTML/JavaScript and executes it.

Key conditions for exploitation

• The plugin is installed and active on the site.
• The wpda_app shortcode is available and used (or the plugin stores data that is later rendered via that shortcode).
• The attacker has an account at Contributor level or higher.
• A target (admin/editor or other site user) views the page or admin area where the payload is rendered.

Because the attack saves a persistent payload in the database, it can affect anyone who later loads the page, including administrators. The payload can execute without additional interaction beyond viewing the page (although some attacks may require social engineering).

Realistic attack scenarios

1. Contributor writes a post containing the vulnerable shortcode populated with malicious input. An Editor or Administrator previews or edits the entry in the admin area; the payload executes in the admin’s browser and can attempt to:
   • Exfiltrate cookies or session tokens.
   • Trigger administrative actions via forged requests.
   • Inject further content or trigger a file upload flow.
2. Contributor uses a plugin-managed app page (rendered by wpda_app) to inject code that executes on the public front-end. Visitors (and administrators browsing the site) trigger the script, which can redirect users, display phishing overlays, or try to load additional malware.
3. The payload writes content to other posts or creates a new page (if combined with another vulnerability or misconfigured capability escalation), leading to broader persistence.

Immediate actions (what to do right now)

If the WP Data Access plugin is installed on any of your sites, follow these steps immediately:

1. Update the plugin to version 5.5.64 or later.

   This is the simplest and preferred fix. Apply the update on staging first, then production.

2. If you cannot update immediately, temporarily disable the plugin or remove the affected shortcode:

   From the WordPress admin: Plugins → Installed Plugins → Deactivate WP Data Access.

   If you cannot deactivate, remove or override the shortcode registration via a small custom snippet (example below).

3. Restrict contributor activity temporarily:
   • Require review for contributor posts. Remove contributor accounts you do not recognize.
   • Consider changing the contributor role to require approval before preview by higher privileged users.
4. Use your WAF (Web Application Firewall) to block obvious attempts:

   Apply rule(s) that block requests containing script tags or suspicious payloads in shortcode parameters or POST bodies where wpda_app appears.

5. Scan the site for stored payloads and malware:

   Run malware scanner and grep for occurrences of the wpda_app shortcode in posts, pages, and postmeta.

6. Rotate admin sessions and credentials if you suspect compromise:

   Reset administrator passwords, revoke sessions (log out all users), and rotate API keys.

Quick detection checklist (how to find suspicious content)

Search content for the shortcode and for embedded script-related strings. WP-CLI examples (run from your host shell — make backups first):

wp post list --post_type='post,page' --format=ids | \
xargs -n1 -I% wp post get % --field=post_content | \
grep -n "\[wpda_app"

wp db query "SELECT ID,post_title FROM wp_posts WHERE post_content LIKE '%[wpda_app%';"

wp db query "SELECT ID,post_title FROM wp_posts WHERE post_content LIKE '%

 $v ) {
            $safe_atts[ sanitize_key( $k ) ] = sanitize_text_field( $v );
        }

        // If the original shortcode may output complex content, return a safe placeholder
        // or render only the allowed, sanitized attributes.
        $output = '
';
        $output .= '';
        $output .= '
';

        return $output;
    } );
}, 9 );