September 27th, 2017

WordPress: Massively Popular and a Big Target for Attackers

For a deep dive, see our white paper: Securing WordPress

WordPress is the world’s most popular publishing platform, with a strong emphasis on usability and support of open web standards. It powers most of the largest content providers as well as millions of personal blogs. Its open source software, available at, can be downloaded to a suitable server and run as a standalone publishing platform, while ordinary users can quickly create personal sites as sub-domains of

There’s no doubt that the statistics about WordPress are impressive: ~30% of the million most visited sites on the Internet run WordPress; at 52%, it far surpasses its nearest competitor (at a measly 6.3%) for the largest market share of content management systems; it powers 96% of blogging websites worldwide – we could go on and on, but we refer the reader to other sources for more numbers.

Wordpress is a massive target for hackers

But with such numbers come vulnerabilities. Its popularity makes it a conspicuous target for hackers. Not all hacking is in search of personal data or immediate financial gain. WordPress attacks serve as a fertile finishing school for hackers-to-be as well as provide access to resources that can be used for launching other types of attacks, such as search engine optimizations, ad injections, affiliate links, botnet attacks, etc. Consider some examples:

  1. Attack. A compromised WordPress server can be used to launch large scale, brute-force login attempts or denial-service attacks against other servers;
  2. Infect. A compromised WordPress website can include JavaScript code that takes the user’s browser to a rogue “ad server” which then redirects it to whatever malicious ad campaign is running;
  3. Spam. Spam emails might contain a link to a compromised WordPress site whose purpose is to redirect the browser to the spammer’s site. By using a link (to your site) that passes spam filters, the spammer or malware distributor trades on your site’s reputation to divert users to its site.
  4. Commandeer. Compromised WordPress servers can be used for file storage – files such as malware, child pornography, etc. Owners of such sites may remain oblivious to such usage, unless they happen to monitor their bandwidth and note odd usage patterns.
  5. Exfiltrate. A penetrated WordPress site can attack other sites on the same server and exfiltrate any data and passwords accessible to the site on that server.  This includes the complete contents of the WordPress database and other available databases.
  6. Infiltrate. Once your server is penetrated, that may give the attackers privileged access to other servers.
  7. Meddle. A malicious site can use a false referrer URLs to pollute other sites web traffic analytics.

All these would be merely interesting if it weren’t for the fact that WordPress is also used by many small and medium sized businesses to build web sites that contain their visitors’ sensitive and private data. In the cases of interest to us, WordPress’s ease of setup and low cost make it an attractive choice for hosting sites for medical practices and other small businesses. Such sites often accumulate a lot of confidential information, such as protected health information (PHI), personally identifiable information (PII), and other company and customer secrets such as mailing lists, customer lists, sales prospect data, etc.

Superficially, HIPAA’s technical safeguards for access, audit and integrity and data transmission protections appear to be well covered by WordPress. However, the devil is in the details. While creating a site may be quick and easy with WordPress, establishing its security and maintaining it over time is much harder.

In a series of posts, we shall outline the security vulnerabilities of WordPress, the state of current WordPress security with examples of healthcare-related data breaches, and best practices for creating a secure WordPress site — one suitable for all businesses which require a security posture of some kind — i.e., everyone.

In this first post of the series, we’ll describe the nature and causes of WordPress vulnerabilities.   This gives you an idea of what you are getting into when setting your site up with WordPress and reflects the difficulty of setting up a secure web site of any kind.

How WordPress vulnerabilities arise

Aware of its attractiveness to hackers, the WordPress Security Team is extremely responsive to reported and verified vulnerabilities. Patches are released promptly, either in the next point release or as an immediate push depending on the severity of the exploit. A new feature since WordPress version 3.7 allows for automatic background updates of such patches, requiring no action on the part of site administrators.

Unfortunately, site owners can (and often do) opt out of automatic updates. As the recent Equifax breach has just revealed, it is one thing to have security updates available and another to actually apply them. (Equifax waited to apply a critical Apache security patch[1] more than two months after its release, with predictable and disastrous consequences.) Indeed, are many versions of WordPress operating in the wild: about 68% of WordPress sites are running old versions of the software.

Also, it is not just the core WordPress software that you must worry about. WordPress has over 40,000 plugins, performing a variety of customized functions. These extend the basic functionality and provide the feature richness that adds to WordPress’ usability and popularity. There are many sources of plugins, both free and commercial, and can often come from untrusted sources. Some plugins come with malware pre-installed! As if this were not enough to worry about, WordPress also offers something called “themes.” These are features that help you customize the style (fonts, layout, widgets, etc.) and look and feel of your web page. There is also a rich ecosystem of theme providers[2], both free and commercial, again of varying reputation.

Plugins and themes are notorious sources of security vulnerabilities. Many WordPress breaches can be attributed to outdated or unpatched plugins or themes or those downloaded from untrusted sources. WordPress maintains a database of plugin vulnerabilities, but critics complain that the data is often stale or inaccurate. In fact, an industry has grown around monitoring security for WordPress and its ecosystem. WordPress’s official plugin and themes repositories are scrutinized by its legions of users and are generally considered safe. Of course, users have to ensure that they regularly update to the latest versions.

