CVE-2026-4804: Zakra WordPress Theme Stored XSS Vulnerability (Versions ≤4.2.0)

Technical summary

Zakra registers three post meta fields (zakra_menu_item_color, zakra_menu_item_hover_color, zakra_menu_item_active_color) via register_post_meta() with REST API access enabled and an authentication callback that always returns true, but omits the sanitize_callback parameter. While the classic editor applies sanitize_hex_color() during save, the REST API path bypasses this entirely. Retrieved values are concatenated directly into inline CSS via wp_add_inline_style() without output escaping, allowing stored XSS for authenticated attackers at contributor level and above. The vulnerability chain combines insufficient input validation at the API boundary with missing output escaping in the rendering path.

Business impact

Organizations running Zakra-based sites face persistent XSS threats targeting site visitors. Compromised pages can harvest credentials, distribute malware, deface content, or redirect traffic. The attack requires initial compromise of a low-privileged account (contributor), making it a stepping stone in multi-stage intrusions. Unlike reflected XSS, the payload persists across sessions, affecting all visitors until remediated. Sites with public contributor access or weak account hygiene face elevated risk.

Affected systems

Zakra theme for WordPress, all versions through 4.2.0, is affected. The vulnerability requires REST API access (enabled by default in WordPress) and applies to any installation where contributors or higher-privileged users exist. Multisite installations where contributors can edit site options are particularly exposed. The vulnerability does not affect installations with REST API disabled or theme versions after 4.2.0 (pending confirmation of patched versions from the vendor).

Exploitability

Exploitability is moderate. An attacker must obtain contributor-level credentials or higher—achievable through credential compromise, account enumeration on public sites, or social engineering. No additional complexity exists once credentials are obtained; the REST API accepts unsanitized input without additional authentication factors. The attack is reliable and repeatable. However, the requirement for authenticated access prevents unauthenticated exploitation, and many organizations restrict contributor access, reducing real-world exposure in hardened environments.

Remediation

Update the Zakra theme to a patched version released after 4.2.0 that adds sanitize_callback to the meta field registration and applies output escaping to inline CSS. Organizations should verify the patched version number against the official Zakra release notes or vendor advisory before deployment. Interim mitigations include restricting REST API access if operationally feasible, disabling contributor-level permissions for untrusted users, or implementing Web Application Firewall rules to block REST API calls modifying these specific meta fields.

Patch guidance

Verify availability of a patched Zakra version beyond 4.2.0 in the official WordPress theme repository or vendor advisory. Apply updates through the WordPress admin dashboard or command line (e.g., wp theme update zakra). Test patched versions in a staging environment to confirm color settings render correctly and no functionality regresses. After deployment, audit post meta tables for suspicious hex values or encoded payloads injected during the vulnerability window. Consider reviewing contributor account activity logs during the exposure period.

Detection guidance

Monitor REST API POST/PUT requests to /wp-json/wp/v2/posts with meta parameters zakra_menu_item_color, zakra_menu_item_hover_color, or zakra_menu_item_active_color containing non-standard hex values (e.g., script tags, event handlers, or obfuscated JavaScript). Audit post meta values in the database for anomalies using queries filtering for these three fields. Review contributor account creation and permission grants. Implement log-based detection on wp_add_inline_style() calls that output suspicious CSS containing script references or event bindings. SIEM rules should flag REST API calls from unfamiliar IP addresses or user agents modifying theme-related meta fields.

Why prioritize this

While CVSS 6.4 (medium) reflects the authenticated requirement, organizational risk varies. This vulnerability warrants high priority for sites with public contributor registration, weak access controls, or high visitor traffic. For hardened environments with strict contributor management, priority is lower but still warrants patching within normal update cycles. The persistent nature of stored XSS and potential for large-scale visitor impact elevate practical risk beyond the base CVSS score.

Risk score, explained

CVSS 6.4 reflects: Low attack complexity (network-based REST API, no special conditions), requirement for low privileges (contributor access), scope change (attacks affect other users), and confidentiality/integrity impact (session compromise, page defacement). Lack of availability impact prevents higher severity. The score appropriately penalizes the authenticated requirement but does not account for deployment-specific factors (contributor access prevalence, visitor count, sensitivity of site data). Organizations should calibrate remediation urgency based on their actual attack surface and user populations.

Frequently asked questions