CVE-2020-27216

Local Temp Directory Hijacking Vulnerability

[jetty-distribution]$ java -Djava.io.tmpdir=/var/web/work -jar start.jar

<Configure class="org.eclipse.jetty.webapp.WebAppContext">
  <Set name="contextPath"><Property name="foo"/></Set>
  <Set name="war">/var/web/webapps/foo.war</Set>
  <Set name="tempDirectory">/var/web/work/foo</Set>
</Configure>

// ensure file will always be unique by appending random digits
tmpDir = File.createTempFile(temp, ".dir", parent); // Attacker knows the full path of the file that will be generated
// delete the file that was created
tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty.
// and make a directory of the same name
// SECURITY VULNERABILITY: Race Condition! - Attacker beats Jetty and now owns this directory
tmpDir.mkdirs();

On Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability.

Additionally, any user code uses of WebAppContext::getTempDirectory would similarly be vulnerable.

Additionally, any user application code using the ServletContext attribute for the tempdir will also be impacted.
See: https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletContext.html#TEMPDIR

For example:

import java.io.File;
import java.io.IOException;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class ExampleServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        File tempDir = (File)getServletContext().getAttribute(ServletContext.TEMPDIR); // Potentially compromised
        // do something with that temp dir
    }
}

Example: The JSP library itself will use the container temp directory for compiling the JSP source into Java classes before executing them.

CVE-2020-27216 has a CVSS score of 7.0 (High). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (9.4.33, 10.0.0.beta3, 11.0.0.beta3, 9.4.33.v20201020); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

Fixes were applied to the 9.4.x branch with:

• https://github.com/eclipse/jetty.project/commit/53e0e0e9b25a6309bf24ee3b10984f4145701edb
• https://github.com/eclipse/jetty.project/commit/9ad6beb80543b392c91653f6bfce233fc75b9d5f

These will be included in releases: 9.4.33, 10.0.0.beta3, 11.0.0.beta3

1. What is CVE-2020-27216? CVE-2020-27216 is a high-severity security vulnerability in org.mortbay.jetty:jetty-webapp (maven), affecting versions < 9.4.33. It is fixed in 9.4.33, 10.0.0.beta3, 11.0.0.beta3, 9.4.33.v20201020.
2. How severe is CVE-2020-27216? CVE-2020-27216 has a CVSS score of 7.0 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which packages are affected by CVE-2020-27216?
   • org.mortbay.jetty:jetty-webapp (maven) (versions < 9.4.33)
   • org.eclipse.jetty:jetty-webapp (maven) (versions >= 10.0.0.beta1, <= 10.0.0.beta2)
4. Is there a fix for CVE-2020-27216? Yes. CVE-2020-27216 is fixed in 9.4.33, 10.0.0.beta3, 11.0.0.beta3, 9.4.33.v20201020. Upgrade to this version or later.
5. Is CVE-2020-27216 exploitable, and should I be worried? Whether CVE-2020-27216 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2020-27216 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2020-27216?
   • Upgrade org.mortbay.jetty:jetty-webapp to 9.4.33 or later
   • Upgrade org.eclipse.jetty:jetty-webapp to 10.0.0.beta3 or later
   • Upgrade org.mortbay.jetty:jetty-webapp to 10.0.0.beta3 or later
   • Upgrade org.eclipse.jetty:jetty-webapp to 11.0.0.beta3 or later
   • Upgrade org.mortbay.jetty:jetty-webapp to 11.0.0.beta3 or later
   • Upgrade org.eclipse.jetty:jetty-webapp to 9.4.33.v20201020 or later