In the case of a medical site, the concern is also that custom plugins and themes created for this market niche are properly maintained, updated and patched by their developers in a timely fashion as new vulnerabilities are identified. There might not be as much scrutiny of these as for the more common and general purpose ones.

A closer look at WordPress vulnerabilities

The specifics of different exploits of WordPress and its plugins are too numerous and complex to detail for a general audience in this post. However, almost all vulnerabilities arise from issues with the PHP code which powers WordPress, plugins and themes. Careless PHP coders unwittingly introduce such vulnerabilities into their code.  With so many lines of code from so many different developers of varying levels of skill and security expertise and with such varying levels of oversight and testing, it is not surprising that there are and will continue to be large numbers of known and yet-to-be-discovered vulnerabilities. 

If your version of WordPress and all of its plugins and themes is up to date, then you may be protected from most known and published security issues.  However, attackers often use new or unpublished attach vectors (i.e., “0 day attacks”) to penetrate even fully updated sites.  Knowing this, someone interested in using WordPress for sensitive data must understand how vulnerabilities arise and take steps defend against as yet unknown issues.  There will always be future vulnerabilities.

We provide below a brief description of the sorts of vulnerabilities that are most commonly found and exploited by WordPress attackers.

SQL Injection

SQL injection is a security vulnerability arising from the ability to insert malicious code into SQL queries and statements via web-based form inputs, such as the username and password login inputs. Instead of the expected username/password, the hacker enters specially crafted SQL statements into the fields which are then run against the database. There are many more ways of SQL injection than bypassing login fields and returning results. SQL injections can have a deadly effect, as they provide access to the database where new accounts can be created (with full admin rights) and new data added such as links to other websites, etc. They can and are also be used to exfiltrate the full contents of a running database. And, of course, there are automated hacking tools to probe for SQL injection vulnerabilities and perform the attacks quickly and efficiently!

The solution is to prevent user input from being passed “as is” to web applications and back ends. PHP offers ways to “sanitize” the data to neutralize anything that could be harmful.

SQL Injection allows data exfiltration

Cross-site Scripting

Cross-site Scripting (XSS), is a means by which an attacker can insert malicious JavaScript that is downloaded and executed when a user (via her web browser) visits a page or inputs data into forms. There are many ways to insert malicious JavaScript into the target web page. Once the page is displayed and the script executed, the attacker can take advantage of various JavaScript capabilities including sending arbitrary requests to any website in the background, reading sensitive information like session cookies, or manipulating the page itself to create, for example, a fake login form whose entries are diverted to the attacker.

There are several ways to prevent XSS, most notably “escaping” user input so that the browser does not read it as code to be executed.

Cross-site Request Forgery

Cross-site Request Forgery (CSRF) is a way for an authenticated user at a site to have his session hijacked by an attacker. For example, a link in an unrelated HTML email causes the browser to run some malicious JavaScript on a site to which the user is currently authenticated. The actions take place within the established security context between the browser and the website and therefore the rogue actions happen transparently and seem normal from the web site’s perspective. In contrast to the XSS attack, where the server is compromised, the server is not penetrated and CSRF uses the browser as its unwitting accomplice.

There are several ways to prevent or mitigate CSRF.  These should be combined with training on sensible user actions and policies, such as not staying logged on indefinitely.

Remote Code Execution

Remote Code Execution (RCE) exploits a bug in the code (OS, applications etc.) of a system to introduce malware. In particular, it allows attackers to execute their own programs on the server.  With the aid of this malware, the attacker can freely roam about the system – remotely! – performing all sorts of actions with administrative privileges. One common mode of infiltration is to use memory overflow vulnerabilities in browsers to run arbitrary code in the target system.

File Upload

The File Upload vulnerability is as simple as the name suggests. It takes advantage of a very common user action, and therein lies it weakness. An attacker finds a way to upload some malware disguised as a normal file into a system. This can be trivial if there is no authentication check of users who are allowed to upload, or if there is no check on the file types that can be uploaded. After that, it is only a matter of time when the attacker can gain access to execute the code the malware contains.

Web Shell

This is a small footprint PHP script that is uploaded to an already hacked PHP-supporting site such as WordPress. Once uploaded, the script can perform all the actions of the server administrator. Web shells typically are browser-based and provide a convenient GUI for performing actions such as uploading/downloading files and scripts, creating/deleting files and directories, running scripts, database access, etc. Typically, web shells are used for defacing a site or hijacking it for purposes of sending spam emails.

There are several more WordPress attack vectors. The interested reader can consult the list at the WordPress Security site.

Future Posts

We shall continue this series in future posts by looking at the current state of WordPress security, some examples of WordPress-related healthcare breaches, various mitigation techniques and best practices for creating a HIPAA-compliant WordPress site.

Read Next: For a deep dive, see our white paper: Securing WordPress



[1] To be clear, the Equifax vulnerability had nothing to do with WordPress. We are making a point about the vulnerability that comes from postponing updates and patching.

[2] For instance, look here and here for popular medical themes for WordPress sites.

Leave a Comment

You must be connected or logged in to post a comment. This is to reduce spam comments.

If you have not previously commented, you can connect using existing social media account, or register with a new username and password.