Tener múltiples JRE en un sistema no es en sí mismo un riesgo, pero existe el riesgo de que puedan ser invocados por código no confiable.
Por lo tanto, es probable que la clave de esta configuración sea garantizar que los JRE desactualizados solo puedan ser invocados por la aplicación que lo necesita y no por ningún código no confiable.
Exactamente cómo lograr esto depende de la aplicación que necesita para permitir el uso de. Si se trata de una aplicación cliente gruesa, instale el JRE obsoleto en el directorio de inicio de las aplicaciones y asegúrese de que cualquier variable de entorno (como JAVA_HOME) que dirija los programas a JRE específicos no apunte a ello, sería de ayuda.
El elemento más crítico en términos de riesgo probable es garantizar que el complemento del navegador Java para la versión vulnerable no esté expuesto a Internet. Hay una gran cantidad de sitios / explotaciones maliciosas que pueden atacar esa debilidad, por lo que es una de evitar.
Si su aplicación de negocios. necesita el complemento del navegador Java, entonces las cosas se vuelven más difíciles de hacer con menos riesgo. Aquí, yo diría que sus opciones son para asegurar que el navegador con el complemento Java obsoleto solo sea utilizable para acceder a la aplicación heredada (por ejemplo, forzar un proxy y configurarlo en uno que no pueda acceder a sitios basados en Internet), o para proporcionar un entorno virtual con el navegador / complemento Java disponible y otra vez asegurarse de que el entorno no pueda acceder a Internet.
Con cualquiera de estas soluciones, aún existe el riesgo de que un atacante encuentre la manera de invocar al JRE vulnerable, pero al restringir su uso, puede reducir el nivel de riesgo.