FULL PRODUCT VERSION :
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Debian Linux 6 Kernel 2.6.32 amd64
presumably, the bug is cross-platform

EXTRA RELEVANT SYSTEM CONFIGURATION :
Firefox 26

A DESCRIPTION OF THE PROBLEM :
The applet manifest attribute Caller-Allowable-Codebase can limit JS caller to specific websites. However, in some unusual cases, there is possibility to call applet from different site. This is due to the URL compare algorithm, which does DNS lookup and compares resolved addresses.

ADDITIONAL REGRESSION INFORMATION: 
The attribute Caller-Allowable-Codebase was introduced in 7u45 (also affected), so there is no way how to reproduce buggy behavior in earlier versions.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Set up DNS to point two different names (server1 and server2) to the same IP address of webserver.
2) Create HTML page with embedded applet and JS calling that applet.
3) Create applet with "Caller-Allowable-Codebase: https://server1".
3) Sign the applet.
4) Put the HTML page and applet to the webserver.
5) Open https://server1/page.html, JS can call the applet.
6) In another browser tab, open https://server2/page.html, JS can also call the applet.
7) Close and reopen browser and repeat steps 5 and 6 in reverse order, JS in page from neither server2 nor server1 can call the applet.

There are also DNS lookups for server names observable when accessing the applet, even in the scenario behind proxy server (DNS lookups for external names make no sense there).

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JS on page from server1 should call applet, JS on page from server2 should not call the applet, regardless of the order.
ACTUAL -
see steps 6 and 7

ERROR MESSAGES/STACK TRACES THAT OCCUR :
The problem seems to be due to the improper URL comparison algortihm used. With attached debugger and breakpoint set to java.net.InetAddress.getByName, the stack shows URL comparison done by java.net.URL (use of java.net.URI instead would solve the problem completely):

"Applet 1 LiveConnect Worker Thread"
java.net.InetAddress.getByName(InetAddress.java:1048)
java.net.URLStreamHandler.getHostAddress(URLStreamHandler.java:437)
java.net.URLStreamHandler.hashCode(URLStreamHandler.java:354)
java.net.URL.hashCode(URL.java:877)
java.util.HashMap.hash(HashMap.java:366)
java.util.HashMap.getEntry(HashMap.java:466)
java.util.HashMap.get(HashMap.java:421)
com.sun.deploy.security.CPCallbackHandler.isJSCallerInWhiteList
com.sun.deploy.security.CPCallbackHandler.access$300
com.sun.deploy.security.CPCallbackHandler$ParentCallback.checkJS2JavaAccess
com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$200
com.sun.deploy.security.CPCallbackHandler.checkUntrustedAccess
sun.plugin2.applet.Plugin2ClassLoader.checkUntrustedAccess
sun.plugin2.applet.Plugin2Manager.checkUntrustedAccess
sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo.isLiveconnectCallAllowed
sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo.doObjectOp
sun.plugin2.main.client.LiveConnectSupport$PerAppletInfo$LiveConnectWorker.run
java.lang.Thread.run(Thread.java:744)


REPRODUCIBILITY :
This bug can be reproduced always.