Last updated 25 August 2025
A flaw was found in Spring Security in combination with Spring Framework versions prior to 5.0.6 contains an authorization bypass when using method security. An unauthorized malicious user can gain unauthorized access to methods that should be restricted.
References: https://pivotal.io/security/cve-2018-1258
Apache Commons IO: Possible denial of service attack on untrusted input to XmlStreamReader
Impact 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: java 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.
CVSSv3.1 Evaluation
This vulnerability has been calculated to have a CVSSv3.1 score of 7.8/10 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Patches 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
Workarounds
A work around is to set a temporary directory, either for the server or the context, to a directory outside of the shared temporary file system. For recent releases, a temporary directory can be created simple by creating a directory called work in the ${jetty.base} directory (the parent directory of the webapps directory). Alternately the java temporary directory can be set with the System Property java.io.tmpdir. A more detailed description of how jetty selects a temporary directory is below.
The Jetty search order for finding a temporary directory is as follows:
1. If the WebAppContext has a temp directory specified), use it. 2. If the ServletContext has the javax.servlet.context.tempdir attribute set, and if directory exists, use it. 3. If a ${jetty.base}/work directory exists, use it (since Jetty 9.1) 4. If a ServletContext has the org.eclipse.jetty.webapp.basetempdir attribute set, and if the directory exists, use it. 5. Use System.getProperty("java.io.tmpdir") and use it.
Jetty will end traversal at the first successful step. To mitigate this vulnerability the directory must be set to one that is not writable by an attacker. To avoid information leakage, the directory should also not be readable by an attacker.
Setting a Jetty server temporary directory.
Choices 3 and 5 apply to the server level, and will impact all deployed webapps on the server.
For choice 3 just create that work directory underneath your ${jetty.base} and restart Jetty.
For choice 5, just specify your own java.io.tmpdir when you start the JVM for Jetty.
shell [jetty-distribution]$ java -Djava.io.tmpdir=/var/web/work -jar start.jar
Setting a Context specific temporary directory.
The rest of the choices require you to configure the context for that deployed webapp (seen as ${jetty.base}/webapps/<context>.xml)
Example (excluding the DTD which is version specific):
xml <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>
References - https://github.com/eclipse/jetty.project/issues/5451 - CWE-378: Creation of Temporary File With Insecure Permissions - CWE-379: Creation of Temporary File in Directory with Insecure Permissions - CodeQL Query PR To Detect Similar Vulnerabilities
Similar Vulnerabilities
Similar, but not the same.
- JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - Google Guava - https://github.com/google/guava/issues/4011 - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
For more information
The original report of this vulnerability is below:
On Thu, 15 Oct 2020 at 21:14, Jonathan Leitschuh <jonathan.leitschuh@gmail.com> wrote: Hi WebTide Security Team, I'm a security researcher writing some custom CodeQL queries to find Local Temporary Directory Hijacking Vulnerabilities. One of my queries flagged an issue in Jetty. https://lgtm.com/query/5615014766184643449/ I've recently been looking into security vulnerabilities involving the temporary directory because on unix-like systems, the system temporary directory is shared between all users. There exists a race condition between the deletion of the temporary file and the creation of the directory. java // 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(); https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L511-L518 In several cases the parent parameter will not be the system temporary directory. However, there is one case where it will be, as the last fallback. https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L467-L468 If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability. Would your team be willing to open a GitHub security advisory to continue the discussion and disclosure there? https://github.com/eclipse/jetty.project/security/advisories This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. Cheers, Jonathan Leitschuh
dom4j could allow a remote attacker to execute arbitrary code on the system, caused by improper input validation in multiple methods. By sending a specially-crafted XML content, an attacker could exploit this vulnerability to execute arbitrary code on the system.
Out-of-bounds Write vulnerability in Apache Commons Configuration.
Affected versions:
- Apache Commons Configuration 2.0 before 2.10.1
References:
https://www.cve.org/CVERecord?id=CVE-2024-29131 https://issues.apache.org/jira/browse/CONFIGURATION-840
Description Invalid HTTP/2 requests (for example, invalid URIs) are incorrectly handled by writing a blocking error response directly from the selector thread. If the client manages to exhaust the HTTP/2 flow control window, or TCP congest the connection, the selector thread will be blocked trying to write the error response. If this is repeated for all the selector threads, the server becomes unresponsive, causing the denial of service.
Impact A malicious client may render the server unresponsive.
Patches The fix is available in Jetty versions 9.4.47. 10.0.10, 11.0.10.
Workarounds No workaround available within Jetty itself. One possible workaround is to filter the requests before sending them to Jetty (for example in a proxy)
For more information If you have any questions or comments about this advisory: Email us at security@webtide.com.
A command injection vulnerability was found in Python 2.x and 3.x, specifically within the mailcap module. Mailcap core-module is based on the format documented in RFC 1524. The “findmatch()” function does not sanitise the second argument (filename). As a result, the legitimate command (that is used for opening the specified mime type) is concatenated with an arbitrary command, injected by an attacker.
A flaw was found in springframework in versions prior to 5.0.16, 5.1.13, and 5.2.3. A reflected file download (RFD) attack is possible when a "Content-Disposition" header is set in response to where the filename attribute is derived from user supplied input. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
Apache Struts contains a Remote Code Execution when using results with no namespace and it's upper actions have no or wildcard namespace. The same flaw exists when using a url tag with no value, action set, and it's upper actions have no or wildcard namespace.
libcurl-using applications can ask for a specific client certificate to be used in a transfer. This is done with the CURLOPTSSLCERT option (--cert with the command line tool).When libcurl is built to use the macOS native TLS library Secure Transport, an application can ask for the client certificate by name or with a file name - using the same option. If the name exists as a file, it will be used instead of by name.If the appliction runs with a current working directory that is writable by other users (like /tmp), a malicious user can create a file name with the same name as the app wants to use by name, and thereby trick the application to use the file based cert instead of the one referred to by name making libcurl send the wrong client certificate in the TLS connection handshake.
Impact When using SSL/TLS with Jetty, either with HTTP/1.1, HTTP/2, or WebSocket, the server may receive an invalid large (greater than 17408) TLS frame that is incorrectly handled, causing CPU resources to eventually reach 100% usage.
Workarounds
The problem can be worked around by compiling the following class: java package org.eclipse.jetty.server.ssl.fix6072;
import java.nio.ByteBuffer; import javax.net.ssl.SSLEngine; import javax.net.ssl.SSLEngineResult; import javax.net.ssl.SSLException; import javax.net.ssl.SSLHandshakeException;
import org.eclipse.jetty.io.EndPoint; import org.eclipse.jetty.io.ssl.SslConnection; import org.eclipse.jetty.server.Connector; import org.eclipse.jetty.server.SslConnectionFactory; import org.eclipse.jetty.util.BufferUtil; import org.eclipse.jetty.util.annotation.Name; import org.eclipse.jetty.util.ssl.SslContextFactory;
public class SpaceCheckingSslConnectionFactory extends SslConnectionFactory { public SpaceCheckingSslConnectionFactory(@Name("sslContextFactory") SslContextFactory factory, @Name("next") String nextProtocol) { super(factory, nextProtocol); }
@Override protected SslConnection newSslConnection(Connector connector, EndPoint endPoint, SSLEngine engine) { return new SslConnection(connector.getByteBufferPool(), connector.getExecutor(), endPoint, engine, isDirectBuffersForEncryption(), isDirectBuffersForDecryption()) { @Override protected SSLEngineResult unwrap(SSLEngine sslEngine, ByteBuffer input, ByteBuffer output) throws SSLException { SSLEngineResult results = super.unwrap(sslEngine, input, output);
if ((results.getStatus() == SSLEngineResult.Status.BUFFERUNDERFLOW || results.getStatus() == SSLEngineResult.Status.OK && results.bytesConsumed() == 0 && results.bytesProduced() == 0) && BufferUtil.space(input) == 0) { BufferUtil.clear(input); throw new SSLHandshakeException("Encrypted buffer max length exceeded"); } return results; } }; } } This class can be deployed by: + The resulting class file should be put into a jar file (eg sslfix6072.jar) + The jar file should be made available to the server. For a normal distribution this can be done by putting the file into ${jetty.base}/lib + Copy the file ${jetty.home}/modules/ssl.mod to ${jetty.base}/modules + Edit the ${jetty.base}/modules/ssl.mod file to have the following section:
[lib] lib/sslfix6072.jar
+ Copy the file ${jetty.home}/etc/jetty-https.xml and${jetty.home}/etc/jetty-http2.xml to ${jetty.base}/etc + Edit files ${jetty.base}/etc/jetty-https.xml and ${jetty.base}/etc/jetty-http2.xml, changing any reference of org.eclipse.jetty.server.SslConnectionFactory to org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory. For example: xml <Call name="addIfAbsentConnectionFactory"> <Arg> <New class="org.eclipse.jetty.server.ssl.fix6072.SpaceCheckingSslConnectionFactory"> <Arg name="next">http/1.1</Arg> <Arg name="sslContextFactory"><Ref refid="sslContextFactory"/></Arg> </New> </Arg> </Call> + Restart Jetty
A flaw was found in krb5. MIT Kerberos 5 allows unbounded recursion via an ASN.1-encoded Kerberos message because the lib/krb5/asn.1/asn1encode.c support for BER indefinite lengths lacks a recursion limit.
A flaw was found in curl. This flaw lies in the --ssl-reqd option or related settings in libcurl. Users specify this flag to upgrade to TLS when communicating with either IMAP, POP3 or a FTP server. An attacker controlling such servers could return a crafted response which could lead to curl client continue its operation without TLS encryption leading to data being transmitted in clear text over the network. The highest threat from this vulnerability is to data confidentiality.
In Spring Framework versions 5.2.0 - 5.2.8, 5.1.0 - 5.1.17, 5.0.0 - 5.0.18, 4.3.0 - 4.3.28, and older unsupported versions, the protections against RFD attacks from CVE-2015-5211 may be bypassed depending on the browser used through the use of a jsessionid path parameter.
A vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. However, the HSTS mechanism could be bypassed if the host name in the given URL first uses IDN characters that get replaced to ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop (U+002E) .. Then in a subsequent request, it does not detect the HSTS state and makes a clear text transfer. Because it would store the info IDN encoded but look for it IDN decoded.
Due to the formatting logic of the "console.table()" function it was not safe to allow user controlled input to be passed to the "properties" parameter while simultaneously passing a plain object with at least one property as the first parameter, which could be "proto". The prototype pollution has very limited control, in that it only allows an empty string to be assigned to numerical keys of the object prototype.Node.js >= 12.22.9, >= 14.18.3, >= 16.13.2, and >= 17.3.1 use a null protoype for the object these properties are being assigned to.
Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr. We recommend upgrading to version 3.15.0 or greater.
SnapCenter versions prior to 4.7 shipped without Content Security Policy (CSP) implemented which could allow certain types of attacks that otherwise would be prevented.
A flaw was found in nodejs. A denial of service is possible when the whitelist includes “localhost6”. When “localhost6” is not present in /etc/hosts, it is just an ordinary domain that is resolved via DNS over the network. If the attacker controls the victim's DNS server or can spoof its responses, the DNS rebinding protection can be bypassed by using the “localhost6” domain. As long as the attacker uses the “localhost6” domain, they can still apply the attack described in CVE-2018-7160.
SnapCenter versions 4.8 through 4.9 are susceptible to a vulnerability which may allow an authenticated SnapCenter Server user to become an admin user on a remote system where a SnapCenter plug-in has been installed.
Eclipse Jetty could allow a remote attacker to hijack a user's session, caused by a flaw in the FileSessionDataStore. An attacker could exploit this vulnerability to gain access to another user's session.
Internally libssl in OpenSSL calls X509verifycert() on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as SSLconnect() or SSLdohandshake()) to not indicate success and a subsequent call to SSLgeterror() to return the value SSLERRORWANTRETRYVERIFY. This return value is only supposed to be returned by OpenSSL if the application has previously called SSLCTXsetcertverifycallback(). Since most applications do not do this the SSLERRORWANTRETRYVERIFY return value from SSLgeterror() will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause X509verifycert() to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains. By combining the two issues an attacker could induce incorrect, application dependent behaviour. Fixed in OpenSSL 3.0.1 (Affected 3.0.0).
Last updated 18 August 2025
Vulnerability in the MySQL Connectors component of Oracle MySQL (subcomponent: Connector/Python). Supported versions that are affected are 8.0.13 and prior and 2.1.8 and prior. Easily exploitable vulnerability allows unauthenticated attacker with network access via TLS to compromise MySQL Connectors. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all MySQL Connectors accessible data as well as unauthorized access to critical data or complete access to all MySQL Connectors accessible data. CVSS 3.0 Base Score 8.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N).
Last updated 24 July 2024
Last updated 18 August 2025
Last updated 18 August 2025
Last updated 18 August 2025
Last updated 24 July 2024