Certain business applications or legacy software require running older versions of the Java Runtime Environment on client systems, e.g. JRE6 or 7 rather than or in addition to 8.

Assuming that upgrading the application is not an option, is my only option to install an unsafe JRE?

If so, what are the potential risks and is there any way to mitigate them?

Note: I am asking with client machines in mind but answers addressing the security implications on servers are welcome.

  • JREs that don't meet the current security baseline may have known non-mobile code vulnerabilities, such as TLS/SSL implementation flaws. Commented Apr 14, 2015 at 14:31

1 Answer 1


Having multiple JREs on a system isn't in and of itself a risk, but the risk that they might be invoked by untrusted code is present.

So the key to this setup is likely to be ensuring that the outdated JREs can only be invoked by the application that you need it to and not by any untrusted code.

Exactly how you achieve this depends on the application that you need to allow the use of. If it's a thick client app then installing the outdated JRE in the applications home directory and ensuring that any environment variables (like JAVA_HOME) that direct programs to specific JREs are not pointing at it would help.

The most critical element in terms of likely risk is ensuring that the Java browser plugin for the vulnerable version is not exposed to the Internet. There are a large number of malicious sites/exploits which can attack that weakness, so it's one to avoid.

If your business app. needs the Java browser plugin then things get harder to do with less risk. Here I'd say your choices are either to ensure that the browser with the outdated Java plugin is only usable for access to the legacy application (e.g. force a proxy and set it to one that can't get to Internet based sites), or to provide a Virtual environment with the browser/Java plugin made available and again make sure that environment can't access the Internet.

With any of these solutions there is still a risk that an attacker will find a way to invoke the vulnerable JRE but by restricting the use of it, you can reduce the level of risk.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .