CVE-2026-4805: Woostify WordPress Plugin XSS Vulnerability

CVE-2026-4805 Overview

The Woostify plugin for WordPress contains a Stored Cross-Site Scripting (XSS) vulnerability in versions up to and including 2.5.0. This security flaw exists due to insufficient input sanitization and output escaping in the bundled Lity.js lightbox library. The vulnerability occurs when user-controlled input from the href attribute is concatenated directly into a jQuery HTML string without proper sanitization, allowing authenticated attackers with Contributor-level access or above to inject arbitrary web scripts into pages that execute whenever a user accesses an injected page.

Critical Impact

Authenticated attackers can inject malicious scripts that persist on WordPress pages, potentially leading to session hijacking, credential theft, and further compromise of the WordPress installation.

Affected Products

• Woostify WordPress Plugin versions up to and including 2.5.0
• WordPress installations using the vulnerable Lity.js lightbox library bundled with Woostify
• Sites with Contributor-level or higher user access enabled

Discovery Timeline

• April 28, 2026 - CVE-2026-4805 published to NVD
• April 28, 2026 - Last updated in NVD database

Technical Details for CVE-2026-4805

Vulnerability Analysis

This Stored Cross-Site Scripting vulnerability resides in the Lity.js lightbox library bundled with the Woostify WordPress plugin. The root issue stems from improper handling of user-supplied data in the href attribute, which is passed directly into jQuery HTML construction methods without adequate sanitization or encoding. When an authenticated user with at least Contributor-level privileges crafts a malicious link containing JavaScript code in the href attribute, this code gets stored in the WordPress database and subsequently rendered unsanitized on the frontend.

The attack requires authentication with at least Contributor-level access, which limits the immediate threat surface. However, once exploited, the injected scripts persist and execute for all visitors to the affected page, including administrators. This creates opportunities for privilege escalation, session token theft, and further malicious activities.

Root Cause

The vulnerability is caused by insufficient input sanitization and output escaping in the Lity.js lightbox library. Specifically, user-controlled input from the href attribute is concatenated directly into a jQuery HTML string without sanitization at multiple code locations including line 142, line 163, line 611, and line 635 of the vulnerable Lity.js file. This allows attackers to break out of the intended HTML context and inject arbitrary JavaScript code.

Attack Vector

The attack is conducted over the network and requires authenticated access with Contributor-level privileges or higher. An attacker can create or edit content containing a specially crafted link with malicious JavaScript in the href attribute. When the Lity.js lightbox processes this link, the unsanitized input is rendered in the page context, causing the malicious script to execute for any user who views the page. This includes administrators, making session hijacking and privilege escalation viable attack outcomes.

The vulnerability mechanism involves the following flow:

1. An authenticated attacker with Contributor access creates content with a malicious href attribute
2. The Lity.js library processes the link without proper sanitization
3. User-controlled input is directly concatenated into jQuery HTML strings
4. When any user views the page, the injected JavaScript executes in their browser context

For technical implementation details, see the GitHub Commit Details and the Wordfence Vulnerability Report.

Detection Methods for CVE-2026-4805

Indicators of Compromise

• Unusual or obfuscated JavaScript code in post content, particularly within href attributes
• Unexpected network requests to external domains originating from WordPress pages
• Cookie or session token exfiltration attempts in server logs or browser network activity
• Modified content in the WordPress database containing script tags or event handlers

Detection Strategies

• Monitor WordPress content for href attributes containing JavaScript event handlers or script injections
• Implement Content Security Policy (CSP) headers to detect and block inline script execution
• Review user activity logs for Contributors and Authors creating suspicious content
• Use WordPress security plugins to scan for stored XSS patterns in database content

Monitoring Recommendations

• Enable detailed logging for content creation and modification by users with Contributor-level access
• Configure web application firewalls (WAF) to alert on potential XSS payload patterns in POST requests
• Monitor client-side errors and unexpected script executions using browser telemetry
• Set up alerts for unusual outbound connections from WordPress frontend pages

How to Mitigate CVE-2026-4805

Immediate Actions Required

• Update the Woostify plugin to version 2.5.1 or later immediately
• Review and audit all content created by users with Contributor-level access for malicious scripts
• Consider temporarily restricting Contributor publishing capabilities until the patch is applied
• Implement Content Security Policy headers to mitigate the impact of any undetected stored XSS

Patch Information

The vulnerability has been addressed in Woostify version 2.5.1. The patch implements proper input sanitization and output escaping for the href attribute in the Lity.js lightbox library. Users should update immediately through the WordPress admin panel or by downloading the latest version from the WordPress theme repository. The specific changes can be reviewed in the WordPress Changeset 2.5.0 to 2.5.1.

Workarounds

• Restrict user registration and limit Contributor-level access to trusted users only
• Implement a Web Application Firewall (WAF) rule to filter potential XSS payloads in content submissions
• Disable the Lity.js lightbox functionality temporarily if not critical to site operation
• Enable WordPress multisite network restrictions for content containing potentially dangerous HTML

# Add Content Security Policy header in .htaccess as a mitigation measure
<IfModule mod_headers.c>
    Header set Content-Security-Policy "script-src 'self'; object-src 'none';"
</IfModule>