Optimole WordPress Plugin CVE-2026-5217: Brief Summary of Unauthenticated Stored XSS via Srcset Descriptor

Introduction

A stored cross-site scripting vulnerability in the Optimole WordPress plugin lets unauthenticated attackers inject persistent JavaScript payloads into any page that renders optimized images. The plugin has over 200,000 active WordPress installations. The plugin does protect the endpoint with an HMAC-based check, but it leaks the required tokens directly in the frontend HTML, so anyone who can load a page on the site can make valid API calls.

Optimole is a popular WordPress plugin for real-time image optimization, automatic WebP and AVIF conversion, CDN delivery, and lazy loading. It has over 200,000 active installations and nearly 8 million total downloads. A security flaw in a plugin this widely deployed immediately becomes a high-value target for automated exploitation campaigns.

Technical Information

The Unauthenticated Endpoint

The vulnerability lives in the /wp-json/optimole/v1/optimizations REST endpoint, registered in rest.php. The endpoint's permission callback is set to __return_true, which means WordPress does not enforce any authentication on incoming requests. The developers instead implemented their own authorization scheme using an HMAC signature and a timestamp. The critical design flaw is that both the HMAC signature and the timestamp are embedded directly in the frontend HTML of every page that uses Optimole. Any visitor can view the page source, extract these values, and use them to construct fully valid API requests.

Sanitization Gap in sanitize_text_field()

The endpoint accepts a user-supplied s parameter that functions as a srcset descriptor. On line 1008 of rest.php, the plugin sanitizes this input with WordPress's sanitize_text_field() function. This function strips HTML tags and removes extra whitespace, but it does not escape double quote characters. That gap is what makes the attack possible. A payload containing double quotes passes through the sanitization step completely intact.

Storage and Retrieval: The Stored XSS Chain

After sanitization, the plugin stores the descriptor value in WordPress transients, which are backed by the wp_options database table. The payload now persists in the database.

When any user visits a page where Optimole renders images, tag_replacer.php (around line 526) retrieves the stored descriptor and injects it directly into the srcset attribute of an <img> tag. The plugin applies no output escaping at this stage. Because the double quotes were never neutralized, the attacker's payload breaks out of the srcset attribute and can introduce arbitrary HTML attributes, including JavaScript event handlers like onload or onerror.

Step-by-Step Attack Flow

1. The attacker visits a target WordPress site running a vulnerable version of Optimole and extracts the HMAC signature and timestamp from the page's HTML source.
2. Using the extracted tokens, the attacker sends a crafted POST request to /wp-json/optimole/v1/optimizations with a malicious s parameter. The value contains double quotes designed to break out of the srcset attribute, followed by a JavaScript event handler.
3. The endpoint validates the HMAC, which succeeds because the attacker used real tokens, then passes the descriptor through sanitize_text_field(). HTML tags are stripped, but the double quotes remain.
4. The plugin stores the poisoned descriptor as a WordPress transient in the wp_options table.
5. When any user, including a site administrator, loads a page where Optimole renders images, tag_replacer.php retrieves the stored descriptor and injects it verbatim into the srcset attribute. The double quotes break the attribute boundary, and the injected JavaScript executes in the victim's browser session.

The whole chain is unauthenticated and needs no user interaction on the injection side. The payload persists across page loads and affects every visitor to the compromised page.

Affected Systems and Versions

All versions of the Optimole plugin (also known as "Optimole – Optimize Images | Convert WebP & AVIF | CDN & Lazy Load | Image Optimization") up to and including version 4.2.2 are affected by CVE-2026-5217.

The vulnerability is fixed in version 4.2.3. However, version 4.2.3 introduced a separate Reflected XSS vulnerability (CVE-2026-5226), so the recommended minimum safe version is 4.2.4.

Any WordPress site with the optimole-wp plugin installed at version 4.2.2 or earlier is vulnerable, regardless of WordPress core version or hosting configuration.

Vendor Security History

The vendor, Codeinwp, responded quickly to the disclosure of CVE-2026-5217. Version 4.2.3 was released on April 1, 2026, with commit messages explicitly referencing "fix: prevent cross site scripting" and "Enhance security." Two days later, on April 3, 2026, Codeinwp released version 4.2.4 to fix CVE-2026-5226, a Reflected XSS vulnerability in the page profiler URL that shipped in the 4.2.3 release.

Two XSS vulnerabilities in adjacent releases show how hard it is to fully secure REST API endpoints in WordPress plugins, even for an actively maintained project with a large user base.

References

• NVD Entry for CVE-2026-5217
• Wordfence Threat Intel: Optimole <= 4.2.2 Unauthenticated Stored XSS
• Wordfence Threat Intel: Optimole <= 4.2.2 Stored XSS via Srcset Descriptor
• Wordfence Threat Intel: Optimole <= 4.2.3 Reflected XSS (CVE-2026-5226)
• Wordfence: Optimole Plugin Vulnerability History
• rest.php (tag 4.2.1, line 159) in WordPress Plugin Repository
• rest.php (tag 4.2.1, line 1008) in WordPress Plugin Repository
• tag_replacer.php (tag 4.2.1, line 526) in WordPress Plugin Repository
• rest.php (trunk, line 159) in WordPress Plugin Repository
• rest.php (trunk, line 1008) in WordPress Plugin Repository
• tag_replacer.php (trunk, line 526) in WordPress Plugin Repository
• Optimole Plugin on WordPress.org
• GitHub Release v4.2.3
• GitHub Diff v4.2.2 to v4.2.3
• Optimole Changelog