And it could have been mitigated with anti-XSS 101: rejecting all form posts containing angle-brackets.
Unless you're intending for your user to post HTML, or math inequalities, or diff patches - there's no reason to allow angle brackets on a form post.
Blacklists are only acceptable if you do it in addition to contextual encoding wherever you emit user controlled data, and even then a much stronger protection would be to whitelist acceptable characters. Either way, contextual encoding whenever you emit user data is the only real protection. --And even then it's not a good fallback protection, a strong Content-Security-Policy should be your fallback protection.
> Unless you're intending for your user to post HTML, or math inequalities, or diff patches - there's no reason to allow angle brackets on a form post.
Form posts are not the only vector for XSS, any HTTP request can be potentially exploited to perform XSS (and any part of an HTTP request), doesn't matter if it's a Form, an AJAX request, an HTTP header value, or a GET parameter, they're all potential attack vectors.
In my experience, it doesn't even cover cases such as this one, but it certainly makes developers confident they don't need to apply contextual escaping.
And "rejecting all form POSTs containing angle brackets" is definitely not the XSS 101 prevention mechanism! Don't do that.