Has anybody reported anything? The commons project seems to have been made aware of this just this weekend through third parties. If nobody reported anything no wonder it didn't get fixed.

A big problem with a lot of enterprise application security models nowadays is that if you don't assume that your network has been compromised and that there's active attackers in your network already, you're pretty much setting yourself up for a Home Depot and Target situation. Nevermind that both of these companies are having record sales and stock valuations, enterprise security in practice is more about compliance and dealing with the cost of auditors / regulators showing up and slowing your business down than about loss of revenue and customer safety. Because if people really cared that much about companies that messed up their security, Apple would have had tanking iPhone sales, everyone would have flocked to Lowe's, and Wal-Mart would be picking up where Target's market share went down - none of these things are true at all, in fact the precise opposite.

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)

Well, true for websphere, but for weblogic the affected port is the default listening port, not the admin port. So for a public facing weblogic installation you have a problem.

Its not really a problem with commons-collections and unfair to color it as their issue. Its like blaming the library that is part of a ROP chain for the exploit. The issue is what gets you in first, which is instantiating objects without any thought as to what they are from un-trusted sources.

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.

That wasn't anti-Java snark. I was complaining that the headline format suggests some unusual thing in common for those projects. But it would immediately occur to you that they are all Java-based.