How this vulnerability works (high level, non-exploitative)

Autoptimize is a widely used performance plugin that optimizes assets and can alter markup to implement lazy-loading for images. Lazy-loading delays loading of off-screen images by rewriting the image HTML (for example moving src → data-src, adding loading=”lazy”, or adding placeholders).

The issue fixed in 3.1.15 is a stored XSS vulnerability that allows an authenticated user with Contributor (or higher) privileges to persist payloads inside image attributes used for lazy-loading. Autoptimize’s HTML transformations can move or duplicate attributes (creating data-src/data-srcset or adding inline attributes). If those attributes contain unsanitized content, the content is stored in the database and later rendered to visitors — including editors and administrators who view the infected post.

Stored XSS means the malicious script is persisted server-side and executed in the victim’s browser when they load the page. In this case the payload could reside inside attributes that normally look harmless (alt, title, data-*, srcset, etc.), but the plugin’s rewriting caused those attributes to be interpreted in a way that allowed script execution.

Important context:

• By default, Contributor accounts cannot upload files on many WordPress installations, but attributes can be added to image HTML by editors, custom fields, 3rd-party editors, or modified upload privileges.
• The risk is more than just script execution in visitors’ browsers. Stored XSS can be chained: a contributor can embed code that exfiltrates cookies or tokens from editors/admins who view the post, enabling privilege escalation and persistent compromise.
• Sites with guest authors, multi-author workflows, or weak account hygiene are most exposed.

Real-world impact and attack scenarios

This vulnerability can be leveraged in multiple realistic attack flows:

1. Credential/session theft and account takeover

   A contributor stores an XSS payload in a post. When an editor or admin views the post, the script executes and can exfiltrate cookies or tokens, allowing account takeover.

2. Persistent defacement or ad injection

   JavaScript can rewrite content, inject ads, or redirect visitors to malicious pages.

3. Supply-chain or reputational damage

   Malicious content on a site that syndicates content or serves many users can lead to blacklisting or loss of trust.

4. Malware distribution / drive-by downloads

   XSS can include external malicious scripts that infect visitors or broaden the attack surface.

5. Backdoor planting (post-XSS)

   After stealing admin credentials, attackers may upload PHP backdoors, converting a transient XSS into persistent server-side compromise.

Attackers often obtain contributor-level access via credential stuffing, social engineering, or weak password reuse. On many sites, contributor accounts are an attractive foothold.

Why “low severity” does not mean “ignore it”

Security ratings are useful, but context matters:

• The technical rating may be “low” because the initial actor needs an authenticated Contributor account and modern browsers/content policies reduce some attack vectors.
• In multi-author environments or where contributors are semi-trusted, the practical risk increases.
• Stored XSS gives a persistent foothold that can escalate quickly to full compromise.

Treat this bug as actionable: patch immediately where possible, hunt for indicators, and apply compensating controls until every site is patched.

Immediate actions (operational checklist)

1. Update Autoptimize to 3.1.15 or later immediately. This is the single most important step — the vendor fixed the sanitization and rewriting logic in that release.
2. If you cannot update immediately:
   • Disable lazy-loading in Autoptimize or disable the HTML rewriting that performs lazy-loading transformations.
   • Alternatively, deactivate the plugin until you can patch.
   • Apply generic WAF/edge rules (see the WAF section below) to block obvious exploit payloads.
3. Audit contributor accounts: review all users with Contributor or higher roles; remove or downgrade unknown accounts and force password resets for suspicious users.
4. Search for injected content: hunt for suspicious patterns in posts, pages, custom fields, and media metadata (detection queries below).
5. Scan and clean: use malware scanners and manual inspection to identify injected scripts or unknown files.
6. Rotate secrets and review logs: rotate API keys and tokens that may have been exposed; review server and application logs for suspicious activity.
7. Restore from backup if required: if admin accounts were compromised or files changed, consider restoring from a known-good backup.

Detection and hunting — practical searches

Search the database for suspicious attributes and script-like content. Always backup your database before running queries.

Search for inline event handlers (onerror, onload) in post content:

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%onerror=%'
   OR post_content LIKE '%onload=%'
LIMIT 100;

Search for javascript: usage inside content:

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%javascript:%'
LIMIT 100;

Search for