CVE-2024-25600: Critical Unauthenticated RCE in the Bricks Builder Theme (25,000+ Sites)

In February 2024, researchers disclosed one of the most serious WordPress vulnerabilities of the year: a flaw in the popular Bricks Builder theme that let anyone — with no login, no account, and no special access — run their own code on the server. Tracked as CVE-2024-25600 and rated a near-maximum CVSS score of 9.8, the bug turned a single web request into a full site takeover. Within roughly a day of the patch becoming public, attackers were already scanning the internet for vulnerable sites.

Bricks (commonly called Bricks Builder) is a premium visual site-building theme used on an estimated 25,000 WordPress sites. If you build or manage a site with Bricks, this is a vulnerability worth understanding — both for the damage it caused and for what it teaches about how WordPress code-execution flaws happen in the first place.

CVE Details

• CVE ID: CVE-2024-25600
• Affected software: Bricks Builder, a premium WordPress site-building theme
• Vulnerability type: Unauthenticated Remote Code Execution (RCE)
• CVSS score: 9.8 (Critical)
• Affected versions: All versions up to and including 1.9.6
• Patched version: 1.9.6.1, released February 13, 2024
• Discovered by: a researcher known as “snicco,” reported February 10, 2024
• Exploited in the wild: Yes — active attacks observed from February 14, 2024

The “unauthenticated” label is what makes this so dangerous. Many WordPress vulnerabilities require an attacker to already hold some level of access, such as a subscriber or contributor account. This one required nothing at all — any anonymous visitor on the internet could attempt it.

How the vulnerability works

Bricks lets site builders create dynamic content by configuring small pieces of query logic that get processed on the server. To handle this, a function deep inside the theme — prepare_query_vars_from_settings — passed user-controllable input into PHP’s eval() function. eval() takes a string of text and runs it as live PHP code. That is exactly as dangerous as it sounds: if an attacker can influence the string, they can run whatever code they want.

Bricks did not leave this completely open. The code path that reached eval() sat behind a REST API endpoint protected by a nonce — a security token WordPress uses to verify that a request is legitimate. In theory, only trusted users should ever hold a valid nonce.

The problem was that Bricks printed a valid nonce directly into the HTML of every page, where any visitor — including an unauthenticated attacker — could simply read it. With that token in hand, an attacker could call the protected endpoint, slip a malicious payload into the query settings, and have the server execute it through eval(). A security check that was supposed to gate access wasn’t actually keeping anyone out, and behind that broken gate sat a function that would run whatever code it was handed.

There is an important lesson buried in this design. A nonce is meant to prevent cross-site request forgery — tricking a logged-in user’s browser into making a request — not to decide who is allowed to perform an action. Treating a publicly visible token as if it were a password is a recurring mistake in web security, and it’s exactly what turned a builder feature into a remote code-execution hole.

Real-world impact

Remote code execution is the most severe outcome a web vulnerability can have, because once an attacker can run code on your server, they effectively own the site. With CVE-2024-25600, a successful attacker could:

• Create hidden administrator accounts to retain access even after the bug is patched
• Install backdoors and web shells for persistent control of the server
• Steal database contents, including customer data and password hashes
• Deface the site or inject spam, malware, and malicious redirects that harm visitors
• Use the compromised server to attack other sites or send spam

Security firms observed real malware built specifically for this flaw. Notably, some of the malicious code tried to disable competing security plugins such as Wordfence and Sucuri, and even removed rival malware, so the attacker could keep exclusive control of the compromised site. Because exploitation began so quickly after disclosure — within roughly 24 hours — many site owners were attacked before they had a chance to update.

How to check if you’re affected

You are potentially affected if your site uses the Bricks theme at version 1.9.6 or earlier. To check your version:

• Log in to your WordPress dashboard and go to Appearance > Themes. Bricks will appear here if it is installed or active.
• Click the Bricks theme to view its details, including the version number.
• Alternatively, open wp-content/themes/bricks/style.css over FTP or your host’s file manager and read the Version: line near the top.

If the version is 1.9.6.1 or higher, you already have the fix. If it is 1.9.6 or lower, treat the site as urgently at risk. Because this flaw was exploited so widely, an unpatched site that has been online should also be checked for signs of compromise: unexpected administrator accounts, unfamiliar files in your uploads or themes folders, and unexplained changes to your content or settings.

How to fix it

The fix is straightforward, and you should apply it immediately:

• Update Bricks to 1.9.6.1 or later. You can update from Appearance > Themes, or download the latest version from your Bricks account and upload it.
• If you cannot update right away, take the site offline or restrict access until you can. An unpatched, internet-facing Bricks site is an active target.
• Scan for compromise. If your site ran a vulnerable version while exposed, use a reputable malware scanner and review user accounts, scheduled tasks (WP-Cron), and recently modified files.
• Rotate your secrets after cleanup. If you find evidence of a breach, change all passwords, regenerate the WordPress security keys (salts) in wp-config.php, and review any API keys stored on the site.

A few hardening habits reduce the blast radius of bugs like this in the future: keep automatic updates enabled where you can, put a web application firewall (WAF) in front of your site to block known exploit patterns during the dangerous window before you patch, and keep the number of administrator accounts to a minimum.

Takeaway

CVE-2024-25600 is a textbook example of why WordPress security can’t stop at “I only install reputable software.” Bricks is a well-regarded commercial product, and it still shipped a critical flaw — one that combined a dangerous function (eval()) with a security check that didn’t check the right thing. The sites that came through unscathed weren’t lucky; they were the ones that updated quickly and had layered defenses already in place.

The practical lesson is the one good WordPress hygiene always returns to: patch fast, especially for anything that processes requests from the public internet; don’t assume that premium or popular means safe; and run a security layer that can buy you time during the window between a vulnerability going public and your next update. When the gap between disclosure and mass exploitation is measured in hours, those habits are what keep your site standing.