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:
Today our Plugin Vulnerabilities Firewall stopped an attempt to exploit a recently fixed vulnerability in a WordPress plugin on our own website:
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]
We recently had what appeared to be a hacker probing for usage of the WordPress plugin GutenKit on our website. That likely is related to a vulnerability that had existed in the plugin. The developer wasn’t exactly upfront about that as what appears to be the relevant changelog entry only says “Improved: Security for external plugin installations.” The developer also still doesn’t seem to understand how to properly secure code that they have run through the WordPress REST API.
The relevant code exists in the file /includes/Admin/Api/ActivePluginData.php. That file registers a function to install another plugin in a way that makes it accessible to even those not logged in to WordPress: [Read more]
Across various data we monitor we have been seeing what looks to be a hacker or hackers trying to find websites using the plugin Kubio Pro, by requesting this url: /wp-content/plugins/kubio-pro/readme.txt. At first we were puzzled as to what might explain that. There isn’t a plugin on the WordPress Plugin Directory with the slug kubio-pro, so that would mean either it likely was a plugin made available somewhere else or a backdoor disguised as a plugin. We looked for any information on the web about a vulnerability in a plugin with that slug or the name Kubio Pro and came up with nothing. The same is true for competing data sources for information on vulnerabilities in WordPress plugins.
WPScan, owned by Automattic, serves a not found page for the URL that would contain data on vulnerabilities for a plugin with that slug: [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:
Yesterday, we had what would appear to be a hacker probing for usage of the WordPress plugin Checkout Mestres WP on our website by requesting the readme.txt file for it like this:
/wp-content/plugins/checkout-mestres-wp/readme.txt [Read more]
