Yesterday, data we track showed that what was likely a hacker was probing for usage of the 100,000+ install WordPress plugin TI WooCommerce Wishlist, by requesting its readme.txt file. Why would a hacker be interested in the plugin? Presumably there shouldn’t be any publicly known unfixed vulnerabilities, as the plugin hasn’t been closed in the WordPress plugin directory:
Today, we have had two requests on our website checking if we were using a WordPress plugin by checking for the readme.txt file for it. The requests were for the path /wp-content/plugins/baiduseo/readme.txt. Those appeared to come from a hacker. Why would that be? Well the plugin, SEO合集(支持百度/Google/Bing/头条推送), was closed on the WordPress plugin directory yesterday:
Someone reported to us that our Plugin Vulnerabilities Firewall had blocked an attempt to exploit what turned out to be an arbitrary file upload vulnerability in the plugin Advert Manager. The blocked request was sent to the plugin’s file /upload-file.php. The relevant code that allows arbitrary file uploads in the file is this:
2 3 4 |
$uploaddir = 'uploads/'; $file = $uploaddir . basename($_FILES['uploadfile']['name']); if (move_uploaded_file($_FILES['uploadfile']['tmp_name'], $file)) { |
Someone reported to us that our Plugin Vulnerabilities Firewall had blocked an attempt to exploit what turned out to be an arbitrary file upload vulnerability in the plugin WP E-commerce CSV Importer. The blocked request was sent to the plugin’s file /upload/upload-file.php. The relevant code that allows arbitrary file uploads in the file is this:
2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$uploaddir = "../../../uploads/wpsc/product_images/"; $file = $uploaddir . basename($_FILES['uploadfile']['name']); $type = $_FILES["uploadfile"]["type"]; $size=$_FILES['uploadfile']['size']; if($size>1048576) { echo "error file size > 1 MB"; unlink($_FILES['uploadfile']['tmp_name']); exit; } $newfile = "../../../uploads/wpsc/product_images/thumbnails/" . basename($_FILES['uploadfile']['name']); if (move_uploaded_file($_FILES['uploadfile']['tmp_name'], $file)) { |
if($size>1048576)
{
echo "error file size > 1 MB";
unlink($_FILES['uploadfile']['tmp_name']);
exit;
}
$newfile = "../../../uploads/wpsc/product_images/thumbnails/" . basename($_FILES['uploadfile']['name']);
if (move_uploaded_file($_FILES['uploadfile']['tmp_name'], $file)) { [Read more]
Someone reported to us that our Plugin Vulnerabilities Firewall had blocked an attempt to exploit what turned out to be an arbitrary file upload vulnerability in the plugin HB AUDIO GALLERY. The blocked request was sent to the plugin’s file /lib/upload_picture.php. The relevant code that allows arbitrary file uploads in the file is this:
21 22 23 24 25 26 27 28 29 |
$fileName = time() . '_' . basename($_FILES['picture']['name']); $success = false; $uploadDir = HBAG_IMAGE_UPLOAD_DIR; $targetPath = $uploadDir . $fileName; $aid = $_POST['audio_id']; $targetPathUrl = PICTURE_DIR_URL . $fileName; //Upload file to server if (move_uploaded_file($_FILES['picture']['tmp_name'], $targetPath)) { |
//Upload file to server
if (move_uploaded_file($_FILES['picture']['tmp_name'], $targetPath)) { [Read more]
On Friday we looked at a vulnerability likely being exploited in a WordPress plugin, where there is a fix, but WordPress hasn’t made it available. Like that situation, we had what appears to be a hacker probing for usage of the plugin Front End Users over the weekend by requesting the readme.txt file for the plugin. Like that previous situation, the plugin is closed on the WordPress plugin directory:
Recently, our firewall plugin blocked an attempt on one of our websites that appeared to be trying to exploit a vulnerability that would allow an attacker to upload a .php file to a website. We were able to trace that back to a vulnerability in the plugin Startklar Elementor Addons.
The logging for the block attempt showed that the attempt was trying to access an AJAX accessible function in a WordPress plugin that would be accessed with the action set to startklar_drop_zone_upload_process. That plugin makes a function named process() accessible through that to those logged in to WordPress as well as those not logged in: [Read more]
This week, our Plugin Vulnerabilities Firewall plugin has blocked several attempts across our websites to exploit a vulnerability in a WordPress plugin. In investigating the attacks, we found that the vulnerability exists in the most recent version of the BuddyPress Cover plugin. That plugin was closed on the WordPress Plugin Directory on May 28:
We recently saw a hacker probing for usage of the WordPress plugin AI Engine on our website and third-party websites with the following request:
/wp-content/plugins/ai-engine/readme.txt [Read more]
We recently had a hacker probing for usage of the WordPress plugin BERTHA AI on our website with the following request:
/wp-content/plugins/bertha-ai-free/readme.txt [Read more]
