WooCommerce Quote Plugin Flaw: Hackers Upload PHP, No Login

A WordPress quote form could potentially give an attacker control of your server, and they don’t even need a WordPress account. We’ve also got a messaging plugin that could expose your database, a vulnerability that waits for an administrator to open a log, a booking system flaw that could interfere with customer records, and new research showing how AI is finding security problems inside WordPress plugins.

I’ve spent 25 years building production software, and I’ve managed hundreds of WordPress websites over that time. So let’s look at what’s happened, what the actual risk is to your business, and what you need to do about it.

Let’s start with that quote form. If your website allows customers to request a quote and attach a file, pay attention to this one. A critical vulnerability has been disclosed in Addify’s Request a Quote for WooCommerce plugin, and it affects version 2.9.2 and earlier.

Under the vulnerable configuration, the attacker doesn’t need a WordPress account. They don’t need your password, and they don’t need an administrator to click anything. The problem is with the plugin’s file upload functionality.

Imagine your business sells something that requires a custom quote. A customer opens your quote form, uploads a PDF, drawing or specification, then submits it. Your website is supposed to strictly control what kind of file they’re allowed to upload, but the vulnerable version doesn’t properly validate those files.

That means an attacker could potentially upload a PHP file, and that’s considerably more serious than somebody uploading the wrong document, because PHP is code your website can execute. An attacker could potentially upload their own program to your website, then attempt to make your server run it. The vulnerability has been rated 9.8 out of 10, and successful exploitation could lead to remote code execution.

For your business, that could potentially mean complete compromise of the website. An attacker could potentially access your WordPress configuration and reach your database credentials. They could install malware, create administrator accounts, modify your website and redirect your customers.

Depending on your hosting configuration, the problem could potentially extend beyond this one website. And if customer information is accessed, you’re potentially dealing with a data breach as well.

But there are important conditions here. You need to be using Request a Quote for WooCommerce version 2.9.2 or earlier, and the vulnerable attack path involves a public quote rule using the multi-page popup flow. So don’t assume every WooCommerce website is vulnerable.

Check your website. Log into WordPress, go to Plugins and find Request a Quote for WooCommerce. Check the version number, and if you’re running 2.9.2 or earlier, update it to 2.9.3 or later.

If you can’t update immediately, disable the affected public quote functionality until you can. And if that vulnerable configuration has been publicly accessible, don’t stop at the update.

Check the website for unexpected PHP files. Check for administrator accounts you don’t recognise, and review your server and security logs for suspicious activity. Updating closes the vulnerability, but it doesn’t remove something an attacker may have already put there.

Next up, Better Messages. That’s the WordPress plugin used for private messaging, group chat, chat rooms and AI chatbots. Versions up to and including 3.0.4 are affected by an SQL injection vulnerability.

The attacker does need a WordPress account for this one, but they only need subscriber-level access. That distinction matters because, on a membership or community website, a subscriber isn’t necessarily someone you trust. It could simply be somebody who registered an account.

The vulnerability allows that user to interfere with the query being sent to your WordPress database. Your WordPress database contains a lot more than your blog posts. Your users, your website settings and your plugin configuration are in there, and depending on your website, customer information may be in there as well.

A successful SQL injection attack can potentially allow information to be extracted from that database, and depending on the vulnerability, database information may also be manipulated. So the business risk here is potentially the confidentiality and integrity of the information your website relies on.

But again, there are conditions. The vulnerable path involves Better Messages being used with the BuddyBoss platform, and it also depends on the social groups configuration. So don’t translate this into every Better Messages installation being compromised.

Check whether the conditions apply to your website. Go to Plugins and find Better Messages. If you’re running version 3.0.4 or earlier, update it to 3.0.5 or later.

Then check whether your website allows ordinary users to register accounts, and if you’re using BuddyBoss, check the social groups configuration as well. If all of those conditions line up, I’d give this considerably more attention than a normal plugin update.

Next is Automatic.css, and this one has a different attack path. Automatic.css version 4.0.0 contains a stored cross-site scripting vulnerability. The attacker doesn’t need a WordPress account to plant the malicious content, but the attack doesn’t necessarily happen immediately; it can sit there and wait.

An attacker sends a specially constructed request to your website, and malicious JavaScript can then become stored in data associated with that request. Later, an administrator logs into WordPress and opens the Automatic.css activity log settings page. That’s when the malicious JavaScript can execute inside their browser.

The administrator hasn’t necessarily downloaded anything, opened an email attachment or clicked a suspicious link. They could simply be checking the activity log on their own website. That’s what makes this one interesting.

