An unspecified vulnerability in Java SE related to the Hotspot component could allow an unauthenticated attacker to cause low confidentiality impact, low integrity impact, and no availability impact.

An unspecified vulnerability in Java SE could allow an unauthenticated attacker to obtain sensitive information resulting in a low confidentiality impact using unknown attack vectors.

An unspecified vulnerability in Java SE related to the Libraries component could allow an unauthenticated attacker to cause no confidentiality impact, low integrity impact, and no availability impact.

An unspecified vulnerability in Java SE related to the Libraries component could allow an unauthenticated attacker to obtain sensitive information resulting in a low confidentiality impact using unknown attack vectors.

An unspecified vulnerability in Java SE related to the JNDI component could allow an unauthenticated attacker to obtain sensitive information resulting in a low confidentiality impact using unknown attack vectors.

An unspecified vulnerability in Java SE related to the Serialization component could allow an unauthenticated attacker to cause a denial of service resulting in a low availability impact using unknown attack vectors.

A flaw was discovered in the jetty-server, where if an exception is thrown from the SessionListener#sessionDestroyed() method, then the session ID is not invalidated in the session ID manager. On deployments with clustered sessions and multiple contexts, this could result in a session not being invalidated and a shared-computer application being left logged in. The highest threat from this vulnerability is to data confidentiality and integrity.

A specially crafted request could have crashed the Apache HTTP Server prior to version 2.4.30, due to an out of bound access after a size limit is reached by reading the HTTP header. This vulnerability is considered very hard if not impossible to trigger in non-debug mode (both log and build level), so it is classified as low risk for common server usage.

Versions Affected: httpd 2.0.1 to 2.4.29

External references:

https://httpd.apache.org/security/vulnerabilities24.html

A specially crafted HTTP request header could have crashed the Apache HTTP Server prior to version 2.4.30 due to an out of bound read while preparing data to be cached in shared memory. It could be used as a Denial of Service attack against users of modcachesocache. The vulnerability is considered as low risk since modcachesocache is not widely used, modcachedisk is not concerned by this vulnerability.

Apache HTTP Server (httpd) through version 2.4.29 has a vulnerability in the handling of HTTP session headers in modsession. When modsession is configured to forward its session data to CGI applications (SessionEnv on, not the default), a remote user may influence their content by using a "Session" header.

Upstream Advisory:

https://httpd.apache.org/security/vulnerabilities24.html

Upstream Patch:

https://svn.apache.org/viewvc?view=revision&sortby=log&revision=1824477

In Apache HTTP Server 2.4 release 2.4.37 and prior, modsession checks the session expiry time before decoding the session. This causes session expiry time to be ignored for modsessioncookie sessions since the expiry time is loaded when the session is decoded.

A flaw was found in HTTP/2 (modhttp2) connections in Apache HTTP Server httpd 2.4.17 to 2.4.37. A DoS can be triggered by sending request bodies in a slow loris way to plain resources, the h2 stream for that request unnecessarily occupied a server thread cleaning up that incoming data.

References: https://seclists.org/oss-sec/2019/q1/80 https://httpd.apache.org/security/vulnerabilities24.html

In Apache httpd 2.4.0 to 2.4.29, the expression specified in <FilesMatch> could match '$' to a newline character in a malicious filename, rather than matching only the end of the filename. This could be exploited in environments where uploads of some files are are externally blocked, but only by matching the trailing portion of the filename.

In Apache httpd 2.0.23 to 2.0.65, 2.2.0 to 2.2.34, and 2.4.0 to 2.4.29, modauthnzldap, if configured with AuthLDAPCharsetConfig, uses the Accept-Language header value to lookup the right charset encoding when verifying the user's credentials. If the header value is not present in the charset conversion table, a fallback mechanism is used to truncate it to a two characters value to allow a quick retry (for example, 'en-US' is truncated to 'en'). A header value of less than two characters forces an out of bound write of one NUL byte to a memory location that is not part of the string. In the worst case, quite unlikely, the process would crash which could be used as a Denial of Service attack. In the more likely case, this memory is already reserved for future use and the issue has no effect at all.

Eclipse Jetty could allow a remote attacker to obtain sensitive information, caused by improper input validation by the default compliance mode. By sending specially-crafted requests with URIs that contain %2e or %2e%2e segments, an attacker could exploit this vulnerability to access protected resources within the WEB-INF directory, and use this information to launch further attacks against the affected system.

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

Eclipse Jetty could allow a remote authenticated attacker to obtain sensitive information, caused by a flaw when the ${jetty.base} directory or the ${jetty.base}/webapps directory is a symlink. By sending a specially-crafted request, an attacker could exploit this vulnerability to obtain webapp directory contents information, and use this information to launch further attacks against the affected system.

Eclipse Jetty is vulnerable to HTTP request smuggling, caused by a flaw when handling more than one Content-Length headers. By sending a specially-crafted request, an attacker could exploit this vulnerability to poison the web cache, bypass web application firewall protection, and conduct XSS attacks.

Eclipse Jetty is vulnerable to HTTP request smuggling, caused by improper handling of Chunked Transfer-Encoding chunk size. By sending a specially-crafted request, an attacker could exploit this vulnerability to poison the web cache, bypass web application firewall protection, and conduct XSS attacks.

Last updated 25 August 2025

An unspecified vulnerability in Java SE related to the Libraries component could allow an unauthenticated attacker to cause no confidentiality impact, low integrity impact, and no availability impact.

Last updated 25 August 2025

Last updated 25 August 2025

Oracle Java SE 8u161 and 9.0.4 fixes an unspecified vulnerability in the Installer component (CVE-2018-2627). Upstream has CVSS scored this issue as: 7.5/CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H

External Reference:

http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html#AppendixJAVA

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.

Oracle Java SE 7u171, 8u161, and 9.0.4 fixes an unspecified vulnerability in the JavaFX component (CVE-2018-2581). Upstream has CVSS scored this issue as: 4.7/CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N

External Reference:

http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html#AppendixJAVA

Oracle Java SE 8u161 and 9.0.4 fixes an unspecified vulnerability in the Deployment component (CVE-2018-2638). Upstream has CVSS scored this issue as: 8.3/CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H

External Reference:

http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html#AppendixJAVA