Critical Persistent XSS 0day in WordPress

**Update 20150427**: A patch has been released and made available by the WordPress Core Team in version 4.2.1 – Please update immediately.

Yes, you’ve read it right: a critical, unpatched 0-day vulnerability affecting WordPress’ comment mechanisms was disclosed earlier today by Klikki Oy.

Who’s affected

If your WordPress site allows users to post comments via the WordPress commenting system, you’re at risk. An attacker could leverage a bug in the way comments are stored in the site’s database to insert malicious scripts on your site, thus potentially allowing them to infect your visitors with malware, inject SEO spam or even insert backdoor in the site’s code if the code runs when in a logged-in administrator browser.

You should definitely disable comments on your site until a patch is made available or leverage a WAF to protect your site and customers.

Technical details

This vulnerability requires an attacker to send a comment long enough to force the backend MySQL database to truncate what is stored.

WordPress Database Schema

As you can see from the above schema, the comments texts are stored in the comment_content column which is a TEXT column, meaning a comment can only contain a maximum of 65535 bytes of data.

A typical exploit would look like the following:

<a href='x onclick=alert(1) AAAAAAAAAAAAAA..(multiplied so our comment contains more than 65k bytes)'>test</a>

Once taken back from the database would look like this:

<p><a href='x onclick=alert(1) AAAAAAA</p>

Some of you might have noticed that the resulting HTML tag isn’t complete, but this isn’t a problem for most modern browsers as most of them will simply patch it up automatically:

Screen Shot 2015-04-27 at 10.43.34 AM

This bug then allows anyone to insert any HTML tag attributes to his hyperlink, including Javascript event handlers.

What you can do

There’s a few thing you can do to prevent getting hacked before there’s an official patch being released: You can disable comments on your site or leverage a Web Application Firewall to filter good requests from exploit attempts.

Hopefully the WordPress team will release a patch soon.

WordPress Themes: XSS Vulnerabilities and Secure Coding Practices

As many might imagine, my life revolves around Information Security. If you’re like me, you’re undoubtedly seeing all these new posts talking to insecurities in WordPress themes, specifically a plethora of Cross-Site Scripting (XSS) vulnerabilities. Surprise, surprise, right? Yeah, no, not so much.

WordPress Theme XSS Vulnerabilities

Here are some of the posts I am referring to:

Read More

WordPress 3.3 XSS Vulnerability Patched (3.3.1 Released)

We just learned of a reflected XSS vulnerability in WordPress 3.3 via the comments form (wp-comments.php). It is explained in detail here.

The disclosed vulnerability can only be triggered via Internet Explorer according to the disclosing party, our tests lead to the same result.

To further note, this is hard to reproduce because it does not get triggered when WordPress is installed via a domain. If you’re running WordPress 3.3, and WordPress was installed via a domain, you’re not vulnerable. (ethicalhack3r)

We do not consider this to be a serious vulnerability, however, we recommend updating to WordPress 3.3.1 since the vulnerability can be used in targeted attacks. More info on the release can be found in the WordPress Codex, over via the release post.