Oracle's most recent update to Java 7 addresses 42 security flaws has 19 which are considered "critical" and a 10 ranking. In addition to the security fixes, Oracle has been attempting to fix the self signed framework for applets to make them appear less trusted. If you are familiar with the Social-Engineer Toolkit - the Java Applet has been the best technique for penetration testers for the past four years. Updates to the Java Applet has been slow - a few years ago, you could sign a Java Applet with whatever publisher you wanted to and have the publisher field appear to be whatever you wanted it to be. For example: With the progression of the applets, the publisher was changed to UNKNOWN unless using a legitimate code signing certificate. An attempt to make it less believable if an attacker is attempting to use an applet for an attack. With Java 7 update 21 - a few changes occurred and one that was less documented. The first is that the applet shows a red flag saying that the Applet is not trusted and a potential risk: The second which took some time to debug on what was actually causing the issue is a potentially unsafe applet component. With further investigation, in the Social-Engineer Toolkit (SET) the repeater ended up being the culprit. Below is the message received in prior versions of SET: The interesting part about this is that even when executing the Java Applet - the code is still executed and shells presented: The problem relies on the repeater code that controls the behavior of the applet. The repeater code checks to see if the Java Applet is initialized, if not then present the user with the applet again (if cancel was specified. Looking at the Javascript code you can see the control on the client side: function RANDOMFUNCTION(count) { var applet = document.getElementById('IDREPLACEHERE'); var obj = null; try { obj = applet.isInitialized(); } catch(e) { } if (!obj && count > 0) { setTimeout( function() { RANDOMFUNCTION( --count ); }, TIMEHEREPLZ ); } else if (obj) { // do on load window.location = "URLHEREPLZ" } else { window.location.reload(); } } RANDOMFUNCTION(10); Upon changing the repeater to execute within the applet versus Javascript, theres no problem at all for execution of the repeater and getting a prompt for the unsafe execution. Interesting enough, while updates to the applet is needed in order to bring better security to the shortcomings and framework around Java Applets - the problem is not with what is displayed to the user but how it's presented to the user and the access it has. Java you would consider to be sandboxed however, within a Java Applet there is no reason to escape a sandbox. You can execute full Java commands including interacting with the command prompt, operating system, downloaders, and installation of malicious software. The applet provides no sandboxing and once clicked on run - can do whatever you want. The problem is not a little red highlight saying this may be a risk, the problem is the applet framework and how it's deployed. In order for Java to fix the applets, Oracle needs to completely redesign how applets work. TrustedSec performed analysis on pre and post implementation of the new changes in the applet. Prior to the release, the success rate during penetration tests and the applet deployment during a penetration test was 87% success rate with self signed certificates. Post deployment of Update 21 has the same success ratio of 87%. In addition, legitimate code signed certificates only saw an increase of 2% for 89%. The moral of the story is that individuals will click on whatever you tell them to if you make your attacks believable (which attackers are doing). Oracle is attempting to move businesses and developers in the direction of code signing certificates from legitimate code signing authorities. The problem is, with 50 bucks to register a shell company and 300 bucks for the code signing certificate - that is extremely trivial. At the end of the day, the believability on a self signed versus a code signing applet is minimal with little to no improvement on acceptability of the end-user.