Trusted by developers and store owners.

Stop fake orders before they hit your WooCommerce checkout.

For store owners tired of refunding, cleaning up, and losing ad spend to fraud.We block card testing and fake transactions — automatically — so you keep every dollar and every real customer.

• FREE FRAUD AUDIT

lock down your WooCommerce store

The FRAUD Problem

You’re not bad at managing your store.You’re just trying to fight a coordinated problem with the wrong tools.Most WooCommerce stores get hit by fraud the same way:- Random orders from fake emails that look real.
- $0.01 “card testing” orders running through PayPal or Stripe in batches of hundreds.
- Real payment fees on fake transactions that never ship.
- A spike in failed payments that tanks your gateway reputation.
- And endless admin time spent cleaning up mess you didn’t cause.You have a security plugin — but it only protects logins, not your checkout.You have reCAPTCHA — but bots are smarter than that now.You block IPs — but new ones appear every hour.Meanwhile, the attacks keep coming.You feel frustrated, helpless, maybe even embarrassed — wondering why something this common doesn’t have a straight answer.We’ve been there.We’ve seen stores lose thousands in chargebacks, ad spend, and gateway bans because they relied on general “security” plugins that don’t understand WooCommerce.That’s why we built a system that does one thing exceptionally well: stop fake orders before they ever hit your checkout.So you can finally focus on growing sales, not cleaning up fraud.

• BOOK FRAUD AUDIT

Done-For-You Fraud Protection

90% of fraud stopped within 4 hours.99% within 7 days.

We set it up, monitor it, and shut it down — all for you.
No guesswork. No configuration. No wasted ad spend.If we don’t stop your fake orders, you get your money back.

• Book FRAUD AUDIT

Creativo3d - JOSE

"Before using this, we were getting hit with dozens of fake PayPal orders every week. It was frustrating, and I was terrified of losing my payment gateway. Now the attacks have stopped completely — every order that comes through is real. I finally feel in control again."

• Book FRAUD AUDIT

Book my security demo

Speak to a fraud expert

Use the link below to book a FREE security site review and we'll call you in the next 2 hours.

• Book FRAUD AUDIT NOW

© All rights reserved | WooGuard Pro Ltd

Faucibus

Tempus

