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.