We have a Java web application contained in an apache tomcat instance. JRE version is 7.0.51 and Tomcat version is 7.0.42.

Users have expressed their concerns about Java 7's support/updates being discontinued by oracle in April 2015 and has requested for the environment's Java version to be upgrade to version 8. However, by doing so, we are afraid that the application's behavior might change, as we have observed during coding and testing when one of the developers was using JRE 8 instead of 7. This might also mean that we would need to upgrade the 3rd party libraries we used such as OJDBC and even upgrade the Tomcat version.

My question are:

  1. What are the security concerns if we are to stick with an old JRE version?
  2. What can we do to mitigate the security concerns?
  3. Isn't it the responsibility of the web server's, load balancer's (and such) security features to prevent security issues for the Java versions they supposedly support?


All of you suggested that it's necessary to upgrade a server's Java version. However, this is a big and very complex application with lots of dependencies; upgrading would mean performing costly regression testing on the whole system. My additional questions are:

  1. Does the risk outweigh the incurred costs? Are the risks that great to justify additional testing and potential re-coding?
  2. How can a malicious attacker exploit an outdated Java version? My understanding is, services/ports that are directly communicating with external users are the only entry point to an internet-base attack (assume no internal attacks). Then, isn't it the job of the Operating System and services to ensure that there are no exploitable bugs?
  • Is this an external facing system?
    – Motivated
    Commented Nov 10, 2015 at 7:27
  • @Motivated yes it is Commented Nov 10, 2015 at 7:27
  • Depending on the urgency to patch, the threat model, etc, a consideration may be to look at leveraging managed services such as F5's Silverline offering. This will give you the window of opportunity to assess the risks, impact as well as look at updating to the latest version depending on whether you have test systems.
    – Motivated
    Commented Nov 10, 2015 at 7:47
  • 7u51 is Dec 2013, more than a year before the EOL; you should update to at least 7u80. J8 is designed to be upward compatible with very few exceptions, and for application (not applet) running on 8 vs 7 with no code change I've not noticed any material difference other than improvements in TLS and slightly different memory tuning; if you have specific differences that cause trouble or concern you could ask about them (probably SO but maybe here if security). Similarly old libraries and Tomcat should run fine on new Java, but maybe not the reverse. Commented Nov 11, 2015 at 0:48
  • @dave_thompson_085 7u51 was the latest version when coding started. For compatibility between Java 7 and 8, we tested one complex module that behaved entirely differently in Java 8, upon shallow investigation of the problem, this was probably due to the implementation changes in Java Regex Commented Nov 11, 2015 at 2:01

3 Answers 3


Given that your system is exposed to the internet, you should do all the tasks you mention in your question. Sooner or later an automated attack against Java 7 will be available, and bots will find your server.

  • 1
    and how will the "bots" exploit the system? Commented Nov 11, 2015 at 2:10
  • @user3367701: Typically they make a tailored http-request triggering the security hole. Commented Nov 11, 2015 at 8:25
  • @jknappen Could you please explain that? I am really not able to understand what you are saying. As far as i understand, you would need to put CODE/class/jar-Files to the Server to exploit a System via a JRE?
    – swe
    Commented Sep 20, 2017 at 8:00

One more point to consider when updating your Java installation (because you do want to keep it up to date) is that older versions are not removed by default.

There was a plan for oracle to actually upgrade Java and not only install a new version but it was not yet in place last time I checked (this is not the same as having auto updates).

The core problem behind this is that a malicious applet may require a specific version of java when it runs.

  • This question is not about applets?
    – swe
    Commented Sep 20, 2017 at 7:56

Let me answer your concerns point-wise assuming the Server you have is Internet-facing.

1) Running outdated JRE version is not recommended as many of the vulnerabilities can be remotely exploited both on client and server deployment and are having lower access complexity. Refer to Critical Patch Update listings for Oct'15 here http://www.oracle.com/technetwork/topics/security/cpuoct2015-2367953.html#AppendixJAVA

2)You should patch all you can, keeping the constraints you mentioned above in mind. While I recommend you start working on porting of your application in meanwhile to higher versions. The defenses at Network Perimeter like Firewall, IPS and WAF appliances can deter most of the risk till you are in process to port.

3)No, that responsibility lies with Oracle and they do release patches time to time. However many commercial Load-Balancers come with security component built-in to some extent. You can also think of Hardening your Tomcat if not already done. My point is fixing security holes at source is better than at next level.

  • 1
    It seems to me it's only a risk if a malicious user gets to run Java code in the server. But that would mean it has found exploits in the services accessible to the user, making the user capable of dropping Java payloads Commented Nov 11, 2015 at 2:12
  • Can I run a jar which will accept connections without any service in between? Moreover, if I am able to run an exploit using a web server to drop the payload, still it is vulnerable right? Commented Nov 11, 2015 at 5:01

You must log in to answer this question.

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