Millions of WordPress Websites are vulnerable to Cross-Site Scripting (XSS)

Sucuri, a company that offers a security service that detects unauthorized changes to network (cloud) assets, including web sites, DNS, Whois records, SSL certificates and others, last week’s report came as a shock to most webmasters using WordPress. The report indicated the vulnerability of any WordPress Plugin or theme powered by the genericons package to DOM-based Cross-Site Scripting (XSS).

Not a big deal, right? There are thousands of packages in WordPress repositories and a single package doesn’t matter much anyways. Think again! The install base of a plugin from the package, JetPack, is installed in over 1 million sites, and this is only a small part of the threat. The other part is TwentyFifteen, the default theme of genericons package, not to mention thousands of other plugins and themes based on that package. Taken together, there is no harm in predicting 3 million websites to be on vulnerability radar. Which is the vulnerable part

Any plugin or a theme based on the genericons package by default contains a file, examples.html. This file is vulnerable to XSS and acts as a vector.

What is “DOM-based Cross-Site Scripting (XSS)”?

In simple words, DOM-based Cross-Site Scripting (XSS) is a typical cross-site scripting attack involving Document Object Model (DOM) elements in the HTML code or JavaScript of a website. Like every XSS, wherein the attacker inputs a malicious script in a web site element like a forum, comment section, or any other input area; any user clicking on that element triggers the attack and gives access to the attacker.

The attacker in the case of “DOM based XSS”, rather than an input element, modifies the DOM elements with a malicious code in the user’s browser and wait for him to click it. The page, although remains the same, behaves differently due to the modifications in the DOM elements. The naïve victim, unable to see the difference in behaviour, is tricked to click on that element, unwarily triggering the attack. The page after the attack could share personal information of the victim to the attacker or simply annoy him with random popups. The choice remains on the attacker.

Why can’t a firewall stop XSS?

The modifications were carried out at the client’s end in a way a new HTTP request was not issued to the client. The firewall at the client’s end, hence, never gets a chance to filter out malicious traffic/ modified code, unless a security patch is applied.

The Good News

As the attack has just hit the wild and still in infancy, chances are you’re not a victim yet and can take necessary precautions.

The Bad News

In one pattern of the attack, an effected WordPress user after logging into WordPress admin was shown a message, “One of your Plugin is vulnerable. Click here http:// for more information.” Clicking on the link triggered XSS, taking over his entire website.

What can I do to prevent my WordPress website from attack?

As I mentioned, the vulnerable example.html file is the source of the threat. By removing the genericons/example.html file, you can easily take over the threat. In addition, a patched (for the threat) firewall or an intrusion detection system should provide an added layer of security.

As the threat has a mass impact, patching millions of WordPress user is going to take some time although a patch is underway. Meanwhile, don’t click rogue links or a banner promising you $1m in prizes, especially when you’re login to WordPress admin.

Many hosts are working night and day to patch this threat. See if your host is among the list:

  • GoDaddy
  • HostPapa
  • DreamHost
  • ClickHost
  • Inmotion
  • WPEngine
  • Pagely
  • Pressable
  • Websynthesis
  • Site5
  • SiteGround

If not, play extremely safe while browsing the web. Alsom if you suspect a breach, disable any plugin or a theme based on genericons package, not to mention, installing a Web Application Firewall (WAF) if you haven’t yet.

What if I am attacked?

Follow The Basic Principles of Security:

  • Maintain a pristine environment in production.
  • Remove debug or test files before you move into production.
  • Remove simple example.html file that had the vulnerability embedded
  • Contact a security expert in XSS
  • Install a Firewall to reduce further harm
  • An Intrusion detection system can save you from zero day threats

Simple oversight of these principles can have devastating impacts on unsuspecting website owners and businesses alike.


As always, prevention is better than cure, however, if your website is compromised, you’re helpless unless. Meanwhile, you can only wait for a patch. The wide range reach that the plugin and theme have combined is another part of the concern: Both of them are installed by default.

Any site behind an updated Website Firewall is still protected, regardless of the status of examples.html file. If a WAF or IPS are not protecting your website, deleting example.html from the genericons directory is must.

Author Bio (Byline):-

Jignesh Parmar is the digital marketing analyst & strategist at Intesols. For the last three years, he is helping small businesses and start-ups to gather the right online marketing tactic. He is passionate about everything digital, and his life revolves around online marketing world. You can follow him on Twitter or reach out to him via Linkedin.


Leave a Reply

Your email address will not be published. Required fields are marked *