Background: It is well known and understood that the Java security sandbox
will only allow an applet to communicate back with the host/computer that the
applet came from (there are ways for other hosts to grant
permission, but that is not at issue here).

The security flaw: When the JAR file pointed to in an <applet> tag
redirects to another server, java security is tricked by the Java caching mechanism. When
the applet is run for the first time, Java security properly thinks that the JAR file came from
the final redirected location. However, when the applet is run a second time, Java security thinks
that the JAR came from the original (pre-redirected) location. And in both cases,
Applet.getCodeBase() returns incorrect information.

The security risk: Extremely low in the demonstrated case. At issue is
the technical expertise of the Oracle Java security team,
because the 'Location' displayed in security dialogs is completely
wrong (not even the correct server).

Live Demonstration: Run the live javatest-coderedirect.html
web page in Java 7 update 25 (1.7.0_25). This applet on this web page
looks like this:

Then, on www.panohelp.com, the JAR does NOT exist. Instead, there is this HTTP redirect:

Redirect /test.jar http://www.maebilt.com/xxx.jar

Then, on www.maebilt.com, the JAR is actually found:

08/31/2013 09:45 AM 8,443 xxx.jar

First time run: The first time the live test is accessed (or, when the java
web browser and the Java cache are cleared), the end-result is that java security
correctly figures out where the JAR came from:

The 'Location' in the security popup is still the same as before (seen upper right),
and wrong, but this time, the applet can access the thinproof.jpg image from
www.panohelp.com (as seen in the screen snapshot below)
— even though the applet JAR code originates from www.maebilt.com
— a violation of the Java security sandbox rules.