I wish the authors of this post gave us a heads up beforehand. It put our users at unnecessary risk.
At Jenkins project, We've published a mitigation script (https://jenkins-ci.org/content/mitigating-unauthenticated-re...) while we work out a better fix for users.
I guess they really wanted those minutes of fame.
This is just one of 23432542574358 attack vectors that can be deployed across intranets and already are routinely ignored, and a hard one at that. It should be patched, and it's a bit shameful to leave it lingering for more than a year, but it's hardly the end of the world.
Companies use deep packet inspection systems on their networks that can actively block packets that look malicious like this attack though, and it's how a lot of enterprises aren't hacked to smithereens every day despite the unfathomable incompetence of so many people working on "critical" applications. I had to deal with an issue where an application was not sending back Ajax requests on occasion that was causing a lot of panic, and it turned out that the reply sent back was being blocked due to a network packet inspection device actively blocking the response because it detected HTTP headers that matched an Apache vulnerability from 2002.
To me, this counts as "remote" because you can build up a big library of dozens of enterprise BS-ware applications that enterprises fail to patch all the time and probably find something that people didn't secure right. Qualys probably won't even be catching this stuff (it's stupid enough to think that a Chef server is running Django and continue to keep probing)
Black hats are going to have fun with this one. :-(
Something that is called out in the Java secure coding guidelines:
http://www.oracle.com/technetwork/java/seccodeguide-139067.h...
and is something that goes way back in many languages. It seems to be a vuln pattern that keeps getting repeated sadly.