You mean the Java 7 Update 11 and 13?
The warning is blown out of proportion, IMO- the warnings seem to suggest uninstalling Java altogether, which is like suggesting you remove Word altogether to prevent Macro viruses. A lot of the problem with how to respond to the Exploit is that people seem to trust the recommendations of these other associations, who themselves might not even know the details of the exploit itself.
In this case, the issue lies within the "MethodHandle" feature that was introduced with Java 7, which is similar in capability to the ideas of the DLR runtime for .NET Applications, in that it is designed to provide beter support for dynamic languages that run on the JVM and is designed to give more flexible and faster access to classes and methods in a dynamic way. Basically, the feature allows Java code to create a handle for a method from an arbitrary class. The exploit is that the feature to get handles to methods from an arbitrary class can be used to get handles to methods to the classes that get handles to methods of arbitrary classes, but when you call them that way, no security check is performed before the class method is actually called.
What makes the exploit interesting is that if code uses the MethodHandle feature as it is intended, there will not be a security issue- all method handles go through a security check when first resolved- the interesting part is that you can create MethodHandles that refer to classes and methods within the MethodHandles Package itself. (In this sense the vulnerability lies in the java.lang.invoke.MethodHandles.Lookup class). Essentially, it provides a way to lookup the constructor and methods from the target class when it tries to make said handle. if the methods handle for the findConstructor method of the MethodHandles Lookup class is used to resolve a constructor method for an arbitrary class, the security check will not be enforced correctly. This is a problem because the target class could be something that is typically restricted and requires a trusted code context- such as File IO or other system-oriented structures. Essentially it allows an application to- if constructed properly- instantiate their own code on the fly in another, more privileged security context.
Of course, this is only an "exploit" when used in contexts where it would have limited trust anyway. Using it in a standard desktop Java application is pointless since you are basically 'on the other side of the airtight hatchway', and already have the same abilities as you would be trying to get using the Lookup exploit.
It's worth noting also that the Java process that hosts applets generally runs with the same privileges as the browser, which is usually run through the users account. What this means is that software that uses this exploit is still limited in what it can do, but it provides a sort of "hole in the first fence" and essentially escapes the Java sandbox into the Account sandbox provided by the Operating System. This is of course still a major issue but generally speaking, since a Limited User Account cannot actually install low-level system software or access and/or change system components, on Vista,7,8 and Linux and OSX, which run users as a limited account by default, there is a mitigating factor. On a more or less default Windows XP, however, this exploit is devastating. Even more so than using a 12 year old Operating System. (then again, an XP machine can get owned pretty fast anyway thanks to the lack of mitigating security concerns).
Primarily at this point in a active exploit, the exploiting Java applet will drop it's payload. Typically, this is a executable program (what language it's written in isn't important, really). It can do this because it's busted out of the sandbox at this point. This program could be a keylogger or something of that sort.
With it's busted-out permissions it can now launch said executable. Of course this is still quite a concern, but most Operating Systems have mitigating factors that help to avoid major, system-wide issues as a result. The exploits in the wild currently rely on a sort of phishing tactic to try to elevate the payload. The fact it get's this far is still something of heavy concern- most people that are exposed to this aren't very security conscious and might not think twice about clicking allow to the Graphical Sudo or UAC prompt that might appear.
Most security packages such as MSE now detect attempts to exploit this vulnerability and are fully able to prevent it. often the payload contains some older package that is detected as something else.
Part of me thinks the biggest problem with this exploit is the massive confusion that Netscape prompted with Javascript. Even though Java in the browser through applets has been obsolete since the early 2000's, people still think they need Java installed in their browser- this is because, for a person unfamiliar with the technology, Java and Javascript may as well be the same thing- so you have people thinking Javascript has this exploit and disabling it, while leaving Java enabled, and people installing Java because sites say "this website works best with Javascript enabled", that sort of thing.
The "fix" is to properly enforce security barriers with regards to Method Handle introspecting itself. Oracle's current stopgap has been to change the default security setting to "high" which also prevents this from being exploited, since MethodHandle's can't be used at all when high security settings are enabled.