The purpose of this article is to provide information to developers and researchers regarding how vulnerabilities can exist in their plugins or themes and how these vulnerabilities can get patched up in order to increase the safety of the world-wide-web in general.Note that we will only provide basic information about these vulnerabilities. There is much more in-depth information to it, but this kind of information is widely available on other sites such as PortSwigger which we will link to in each vulnerability type.Additionally, the examples and remediations only show specific scenarios. Each vulnerability is unique and the remediation for all the different scenarios could greatly differ.Most common WordPress vulnerabilities
SQL Injection (SQLi)
SQL injection occurs when a user provided input value is not being validated or sanitized properly or not used as part of a prepared statement. SQL injection can also occur when the wrong sanitization function is used, or WordPress functions are used incorrectly.More information:Patchstack Weekly: Patchstack Weekly, Week 06: Preparing for SQL Injection
OWASP: SQL Injection
PortSwigger: What is SQL Injection?
SeverityVery high. Affects the integrity and confidentiality of the site. Information could be extracted from the database and malicious information could be inserted into the database depending on the vulnerability.ExampleThe examples below assume a user input variable, through a query parameter or form parameter, is being submitted.$variable = $REQUEST['id'];// Vulnerable, user input variable used directly in SQL query.
$wpdb->getvar("SELECT * FROM wpusers WHERE id = " . $variable);// Vulnerable, escsql variables must be enclosed within quotes.
$wpdb->getvar("SELECT * FROM wpusers WHERE id = " . escsql($variable));// Vulnerable, sanitizetextfield does not remove quotes or escape values.
$wpdb->getvar("SELECT * FROM wpusers WHERE id = " . sanitizetextfield($variable));
RemediationUse the $wpdb->prepare function for any and all interaction with the database that requires user input variables and make sure that you use the placeholder feature (%s, %d, etc) instead of injecting the variables directly into the SQL query. In addition to that, you likely want to validate the user input values you are receiving to make sure that they meet your expectations.$variable = intval($REQUEST['id']);
$wpdb->getvar($wpdb->prepare("SELECT * FROM wpusers WHERE id = %d", [$variable]));
Cross-Site Scripting (XSS)
Cross-Site Scripting occurs when user input variables are not being escaped (output) and sanitized (input) properly. This usually happens due to there not being any sanitization and escaping at all or due to a misunderstanding of some of the WordPress functions.More information:Patchstack Weekly: Patchstack Weekly #46: How To Protect WordPress Against Cross-Site Scripting Attacks (XSS)
OWASP: Cross Site Scripting (XSS)
PortSwigger: What is cross-site scripting (XSS) and how to prevent it?
SeverityVery high. Depending on where the vulnerable user input variables are displayed, this could either affect the entire site and allow a malicious user to perform a redirect to a malicious site, deface the website or simply execute JavaScript on a very specific page.ExampleThe example below assumes a user input variable is saved directly inside of an option, which is then retrieved.$identifier = getoption('myidentifier');// Vulnerable, zero output escaping.
echo '<input type="text" name="myidentifier" value="' . $identifier . '">';// Vulnerable, sanitizetextfield does not escape quotes.
echo '<input type="text" name="myidentifier" value="' . sanitizetextfield($identifier) . '">';
RemediationWordPress provides a long list of different escape functions you can use to escape your user input variables. Depending on where you output the user provided values, you might have to use different functions. The WordPress link will explain in-depth when and where to use each function.If your plugin or theme accepts custom HTML provided by a user, you should use the wpkses function as it allows you to define a whitelist of allowed HTML tags and attributes. However, that gives no guarantee that XSS is not possible.In the example above, we'd want to use the escattr function as it's a user provided value that is printed into a HTML element's attribute.$identifier = getoption('myidentifier');
echo '<input type="text" name="myidentifier" value="' . escattr($identifier) . '">';
We also often see cross-site scripting vulnerabilities in plugins that makes a shortcode available. As contributors can also use shortcodes, it may introduce a contributor+ cross-site scripting vulnerability.For shortcodes the patch is simple as well, just escape the extracted variable. See an example below:extract( shortcodeatts( array(
'style' => ''
), $params ) );// Vulnerable:
$html = '<div style="' . $style . '" class="my class">';
// Should be:
$html = '<div style="' . escattr($style) . '" class="my class">';// Some other code here to generate the HTML...return $html;
Broken Access Control
Broken access control vulnerabilities exist when the authorization and/or authentication of the user is not properly checked. We have seen this very often in actions registered under the following hooks: wpajax, adminaction, adminpost, admininit, registerrestroute.These hooks do not check the authorization and authentication of the user by default. For registerrestroute that would be the case when the permission callback function always returns true.More information:Patchstack Weekly: Patchstack Weekly, Week 45: Authentication vs Authorization
Patchstack Weekly: Patchstack Weekly: Secure AJAX Endpoints & WordPress Vulnerabilities
OWASP: A01 Broken Access Control - OWASP Top 10:2021
PortSwigger: Access control vulnerabilities and privilege escalation
SeverityVery high. We have seen a significant number of vulnerabilities that exist because of a missing authorization check which often leads to a plugin settings change vulnerability. This can affect the integrity, confidentiality and availability of your site.ExampleThis example registers a WordPress AJAX action. Since it's registered under wpajax_, it requires at least subscriber+ privileges.// For this example, we assume there is no nonce token check.
addaction('wpajaxupdatesettings', function(){
updateoption("mysettings", $POST);
});
RemediationWordPress has several functions to determine the authorization of the user. For example, currentusercan and usercan. These can be easily implemented to make sure that unauthorized users cannot perform higher privileged actions. It is also important to check a nonce token in all actions, more information about that in the Cross-Site Request Forgery section.addaction('wpajaxupdatesettings', function() {
if (!currentusercan('manageoptions') || !wpverifynonce('action', 'action')) {
exit;
}updateoption("mysettings", [
'setting1' => eschtml($POST['setting1'])
]);
});
Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery occurs when a nonce token is not being validated while an authorized action is being performed. For example, if you have a WordPress AJAX action that only validates the authorization but not a nonce token, it is possible to force the higher privileged user to perform that action with arbitrary values by either tricking them into visiting a malicious site with the CSRF payload or by executing XSS on the same site.More information:Patchstack Weekly: Patchstack Weekly: WordPress Vulnerabilities & Cross-Site Request Forgery
OWASP: Cross Site Request Forgery (CSRF)
PortSwigger: What is CSRF (Cross-site request forgery)?
SeverityVaries. CSRF is rarely exploited in the wild as it depends on the higher privileged user and might require some level of social engineering as well. In addition, the action that can be executed through CSRF needs to be executing a meaningful action as well.ExampleThe example below which although validates the authorization of the user, does not validate a nonce token.addaction('wpajaxupdatesettings', function() {
if (!currentusercan('manageoptions')) {
exit;
}updateoption("mysettings", [
'setting1' => eschtml($POST['setting1'])
]);
});
RemediationWordPress provides you with a few functions you can use to validate a nonce token. First, you have to make sure that the nonce token is available to the user. You can generate a nonce token for the frontend using the wpcreatenonce function.With the passed nonce value, you can use the wpverifynonce function in an if statement or use the checkadminreferer function outside of an if statement as it automatically exits the script if no nonce token could be validated.addaction('wpajaxupdatesettings', function() {
if (!currentusercan('manageoptions') || !wpverifynonce('action', 'action')) {
exit;
}updateoption("mysettings", [
'setting1' => eschtml($POST['setting1'])
]);
});
Note: make sure that the nonce token check is correctly implemented. We often see nonce token validation implementations which can be bypassed due to mistakes in the way it is implemented. An example is shown below. This is still vulnerable to CSRF because if we simply don't pass the action POST parameter in the CSRF payload, the nonce token is not validated either.addaction('wpajaxupdatesettings', function() {
if (!currentusercan('manageoptions')) {
exit;
}// Should be: if (!isset($POST['action']) || !wpverifynonce('action', 'action')) {
if (isset($POST['action']) && !wpverifynonce('action', 'action')) {
exit;
}updateoption("mysettings", [
'setting1' => eschtml($POST['setting1'])
]);
});
Server-Side Request Forgery (SSRF)
Server-Side Request Forgery occurs when a HTTP request is sent where the URL can be specified by the user thus allowing them to cause the server to send a request to any URL they desire.If there are local services running which are not accessible by the public, this vulnerability can be used to get access to those local services.More information:Patchstack Weekly: Patchstack Weekly #33: What is Server Side Request Forgery (SSRF)?
OWASP: Server Side Request Forgery
PortSwigger: What is SSRF (Server-side request forgery)?
SeverityVaries. This completely depends on what is running on a private environment which can be accessed through a SSRF attack. For the usual WordPress environment this will have close to no impact on the security state. In addition, this also depends on whether or not the result of the HTTP request is returned to the user or not, because otherwise it would be a blind SSRF issue which tend to be even harder to exploit successfully.Examplewpremoteget($GET['url']);
RemediationValidate the URL before it's used in a HTTP request. You can use the wpsaferemoteget function instead of wpremoteget or similar functions such as filegetcontents or usage of the cURL library.Directory Traversal
Directory traversal, sometimes also known as path traversal or arbitrary file read, occurs when a file can be read from the filesystem and its contents are returned back to the user. This should not be confused with Local File Inclusion, which is (in most scenarios) used to execute a file on the website under the context of the webserver/PHP.More information:OWASP: Path Traversal
PortSwigger: What is directory traversal, and how to prevent it?
SeverityMedium to very high. The severity depends on what kind of information is stored on the filesystem of the site and also depends on the setup of the site. For example, if for some reason there is a publicly accessible PHPMyAdmin installation then the wp-config.php file could be read after which the database connection information can be used to connect to the PHPMyAdmin environment.Exampleecho filegetcontents($GET['file']);
RemediationValidate the input parameter before it's used in any function that reads a file. You could match it against a list of acceptable values, verify that it only contains letters using ctypealpha, or remove all slashes and dots. However, keep in mind the fix entirely depends on how this function call is implemented.Local File Inclusion (LFI)
Local File Inclusion occurs when an arbitrary file can be included and executed under the context of the webserver/PHP. This can be especially dangerous if users can upload a file, regardless of the file extension. If a file such as image.png is included using PHP functions such as include or require, any PHP code inside of this file will still get executed.SeverityMedium to very high. The severity depends on what files are available on the website that can be included and if the user can or cannot upload their own files.Exampleinclude $GET['test'];
requireonce './some/folder/' . $GET['test'];
RemediationValidate the input parameter before it's used in any function that includes a file. You could match it against a list of acceptable values, verify that it only contains letters using ctypealpha, or remove all slashes and dots. However, keep in mind the fix entirely depends on how this function call is implemented.Remote File Inclusion (RFI)
Remote File Inclusion occurs when a malicious user can cause the webserver/PHP to load a remote file and execute it under the context of the webserver/PHP. The most common RFI vulnerability typically requires PHPs allowurlinclude to be set to 1.SeverityVery high. This could cause a complete loss of integrity, confidentiality and availability.Exampleinclude $GET['test'];
RemediationYou should never implement the ability to load a remote URL this way. If you must, you should make sure that the user supplied value is part of a whitelist or strict pattern.Remote Code Execution (RCE)
Remote Code Execution occurs when a user supplied value is executed in a PHP function that executes a shell command. Some of these functions include shellexec, exec, popen, system, passthru and procopen.More information:Patchstack: Patching Remote Code Execution in the 'member-hero' Plugin
OWASP: Command Injection
PortSwigger: What is OS command injection, and how to prevent it?
SeverityVery high. Although this also depends on the configuration of the hosting environment and PHP, this could still cause a lot of damage. Someone could, under the right conditions, upload backdoors (wget/curl command) or reverse shell (netcat).Exampleshellexec('imgoptimize ' . $GET['cmd']);
RemediationThe user input values must be checked to only contain allowed values. If you need to escape arguments passed to a binary, consider using escapeshellarg. However, keep in mind that the remediation entirely depends on how the user input value is injected into the command.CSV Injection
CSV Injection occurs when user supplied values are directly inserted into an exported CSV file. When this CSV file is then opened in an application such as Windows Excel, the maliciously injected values from the user could contain a formula that executes a command instead.More information:Patchstack Weekly: Patchstack Weekly #30: What is CSV Injection?
OWASP: CSV Injection
SeverityLow to medium. This would also require the generated CSV file to be opened inside of an application that allows these kinds of functions to be executed. Exploitation would require several steps and potentially social engineering too to get the higher privileged user to export/download the CSV file and then open it in the application.RemediationThe remediation is pretty straightforward. Certain characters that are related to functions should be escaped with a quote. An example can be seen below. You pass the CSV row (the array of values for one row, typically then passed to fputcsv) to this function and it will escape the appropriate characters.function getencodedrow( $row ) {
$result = [];foreach ( $row as $key => $value ) {
$encodedvalue = $value;
if ( inarray( substr( (string) $value, 0, 1 ), [ '=', '-', '+', '@', "\t", "\r" ], true ) ) {
$encodedvalue = "'" . $value;
}

• Continue