Login

Tag Archives: tagDiv Composer

19 Oct 2023

How to Disable Access to Exploitation Path for Vulnerable Code in Outdated tagDiv Composer Plugin

On Monday, we discussed testing we did to see what WordPress firewall plugins were able to protect against a fixed vulnerability that has been exploited in the WordPress plugin tagDiv Composer. We also noted that the best solution was to update the plugin to the latest version, as this was fixed before the exploitation was happening. We subsequently had a new customer for our service contact us who mentioned they were unable to update things, as updating a connected theme was causing the website to break. With most WordPress plugin vulnerabilities, it is relatively easy to patch the code enough to stop exploitation of the vulnerability. That is true for this vulnerability, as we found when we looked into providing them such a patch.

A proof of concept for the vulnerability shows, the exploitation happens through the REST API route /tdw/save_css. At least in the version being used by our customer, 2.7, the relevant code for that route exists in the plugin’s file /css-live/includes/td_live_css_ajax.php. The registration for the route occurs in the function td_live_css_on_rest_api_init(): [Read more]

16 Oct 2023

3 WordPress Firewall Plugins Stop Recent Widely Exploit Vulnerability in tagDiv Composer Plugin

Last week there were a spate of largely unhelpful new stories run about websites getting hacked through an already fixed vulnerability in a WordPress plugin not available through the WordPress Plugin Directory, tagDiv Composer. There is a lot that could be discussed with that, but one element stands out to us. It looked like exploitation of the vulnerability should be easily stopped by WordPress security plugins with a firewall. We say that based on our own experience developing such a firewall plugin. That runs counter to something said by Dan Goodin, who inexplicable continues to be employed by Ars Technica, despite repeatedly getting things wrong in his stories. He wrote this:

The malicious injection uses obfuscated code to make it hard to detect. It can be found in the database used by WordPress sites, specifically in the “td_live_css_local_storage” option of the wp_options table. [Read more]