Answer in brief
CVE-2026-4804 records a Medium severity (CVSS 6.4) vulnerability in Zakra <= 4.2.0 - Authenticated (Contributor+) Stored Cross-Site Scripting via Post Meta REST API. The current sources do not mark it as known exploited. The current feed maps themegrill/Zakra (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 6.4. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps themegrill/Zakra (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| themegrill/Zakrageneric | 0 | Not reported |
Published upstream
Jul 3, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jul 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 3, 2026
The Zakra theme for WordPress is vulnerable to Stored Cross-Site Scripting via post meta values in all versions up to, and including, 4.2.0. This is due to the theme registering three post meta fields (zakra_menu_item_color, zakra_menu_item_hover_color, and zakra_menu_item_active_color) with 'show_in_rest' => true and 'auth_callback' => '__return_true', but without any sanitize_callback parameter in the register_post_meta() calls. While the classic editor save path applies sanitize_hex_color() sanitization, the REST API path completely bypasses this protection. The unsanitized meta values are then retrieved via get_post_meta() and concatenated directly into CSS strings that are output through wp_add_inline_style() without any escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the injected page.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-4804 records a Medium severity (CVSS 6.4) vulnerability in Zakra <= 4.2.0 - Authenticated (Contributor+) Stored Cross-Site Scripting via Post Meta REST API. The current sources do not mark it as known exploited. The current feed maps themegrill/Zakra (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 6.4. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps themegrill/Zakra (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| themegrill/Zakrageneric | 0 | Not reported |
Published upstream
Jul 3, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jul 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 3, 2026
The Zakra theme for WordPress is vulnerable to Stored Cross-Site Scripting via post meta values in all versions up to, and including, 4.2.0. This is due to the theme registering three post meta fields (zakra_menu_item_color, zakra_menu_item_hover_color, and zakra_menu_item_active_color) with 'show_in_rest' => true and 'auth_callback' => '__return_true', but without any sanitize_callback parameter in the register_post_meta() calls. While the classic editor save path applies sanitize_hex_color() sanitization, the REST API path completely bypasses this protection. The unsanitized meta values are then retrieved via get_post_meta() and concatenated directly into CSS strings that are output through wp_add_inline_style() without any escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the injected page.
Quoted source text, attributed separately from HOL analysis.