展现原始漏洞的代码样例，目标类的ClassLoader并没有进行检查；来源：Security Explorations。
Oracle在2013年9月提供了一个修正，作为Java 7u40的一部分，包含了类可见性的检查，它会对比预期类型和传入类型的ClassLoader，对比方式如下：
如果两个ClassLoader相同的话，那么按照定义这两个类型是完全兼容的；
如果其中一个ClassLoader是另一个ClassLoader的父加载器，那么它认为这两个类是通过正常的ClassLoader层级结构加载的，因此将其视为相等是安全的。
在第二项检查中，Security Explorations发现exploit稍加修改就可能继续有效。首先，用于仿造类的自定义ClassLoader将目标ClassLoader设置为它的父类加载器，这可以通过API以参数的方式进行设置：
URLClassLoader lookup_CL = URLClassLoader.newInstance(urlArray, member_CL);
通过该机制将自定义的ClassLoader作为等级结构的一部分，来源：Security Explorations。
然后，鉴于ClassLoader的默认行为是将加载类的任务委托给它的父加载器，攻击者就需要确保父ClassLoader无法加载到这个类，这样他们自定义的ClassLoader就能发挥作用了。借助Java以网络方法加载类的过程，这种攻击模式得到了印证：如果这个类通过URL位置的方式来进行定义的话，父ClassLoader将会试图连接相关的服务器并获取这个类的代码，此时，预先构建好的HTTP服务器可以返回404 NOT FOUND错误，让父ClassLoader加载这个类出现失败，因此就会将控制权转移给自定义的ClassLoader。
通过自定义的HTTP服务器，强制父ClassLoader加载类失败之后的代码流，来源：Security Explorations。
当这个缺陷2016年3月重新爆出时，当时最新的可用版本是8u74，这个版本被证明是有漏洞的，Oracle在8u77中为其提供了修正。但是，在8u77的发布说明中，这个漏洞依然描述为“会影响桌面设备上，Web浏览器中所运行的JavaSE[并且]不会影响到Java部署环境，比如典型的服务器或独立部署的桌面应用”，但是事实证明，它还是会影响服务器配置以及Google App Engine的Java环境。
修正：2016年4月29日
本文错误地认为这个漏洞在8u77、8u91和8u92版本中依然存在，实际上，在8u77中它已经得到了修正。在8u77的发布说明中将其描述为对CVE-2016-0636的修正，具体描述是这样的“未指明的漏洞[...]借助Hotspot子组件中未知的感染内容”并且没有包含对本文中所提及的CVE-2013-5838的明确引用。但是，Security Explorations指出 CVE-2016-0636是针对Issue 69的一个CVE编号，而Issue 69是他们自己代指最初CVE-2013-5838的一种方式。（在本文英文原文的评论区，讨论了该问题解决的相关过程，感兴趣的读者可以访问原文查看。——译者注）
查看英文原文：Vulnerability in Java Reflection Library Fixed after 30 Months