The “Real-Time Find and Replace” WordPress Plugin Updated To Address A High Severity Vulnerability – Disposable mail news

So as to address a high severity vulnerability, the “Real-Time Find and Replace” WordPress plugin was updated as of late in order to forestall the exploitation to infuse code into sites.

The plugin, accessible as open source and has over 100,000 installations is intended to permit WordPress site admins to dynamically supplant HTML content from themes and different plugins with the content on their personal preference before the page is served to users.

The vulnerability recognized by the name of ‘Cross-Site Request Forgery (CSRF)’ prompting Cross-Site Scripting (XSS), could have permitted an attacker to infuse malignant JavaScript code on a target site, yet just by fooling the administrator into performing explicit actions, such as clicking a link.

The core of the plugin’s ‘functionality’ for including the find and replace rules in the function far_options_page, which didn’t confirm the integrity of a request’s source, since it didn’t utilize nonce verification, WordPress Security Company Defiant had discovered.

 By supplanting an HTML tag like with noxious JavaScript, an attacker would
ensure that their code executes on about each page of the targeted site.
Utilizing the infused code, the attacker could make another administrative
account; steal session cookies, or direct clients to a malevolent site.

Defiant detailed the vulnerability to the plugin’s developer
on April 22 and the security flaw was tended to the same day.
The security company Defiant says, “Any attacker capable of
tricking a site owner into executing an unwanted action could replace any
content or HTML on a vulnerable site with new content or malicious code. This
replacement code or content would then execute anytime a user navigated to a page
that contained the original content. ”

“In the most up to date version, a nonce has been added
along with a check_admin_referer nonce verification function to ensure the
legitimacy of the source of a request,” Defiant explained further.

Version 4.0.2 or newer of the Real-Time Find and Replace
plugin includes a patch for the bug, and users are advised to update the plugin
as soon as possible to ensure their WordPress websites are protected.