Cross-site scripting allows attacker-controlled JavaScript to execute inside somebody else’s browser, and in this case, that browser could belong to a WordPress administrator. That means the code is executing while the administrator is authenticated to WordPress. Depending on what the attack is designed to do, that could potentially expose information, perform actions using the authenticated session, or become part of a broader compromise of the website.

Fortunately, the update for this one is straightforward. The affected version is Automatic.css 4.0.0, and the vulnerability is fixed in 4.0.1. So go to Plugins, find Automatic.css, and if you’re running 4.0.0, update it to 4.0.1 or later.

This is also a good example of why you need to know what an update actually contains. Unless you’re looking at the changelog, a notification saying there’s a new plugin version doesn’t tell you whether it’s a new feature or whether it’s closing a vulnerability that could affect your administrator account. Those updates shouldn’t necessarily have the same priority.

Next is Bookly. This one is particularly relevant to businesses using WordPress to manage appointments. Bookly can hold customer information, it manages bookings, and it can send booking notifications.

A vulnerability affects Bookly version 28.2 and earlier, and the attacker doesn’t need a WordPress account. The problem is in Bookly’s customer verification process. Bookly uses a one-time code to verify access to customer information, but the vulnerable version doesn’t perform that verification correctly.

An attacker can potentially bypass that check, which could allow somebody who isn’t logged in to modify an existing Bookly customer record. That could include the customer’s name, email address, phone number and address. An attacker could potentially change those contact details to information they control.

Now, think about what that means for a real business. Imagine this is a medical clinic, a salon, a consultant, a trades business, or any organisation where appointments represent real customers and real revenue. A legitimate customer makes a booking, but somebody changes the information associated with that customer.

Your notifications could go to the wrong address, your staff could contact the wrong person, and you could no longer necessarily trust the integrity of the customer information in your booking system. That’s why the CVSS number shouldn’t be the only thing determining your response. This vulnerability is rated medium severity, but if Bookly is fundamental to how your business operates, the business impact could be considerably more important to you.

So go to Plugins, find Bookly, and if you’re running version 28.2 or earlier, update to 28.3. Then test the booking system: create a test booking, make sure the confirmation email arrives, check the customer information, check the staff notification, and make sure the booking appears where it’s supposed to.

The job isn’t finished because WordPress says the update succeeded. The business process needs to work as well.

And finally this morning, we have some interesting new WordPress security research. Researchers have built an AI-driven system designed to find exposed log files created by WordPress plugins. They tested it against the 300 most installed WordPress plugins, which together represent more than 250 million active installations.

The system identified 81 potential findings across 62 plugins. The researchers manually investigated those results, and they were able to reproduce 79 of the 81 findings.

The problem they’re investigating is surprisingly simple. WordPress plugins create logs, and those logs can be incredibly useful when something goes wrong. But those files can also contain sensitive information.

They may contain an error message, an API request, a username or customer information. They could even contain credentials or information about how the application works.

Now imagine that log file is sitting somewhere that can be accessed directly from the internet. An attacker doesn’t necessarily need to hack WordPress; they may simply be able to request the file. That’s important, because this isn’t necessarily something you fix by updating a plugin.

You need to understand what information your website is creating, where that information is being stored, and whether somebody on the internet can access it. So don’t start randomly deleting log files, because some of them may be important for troubleshooting.

Instead, check whether WordPress debugging is enabled when it doesn’t need to be. Review the plugins that create debug logs, and review transaction logs, API logs, email logs and integration logs. Find out where those files are stored, then verify that they can’t simply be downloaded from the public internet.

But there’s another interesting part to this research. The researchers used both static and dynamic analysis, and an AI agent helped investigate how the plugins actually behaved. That’s potentially where WordPress security becomes much more interesting.

Instead of waiting for somebody to discover a vulnerability and publish a CVE, we can increasingly analyse what’s actually happening on a particular website: what plugins are installed, how they’re configured, what information they’re creating, and whether that particular combination introduces a risk. That’s a much more useful security question than simply asking whether everything is up to date.

So today’s priority starts with Request a Quote for WooCommerce. If you’re running version 2.9.2 or earlier, update to 2.9.3, and if the vulnerable quote functionality was exposed, investigate the site as well. Then check Better Messages, Automatic.css and Bookly.

Understand whether your website actually met the conditions for each vulnerability, and where it did, don’t assume installing the update means the job is finished. The update closes a vulnerability, but you still need to consider what could have happened before you installed it.

Keeping WordPress updated is essential, but managing WordPress securely is much bigger than clicking the update button. That’s your WordPress security briefing.