In July, I found a (stored) cross-site scripting vulnerabiliy in the ‘404 to 301’ plugin for WordPress; the plugin avoids 404 errors by redirecting them, and logs all the visits to a database so that they can. Unfortunately, it displays those logs as part of the administrator interface, and failed to escape the Referer and User-Agent fields before rendering them as part of the HTML page. This means that an attacker can run arbitrary JavaScript in the context of the admin user, by making requests which produce 404 errors, and then waiting until the administrator views the log page (or linking them there somehow, for example).

Such basic errors are relatively common in WordPress plugins; I found this one after literally picking the plugin at random from a list of plugins with relatively many installs (80K+). I submitted it to Securify’s Summer of Pwnage, which was a month-long project searching for vulnerabilities in WordPress plugins; I didn’t really have the time to participate, but I did go and chat with people for a few hours on July 15th, and I thought I might as well find something to submit. My advisory is now publically available on their website.

Usually I wouldn’t even write up XSS issues involving WordPress plugins, but it turns out that (somewhat embarassingly) I missed a much more serious vulnerablity; specifically, as written up a month later, the plugin turned out to inject arbitrary HTML from a third-party site when it was visited by a search engine crawler (e.g. GoogleBot). I do remember seeing the code, but I at the time I didn’t give it too much thought; I was just interested in finding some low-langing fruit - such as this basic XSS vulnerability - which I could quickly write up, and I ran WordPress in an isolated VM where it couldn’t connect to the external site.

The author hastily removed this “tracking” code a few days after it was discovered that spam was being injected into webpages, and then quietly fixed the XSS vulnerabilities in late August.