Temp Mails ( is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Gehaxelt – How WordPress Plugins Leak Sensitive Information Without You Noticing – 10 minute mail

Sebastian Neef (@gehaxelt) is a IT security freelancer and a top contributor from the Disposable mail Crowdsource community. In this guest blog, he looks at ways WordPress plugins leak sensitive data in the wild:

Guest blog post from Crowdsource hacker gehaxelt

The OWASP Top 10 puts Sensitive Data Exposure on the 3rd place of the most common web security issues. In this blog post we will have a look at sensitive data exposure that you might not be aware of. 

WordPress is probably one of the most used Content Management Systems out there. The vast amount of available WordPress plugins certainly plays a huge role, as it allows your WordPress blog to become a full-fledged online shop (i.e link: woocommerce). But relying on 3rd-party plugins to customize your blog or shop comes with certain security risks. There are no restrictions on who can publish a plugin on, so the code quality and therefore security can vary a lot. 

I have analyzed how the most popular WordPress plugins leak information with remediation tips so you can continue using WordPress in a more secure way. 

This research was part of my attempt to get some more valid submissions to the Disposable mail Crowdsource platform, so my focus was only on the top-ranking WordPress plugins. To qualify as a valid submission for Disposable mail Crowdsource, the vulnerable plugin needs to have at least 300,000 active installations and the issue needs to be exploitable remotely without any form of authentication. At least for the information disclosure the criteria was met for the following plugins: 

* A module for this plugin was not implemented due to an increased request complexity.

Taking all installation counts from the above list together and assuming that one installation equals one website, we end up with about 19 million websites that are potentially affected by an information leak issue.  

Let’s first have a look on what kind of information is leaked by those plugins. I think there are three categories of leaked data, which also seem to match with certain CWE (Common Weakness Enumeration Database) categories:

    • Credentials (CWE-200: Information Exposure)
    • Personal Identifiable Information (PII) (CWE-359: Exposure of Private Information (‘Privacy Violation’))
    • System Information (CWE-215: Information Exposure Through Debug Information)


From the attacker’s perspective, gaining access to credentials is the jackpot. It might allow them to obtain usernames, passwords or API keys that could be used to escalate their privileges. A WordPress administrator account is allowed to edit themes or plugins, thus gaining remote code execution is trivial. Leaked API keys are no better, because they might allow the attackers to abuse them, gain unauthorized access or just create huge financial damage.

Here’s a list of things that fall into this category and that I’ve seen leaked:

    • Passwords to protected posts
    • Backup files or zips
    • SMTP credentials

Personal Identifiable Information (PII)

The next level in the hierarchy is, in my opinion at least, personal identifiable information. Especially in 2020 with the new digital information processing laws and GDPR, it might become a company’s nightmare if customers’ PII become public due to hefty fines. For that reason, I was even more surprised to find several plugins to leak the following customers’ or users’ data:

    • Names
    • Email addresses
    • Usernames

System Information

The third category comes down to the remainder of information about the system running WordPress or its configuration. Most of the following types might not have direct, critical security implications, but could still give the attacker useful information for more sophisticated exploitation chains. Most of the WordPress plugins were leaking the following information:

    • Internal host names 
    • Database tables, SQL queries
    • Security logs
    • Full path disclosures
    • File names
    • Software versions (OS, PHP, MySQL, WordPress)
    • PHP Configuration (safe_mode, memory limits, execution limits, etc)

So far we have discussed what plugins leak information and what kind of information is leaked, but we haven’t looked at how this information is potentially exposed to the attackers. 

At the core, the issue lies within WordPress’ file permission scheme which mentions that the wp-content/ folder should be writable, because some plugins might need write permissions there. Depending on how secure you or your WordPress administrator is, the whole wp-content/ might have full rwx permissions, and therefore most plugins choose to create directories and files there. 

This is not a problem by itself, but becomes one as soon as some plugins begin to create log files with the above discussed information that the web administrator does not know about. Plugin developers are not guaranteed a writable “data” folder outside the document root, where they could securely store such log files containing sensitive information in a non-volatile way. PHP’s sys_get_temp_dir could be an option, because it is system agnostic (not everyone runs Linux), but it might not offer persistence. The latter is pretty important for log files. Therefore, most plugin developers opt for a folder that they can assume to be writable on most WordPress installations as this stackoverflow thread suggests:

    • wp-content/uploads/
    • wp-content/*

The former works in most cases, because files uploaded through WordPress’ media library end up there, so it is writable to not break core functionality. The latter includes all subfolders, such as wp-content/plugins/ or wp-content/themes, if the administrator wants to easily install new plugins or edit themes.  

If you are a security-minded person and you are running a WordPress instance, now is the time to ask yourself if you have reviewed the source code of all active plugins, or did you simply install a plugin, because someone needed it to change the website’s functionality? You should review your plugins, but first continue reading to know what you should look for.

I have noticed two different patterns that developers use to create log files, and only one of them has basic security principals in mind. However, both approaches become ineffective security-wise once the administrator forgets to properly configure the web server. Therefore, we cannot just put all blame onto the WordPress plugin developers for leaks, but we need to reinforce basic security principles at any time.  

Static file paths

Developers are not naturally security experts, and often they focus on building solutions that work. There is nothing easier than using WordPress’ wp_upload_dir() or WP_CONTENT_DIR to obtain the path a writable folder and appending a plugin specific suffix. 

Here is a list of example paths:


Let’s recall that the wp-content/ folder lives in the DocumentRoot is accessible from the internet, thus all the files within it are usually accessible, too. This makes it trivial for an attacker to access those log files and their content by navigating to the well-known paths.

Random file names

A good portion of the plugins implemented their logging functionality with more security in mind. By adding a random portion to the file name, it cannot be requested directly without knowing the random part.

Depending on the implementation, the portion’s randomness varied greatly:

  • an incremented 6-digit number (not really random)
  • a randomly generated string
  • a cryptographic hash (MD5 or SHA)

To a developer, this approach might look pretty robust and secure, but it disregards the fact administrators also play a role. Given that WordPress is an entry-level CMS, it might be set up and operated by novice administrators, who just followed a tutorial “to make things work”.

The file name randomization is instantly defeated if the administrator (accidentally) forgets to turn off “directory listing” on their web server. In such a case, an attacker just needs to browse to the respective folders to get a list of the random file names. 

index of /wp-content/uploads/wc-logs

While working on this topic, I have found several examples of such misconfigured web servers on the internet. It is not just a hypothetical scenario. 

If you have made it this far, you might be asking yourself how I discovered all those log file disclosures. I will happily answer this question in this section, so that you can review your own plugins.  There were basically three approaches to this topic: 

    • Find existing files
    • Review the plugins’ source code
    • Use a search engine

While the first method did not show anything interesting in particular, the second one was the most fruitful, but also the most time-intensive. There were over 115 plugins to review, so naturally I could not invest the time to do a thorough in-depth source code review, but rather took some shortcuts and educated guesses. Last but not least, I used search engines to discover files that I might not have seen with the two methods before. 

Let’s have a look at them in detail. 

Find-ing existing files

find is a small linux command line tool to quickly find files or directories in a file system hierarchy. After installing some plugins, I ran it on my test WordPress instances like this:

$> cd path-to-wordpress/wp-content/
$> find . -type f -name ‘*log*’ -ls 
$> find . -type f -name ‘*txt*’ -ls
987828	4 -rw-r--r--   1 gehaxelt gehaxelt  	229 Feb  9  2018 ./sc_cache.txt 

This showed me a few files containing log or txt, thus matching either of the two regular expressions. It is by far the most efficient method to check if such files exist on your web server. If you are administering any WordPress instances, take a note and check your web servers  after you have finished reading.

Source Code Review

Most of the work done was source code review using a few lines of bash, grep and less. 

As the first step, I downloaded all plugins with more than 300k installation from the website and extracted them into separate folders. A few lines of python helped with that task. 

The next step was to look for and identify paths where log entries are written to. PHP offers a few methods such as file_put_contents or fopen to create files. By having access to the source code, using the command line text searching tool “grep” was a suitable choice. Keywords such as “file_put_contents”, “file_get_contents”, “fopen”, “log”, gave a good idea where to look for. 

From there, it became going bottom-up through the code and deducing where the file would be written and if it is randomized or not. 

Google Dorks

(Ab-)using search engines and their specific search keywords for security purposes is often referred to as “dorking”. No sophisticated hacking tools are required for such an attack, just a web browser, a search engine such as google and a query like inurl:"/wp-content/uploads/wp-google-maps/error_log.txt" would be enough to find a whole lot of affected websites.

I took the route of searching for a plugin’s directory name while adding keywords like log or txt etc. It gave mediocre results, but that was better than nothing and also helped to verify the findings from the previous step. 

Overall the results using this method are limited to web sites that usually have DirectoryListing enabled and make their contents indexable by certain search engines. 

We all know that breaking things is much easier than fixing it. I tried to come up with ideas for how to prevent such information leaks to make the ecosystem more secure.  

Rule #1: Use randomized file names

Static file paths make it insignificant for an attacker to check the existence of a file and download it. Using randomized file names might take a bit more time for a developer to implement, but boosts the security immensely. Especially since the majority of web servers should have directory listing disabled, so that an attacker cannot guess the correct file name. 

Rule #2: Prevent directory listing

Even the scenario of a directory-listing enabled web server can be mitigated by the plugin developer: For every folder that is created and where plugin-specific log files are written, an empty index.php file should be created. On literally every web server the index.php file is configured as the DirectoryIndex, meaning instead of showing all contents of a directory, this file will be executed. As an empty file has no content, the attacker won’t see a list of file names, but an empty page. 

Rule #3: Workaround

If Rule #1 and Rule #2 are not followed by a plugin, then one could try to move the created folder outside the “DocumentRoot” (i.e. using a symlink). Alternatively, explicit rules must be created to prevent access to static or randomized log files. Depending on the used web server, simple “.htaccess” files could be used. 

Rule #4: WordPress hardening

The WordPress developers have a lengthy article on WordPress security and hardening. At the time of writing it contained a neat statement which fits this topic perfectly: 

If a plugin wants write access to your WordPress files and directories, please read the code to make sure it is legit or check with someone you trust. 

It is always a good idea to go over this article and check if oneself has considered and implemented the given hardening tips.

To round this section up, I firmly believe that most plugins should be able to implement and follow Rule #1 and Rule #2. The other two rules, Rule #3 and #4, lean more towards the side of the system administrators, but we cannot take them out of the equation. If a WordPress instance is provided for you, don’t forget to ask the responsible administrator to go over the issues mentioned in this article.  

All of the initially listed WordPress plugins and their potentially leaked log files have been implemented into Disposable mail’s automated security and asset monitoring since September – November 2019. The security modules will give you insight into which log files on your web server are discoverable by an attacker. That means, the modules can:

    • easily identify the “static file path” log files 
    • detect the “randomized file path” log files, too, as long as the randomization can be circumvented with the method discussed earlier

My research doesn’t stop here. I am continuously pursuing this topic in order to bring more log file disclosures to users to secure more websites through the Disposable mail and the Crowdsource platform.


Written by:
Sebastian Neef
IT Security Freelancer and Disposable mail Crowdsource hacker

Sebastian Neef (@gehaxelt) is a security researcher at heart and has been interested in IT security since the age of 15. He became an IT security freelancer and consultant during his A-Levels back in 2012 when bug bounty and responsible disclosure programs were just starting out. Sebastian enjoys sharing his knowledge on conferences or his blog, breaking things, playing CTFs with ENOFLAG and helping companies to improve their security. 

How can Disposable mail help?
Disposable mail works with highly skilled ethical hackers like Gehaxelt to crowdsource the most up-to-date security research. Check for the latest WordPress vulnerabilities and 1500+ other known vulnerabilities with a start of a Disposable mail scan. Begin your 14-day free trial today.

Additional reading:
Improving WordPress plugin security from both attack and defense sides

How to Improve Your WordPress Security: Plugins and Themes

Temp Mails ( is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

IT Security FAQ 2: What should you think about when installing a new plugin on WordPress? – 10 minute mail

To add different functions to the popular CMS WordPress – like social media icons or contact forms – it’s usual for people to install and activate different plugins. However, it is important to keep in mind that most security breaches that happen on WordPress are due to vulnerabilities in these plugins.

Comment from our expert:
”My number one advice when installing a WordPress plugin is to ask yourself; do I really need this? Anyone can create a plugin for WordPress, and every new line of code is a possibility for something to go wrong. If you install a plugin with bad code, it could end up with someone hacking your website.”

”To check if a plugin is safe, start of by googling it to see if it has any known vulnerabilities, or if it has been known for having many flaws in the past. Who is the developer of the plugin and does that person seem to know what they are doing?”

”Every now and then, go through the plugins you have already installed and look up if they have any new vulnerabilities. Maybe they haven’t been updated for awhile, which means that they might be easier to hack. Most of the time, if it is a popular plugin with thousands or hundreds of thousands of users, it should be fairly updated and thus might also be safer to use. But when it comes to plugins, the old saying less is more really does apply,” says Johan Edholm at Disposable mail.

wordpress plugins


Want more IT security information? Don’t miss out on the other parts of our IT Sec FAQ series!

Temp Mails ( is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

OWASP TOP 10: Using Components with Known Vulnerabilities – 10 minute mail

Using components with known vulnerabilities is one of the vulnerability categories on OWASP‘s list of the ten most common vulnerabilities. A proof of concept video follows this article. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their Top 10 list one by one in our OWASP Top 10 blog series. 


It is very common for web services to include a component with a known security vulnerability. When that happens it falls under this category, independently of what kind of component is vulnerable, making this a very frequent finding.

The component with a known vulnerability could be the operating system itself, the CMS used, the web server, some plugin installed or even a library used by one of these plugins.


It is one of the most common vulnerability types, with one of the reasons being that it is hard to find. The attack surface is wide as any layer could be vulnerable. As stated above any used component, everything between the core of the OS to libraries used by plugins, could have known vulnerabilities making the site vulnerable.

Developers usually focus on securing their own code and often forget about the code they have imported from others. In many cases developers are not even aware of all the code that is running. This is mainly due to plugins which in turn import libraries which in turn have their own dependencies etc.

Potential impact

The potential impact is impossible to grade for this as it completely depends on the vulnerable component and what vulnerability it suffers from. The vulnerability could be an XSS on some unimportant subdomain, but it could just as well lead to a full system takeover.


When a vulnerability is published on the internet, someone often uploads a ready to use payload which an attacker could simply download and use against the target. This means that an attacker can use it towards the site without even knowing how and why it works. Even when a PoC is not available, documentation about the vulnerability is easy to access, so all the attacker would need to know is how to follow instructions.

However, there are of course also exceptions to this. Some vulnerabilities require existing knowledge about the system, and if the component that is vulnerable is not directly exposed to the internet, the attacker would need to figure out a solution to that as well.

In short, this is often really easy to exploit, but can be as hard as any other vulnerability.

Over the last few years about 4500 CVEs have been published every single year, and there are of course even more vulnerabilities. It is thus hardly surprising that it is impossible for most developers to keep up-to-date with all this information.

Well-known events

A few years ago Reuters got hacked and someone was able to take over their Twitter account to spread false news. Reuters is one of the biggest news agencies and the possible impact of such attack should be obvious.

According to Wall Street Journal they used an outdated version of WordPress when the attack happened, making it likely that was the way attackers were able to comprise the site. It is, however, possible the attack was carried out in some other way as well.

How to discover

The first step is to identify all components that are being used and could possibly be vulnerable, i.e. the ones that somehow process user data. This includes CMS solutions, web servers, operating systems, plugins and everything in between.

The next step is to look up every component for vulnerabilities and exploits. The first step would be to use Google to search for this, and then proceed to look into different vulnerabilities and exploit databases.

To increase the likelihood of hearing about vulnerabilities before someone else uses them for malicious purposes, mailing lists, forums and word of mouth are examples of means that would be necessary to take advantage of.

How Disposable mail can help

We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Disposable mail is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 700 vulnerabilities, including OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable » 

Example of a vulnerable application

One of many examples would be running a WordPress installation with the plugin Jetpack with a version lower than 4.0.3 as stated in our blog post about that specific vulnerability.

There are thousands more ways this vulnerability can occur, so one concrete example does not necessarily say much. However, the Jetpack case might help illustrate how vulnerabilities can be found in popular plugins, affecting a wide range of users.


The first step to get rid of vulnerabilities in the components you are using would be to always keep everything up to date. Build the system in a way that allows security patches to be installed in a timely manner.

Be careful when external components, plugins, softwares or even the dependencies of those plugins are used. Make sure that everything fulfils the requirements that have been set for custom code regarding regularly maintenance, passing security tests, etc.

Slim down the system as much as possible. Delete plugins that are not used, disable features that are of no use, block ports that are not in use.

Regularly scan the site with a security scanner that updates with new vulnerabilities. When using our own service the default is to scan once a week as we constantly update it with more vulnerabilities, and we would recommend something similar if another service was used as well.

As always in life, the following rule applies: do not use anything that sounds too good to be true.

Using Components with Known Vulnerabilities Proof of Concept video:

Just leave a comment or contact [email protected] if there are any questions, we are happy to help!

Temp Mails ( is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Improving WordPress plugin security from both attack and defense sides – 10 minute mail

Paul is a front- & backend developer with a passion in security, who creates designs occasionally. After starting out with WordPress plugin vulnerabilities, he joined the bug bounty world and now also a white hat hacker in the Disposable mail Crowdsource community. As he has acquired his knowledge through community resources himself and wants to make the internet a safer place, he shares his know-how to give something back and in this case tips on WordPress plugin security.

TL;DR: This article aims to be a useful resource for hackers, which would like to learn about functions specific to WordPress plugin security, but also for plugin developers, who might not know about common vulnerabilities like XSS. As a result, vulnerability types are being briefly explained and decorated with links to additional resources to learn more about them before going into WordPress related details for each of them. Let’s improve the WordPress ecosystem security together from both sides, attack and defense.

With a market share of more than 50 percent, WordPress is the most popular Content Management System available. It currently powers 32 percent of the web and WordPress plugin security should always be on top-of-mind. The popularity is at least partly caused by the extensive ecosystem including over 55.000 free open source plugins only tracked in the official repository. On top of that, each installation can easily be individualized with all kind of different themes. Vulnerabilities, especially in plugins and themes, are being discovered regularly. Currently, there are 14.000 vulnerabilities from the core, plugins and themes being categorized in the WordPress Vulnerability Database.

Plugin and theme usage can be mostly fingerprinted in a reliable way by analyzing the generated source code. Therefore a blackbox pentest can be more or less made a whitebox one of. This is why I’d like to write about a few WordPress related aspects – such as vulnerability specific functions – and gotchas that helped me finding several vulnerabilities in WordPress plugins in the past.

WordPress Hooks

WordPress is built to be extendable and flexible in order for plugin developers to be able to ‘hook into’ the rest of WordPress.

There are two different types of hooks: Actions and Filters.

Actions can be thought of as event points, at which you can execute custom PHP code. For example, a developer can hook into the send_headers event in order to send an additional header:


function add_cors_header ()

Next time a response from WordPress is sent, CORS will be allowed exclusively for

Filters allow developers to alter input or output. For example, before displaying a post and after retrieving it from the database, it will be passed to the the_content filter. Again, the second parameter for adding a filter is a function. That function will receive the content as its first parameter. The data returned by the function will then be displayed on the post page. Let’s show You have been hacked. instead of the actual content for all posts:

add_filter('the_content', 'overwrite_post_content');

function overwrite_post_content ($content)
    return 'You have been hacked.';

With this information in mind, it is a good idea to search for all add_action and add_filteroccurrences. Understanding points at which specific code is being executed helps you getting a first impression of some of the plugins features. Sometimes this is enough to spot a vulnerability.

WordPress has a comprehensive list showing all the WordPress hook actions with a description on when they are triggered and a link to the subpage for the specific action including a more comprehensive reference. Especially hooks like admin_init, which is being triggered first for admin page calls, are interesting starting points, because they usually lack sufficient validation and can be accessed by guests aswell. You will learn about that in a moment.

Special action hooks

WordPress has two special endpoints: /wp-admin/admin-ajax.php and /wp-admin/admin-post.php. Even though they are both located in the wp-admin folder, non-administrative users and also guests can send requests to them. But the location will play a key role later on.

/wp-admin/admin-ajax.php basically is an endpoint for custom AJAX requests from within anywhere in your blog. Want to send a form asynchronously? This is the way to go.

/wp-admin/admin-post.php acts in a similar way, but is not generally meant for AJAX requests.

The handlers can be added just as any other action prefixed by wp_ajax_ and admin_post_respectively. Everything else will be the action name. Request parameter action will differ between all the handlers registered for the endpoints. Normally, only authenticated users (which includes low-privileged users such as subscribers) can send requests to them. Adding nopriv_ to the prefix allows unauthenticated requests for both AJAX and admin post calls.

Let’s create an AJAX action which will return the current date for guests:

add_action('wp_ajax_nopriv_retrieve_date', 'current_date');

function current_date ()
   echo date('d.m.Y');

Retrieving the data works like the following:

$.post('', {
    'action': 'retrieve_date',

is_admin() is not is_admin()

Auto completion and suggestions from a developers IDE can be dangerous. Starting to write something like is_ might result in is_admin() being suggested. What does is_admin() do? Checking the current users role, pretty obvious, right? It is not.

ìs_admin() checks for the current endpoint and will return true if the URL being accessed is in the admin section. You probably already see where this ends. is_admin() returns true for both of the endpoints explained above. I honestly wouldn’t have thought of this nor knew about it without reading the documentation.

In fact, this nearly removed the need for exploiting a Cross-Site Request Forgery (CSRF) in order to achieve a Remote Code Execution in a vulnerability I discovered recently in a plugin with 300.000 active installs. A practical deep dive into the vulnerable code including hooks and is_admin() can be found in the disclosure of Widget Logic CSRF to RCE.

Cross-Site-Request-Forgery (CSRF)

How does a website know a request originates from the current website and was willingly fired by the user, who sent it? What would happen if an attacker recreates the form for adding an administrator on his malicious page, which it will be submitted automatically? The admin of the target WordPress blog visits the page, which results in a new administrative user being created. That was a rough outline of what CSRF is about.

WordPress ships with pre-created methods for CSRF tokens and they should always be checked before triggering a state changing behaviour.

wp nonce field() adds a hidden input to your existing form. If you are crafting your own POST AJAX requests for example, only retrieving the token itself can be achieved by calling wp_create_nonce. In a GET request, wp_nonce_url() might be the more convenient way.

On the receiving end, tokens can be verified via methods including wp_verify nonce() and check_admin_referer().

It is advised to always pass the action parameter to both the methods for creating and verifying the nonce. Tokens created for a specific action are only valid when being checked against with the same action being given to the validation method.

wp_verify_nonce() returns…

… false for invalid nonces,
… 1 in case of a valid nonce created within the past 12 hours and
… 2 for nonces older than 12 hours but still within a range of 24 hours.

check_admin_referer() will stop the application by calling die() without a valid token being passed. Important: This just happens in the prefered usage, check the documentation.

Additionally, this is – just like is_admin() – not an authorization check.


As we now know, there are several popular ways of adding a supposed authorization middleware, which does not actually check any permissions.

Roles and capabilities can be verified with current_user_can(). It returns a boolean and needs to know which role or capability has to be available for the currently authenticated user in its first parameter.

For example, making sure only administrators can access the functionality works like the following:

if (current_user_can('administrator')) {
    // Sensitive functionality

WordPress provides a list of all capabilities.

SQL Injection

Even in 2019, SQL injections are some of the most common and critical types of vulnerabilities. Letting untrusted input become part of a database query without escaping or prepared statements leads to a leakage of the whole database. Just to name a possible way of abusing the issue. Again, you can read more about that in an in depth explanation about SQL injections.

Let’s say we create a custom action available via /wp-admin/admin-ajax.php, which retrieves a certain post by its id:

add_action('wp_ajax_nopriv_get_post_by_id', 'get_post_by_id');

function get_post_by_id()
    global $wpdb;

    if (! isset($_REQUEST['id'])) {

    $postId = $_REQUEST['id'];

    $post = $wpdb->get_row('SELECT * FROM '.$wpdb->prefix.'posts WHERE ID = '.$postId);
    header('Content-Type: application/json');
    echo json_encode($post);

A pretty much simplified example of an unauthenticated SQL injection. This does happen in the wild. A GET request with a parameter ID set to a malicious extension to the existing query will retrieve the first administrators name and password hash:


Exploiting the SQL injection

Preparing the query with prepare(), which is part of the wpdb class, is the recommended way of achieving a safe execution. The syntax is similar to sprintf. First parameter receives the raw query with unquoted placeholders:

%s for strings,
%d for integers,
%f for floats.

Every parameter after that will replace the placeholders in the query in their respective order. Alternatively an array can be used for the second parameter.

So how do we refactor our insecure code?

$post = $wpdb->get_row($wpdb->prepare('SELECT * FROM '.$wpdb->prefix.'posts WHERE ID = %d', $postId));

Of course, there are much more functions crafted for database interaction. If you are unsure, consult the WordPress documentation page for the specific method or class to make sure it is rather safe to use with user input or any special sanitization needs to be done before supplying the data.


One of the most common vulnerabilities is Cross-Site-Scripting (XSS). In WordPress plugins, it can often be found within a small chain of vulnerabilities – CSRF to XSS. But what is XSS about? XSS happens when displaying user input without sanitizing it, extremely simplified. For example, if the malicious input is not a comment for the website but a

Temp Mails ( is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.