...
Classes that have the same defining class loader exist in the same namespace but may have different privileges, depending on the security policy. Security vulnerabilities can arise if the trusted code coexists with untrusted code, and both have the same defining class loader. This is because untrusted code can freely access members of the trusted code depending on their accessibility. If the trusted code uses any of the tabulated APIs, no security manager checks are carried out (with the exception of loadLibrary).
Sometimes untrusted code is loaded by a class loader instance that is different from the one used to load the trusted code. Security vulnerabilities can arise if the untrusted code's class loader delegates to the trusted code's class loader. In the absence of such a delegation relationship, the class loaders ensure namespace separation and disallow untrusted code from observing members or invoking methods belonging to the trusted code.
Consider for example, untrusted code that is attempting to load a privileged class. Its class loader is permitted to delegate the class loading to the trusted class's class loader. This is a problem as untrusted code's class loader may not have the permission to load the particular class. Also, if the trusted code accepts tainted inputs, more privileged or even malicious classes may be loaded on behalf of untrusted code.
...