Security Concepts: Half of all WordPress Plugin Vulnerabilities are XSS and Securing FTP

We had a lot of fun creating our WordPress Security Learning Center. One of the coolest experiences was being able to share with WordPress site administrators how attackers actually gain entry to their sites.

Our Introduction to Secure WordPress Sites is the starting point we recommend for all beginner or intermediate level WordPress administrators. In our introduction, we include a demonstration video in the section explaining why it’s important to use sFTP to manage your site and never use FTP. I’m the guy narrating the video and I demonstrate how to use Metasploit to grab FTP passwords from the network when someone uses insecure FTP. That was really fun!


We also discovered some amazing things while creating the Learning Center. In doing analysis on WordPress plugin vulnerabilities to determine what we should be teaching developers, we unearthed a startling statistic that really surprised me and the rest of the team. 47% of WordPress vulnerabilities are Cross Site Scripting (also called XSS) vulnerabilities.

What this means is that if we can successfully teach WordPress developers to avoid writing XSS vulnerabilities, we can prevent almost 50% of the vulnerabilities that appear in WordPress plugins.

This is the distribution we found when we analyzed every plugin vulnerability reported for the past 14 months:

Distribution of WordPress Plugin Vulnerabilities

Once we discovered this, it became clear that it was worth spending a significant amount of time explaining how XSS vulnerabilities are created, how they are exploited and how to avoid writing them.

Our PHP Vulnerability Types and How They Originate article gives you a concise introduction to XSS vulnerabilities which is very accessible for beginner to intermediate WordPress site admins. It doesn’t include any code and uses plain english to explain Cross Site Scripting.

In our Introduction to Writing Secure PHP Code we provide a code example of an XSS vulnerability and how to fix it. What I particularly like about the intro to secure code article is that it talks about XSS vulnerabilities in the broader context of sanitizing, validating and escaping user input and application output. Rather than focusing on a quick atomic fix, we give you broader and more comprehensive view of the problem you’re solving.

In “How XSS Vulnerabilities are Created and How to Avoid Them” we go into detail on Cross Site Scripting vulnerabilities and explain how to avoid them in your code. We include an explanation of the difference between ‘stored’ vs ‘reflected’ XSS which most people don’t understand.

You’ll notice that the content in the WordPress Security Learning Center is vendor neutral. We actively avoided mentioning Wordfence anywhere unless it became very awkward not to. The reason we did this was to create a resource that could focus on the problem of securing the WordPress community and that would help developers write secure themes and plugins for WordPress.

If you would like to help with this effort, please tweet the learning center articles, link to them in your blog posts and online conversations and share the knowledge with the larger community to help us all become more secure. Remember that every WordPress site that is hacked becomes an attack platform that can target your own site. So helping others be secure really does help you be more secure.

Happy Holidays!!

~Mark Maunder – Wordfence Founder & CEO.

Did you enjoy this post? Share it!


  • Nice to know this. However, I can't get it to work using Fzilla and port 22. The message returned everytime is "...Error: ssh_init: nodename nor servname provided, or not known
    Error: Could not connect to server

    • Hi John,

      If you're using filezilla you might have to put ssh:// before the IP address or hostname. It sounds like you may have mistyped the IP or hostname you're trying to connect to.



  • nice post and video. thanks.

  • On a completely related topic, I've just published a HTTP Header plugin for WP, so users can set their own headers, add security headers, etc. Because I couldn't find an existing plugin that allowed me to define my own HTTP response headers.

    It's called "Headit", and you can see it here:

    • Cool! I think code is, in my humble opinion, the best way to express an opinion in technology. Especially if it can be used by others.

  • Hi Mark Maunder,
    I am a 80 years old retired engineer, who had followed 2 webinars how to build my own Wordpress weblog, which is a non-business site. 6 month ago my site had been hacked. My teacher Mark Burrell help me out, because he owns the template I am using. But of course it costed me some money. That was also the first time I heard about Wordfence.
    I am impressed about Wordfence.
    But I know nothing about code and Plugin Vulnerabilities are XSS and Securing FTP"

    Thank you for protecting the many websites and blogs using Wordpress system.

    • You are very welcome sir. We're happy to help. I hope the learning center we just put online is helpful to you.



  • I entered ssh:// and the message returned was to use sftp:// -- neither allows me access.

  • Great Articles!! this good to know about that SFTP is more secure then FTP . I will use that while using that. Wireshark can also sniff password which is not using Secure protocol. :)

    Thanks for article sir!!

  • Hey Mark and Wordfence!

    Thanks so much for these dandy tips! This is great! And easy!

    One caveat about the sftp that I think your visitor John Hughes may be experiencing is that this technique appears to be only available with VPS. Or, conversely, the SFTP access may be something that one needs to acquire through their hosting provider. I have 5 connections that I access through Filezilla and only the VPS connections would log on with the sftp:// prefix and port 22.

    Maybe you guys have some more wisdom on this?

    It should be noted that a VPS is strongly suggested for use with WordPress.