Apache Tomcat versions 7.0.0 to 7.0.84, 8.0.0.RC1 to 8.0.49 and 8.5.0 to 8.5.27 only apply security constraints defined by Servlets once those Servlets are loaded. Depending on the order that Servlets load, some security constraints may not be applied leading to unintended resource exposure.

External References:

https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.85 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.50 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.28

Upstream Fixes:

Tomcat 7.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1823322 http://svn.apache.org/viewvc?view=rev&rev=1824360

Tomcat 8.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1823319 http://svn.apache.org/viewvc?view=rev&rev=1824359

Tomcat 8.5.x:

http://svn.apache.org/viewvc?view=rev&rev=1823314 http://svn.apache.org/viewvc?view=rev&rev=1824358

Apache Tomcat versions 7.0.0 to 7.0.84, 8.0.0.RC1 to 8.0.49 and 8.5.0 to 8.5.27 does not properly handle the URL empty string ("") when used as part of a security constraint definition. This can lead to the security constraint being ignored, leading to unitended exposure of resources.

External References:

https://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.85 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.50 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.28

Upstream Bug Report:

https://bz.apache.org/bugzilla/showbug.cgi?id=62067

Upstream Fixes:

Tomcat 7.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1823309

Tomcat 8.0.x:

http://svn.apache.org/viewvc?view=rev&rev=1814827

Tomcat 8.5.x:

http://svn.apache.org/viewvc?view=rev&rev=1823307

A flaw was found in Apache tomcat. When the default servlet returned a redirect to a directory (e.g. redirecting to /foo/ when the user requested /foo) a specially crafted URL could be used to cause the redirect to be generated to any URI of the attackers choice.

References:

https://lists.apache.org/thread.html/23134c9b5a23892a205dc140cdd8c9c0add233600f76b313dda6bd75@%3Cannounce.tomcat.apache.org%3E

An issue was discovered in libjpeg 9a and 9d. The allocsarray function in jmemmgr.c allows remote attackers to cause a denial of service (divide-by-zero error) via a crafted file.

Last updated 18 August 2025

It was discovered that the password-based encryption (PBE) implementation in the Libraries component of OpenJDK specified incorrect key length. This could lead to generation of keys that were weaker than expected in certain cases.

It was discovered that the JAXP component of OpenJDK did not properly count total size of the expanded general entities and therefore did not properly enforce the totalEntitySizeLimit limit. An attacker able to make a Java application parse a specially crafted XML file could use this flaw to make the application use and excessive amount of memory and possibly exit on out of memory condition.

JAXP XML parsing limits are described on the following page:

https://docs.oracle.com/javase/tutorial/jaxp/limits/limits.html

It was discovered that the RMIConnector and RMIConnectionImpl classes in the JMX component of OpenJDK could log sensitive information such as user passwords in its debug log, possibly leading the exposure of the information.

A flaw was found in the deserialization of the URL class in the Networking component of OpenJDK. Deserialization of the specially crafted data could result in creation of the URL object with an inconsistent state. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

A race condidition in systemd-coredump allows a local attacker to crash a SUID program and gain read access to the resulting core dump

It was discovered that the StAX XML parser in the JAXP component of OpenJDK could do certain DTD processing even when DTD support was disabled via the javax.xml.stream.supportDTD system property. A specially crafted XML document could cause a Java application using JAXP to consume an excessive amount of memory and CPU time when parsed.

It was discovered that the JAXP component of OpenJDK did not enforce the maximum XML name limit (jdk.xml.MaxXMLNameLimit) when parsing XML files. A specially crafted XML document could cause a Java application using JAXP to consume an excessive amount of memory and CPU time when parsed.

It was discovered that the RemoteObjectInvocationHandler class in the RMI component of OpenJDK did not check if object proxy is an instance of a proxy class and that it uses correct invocation handler. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions by gaining access to data that should by protected by the sandbox.

It was discovered that the AlgorithmChecker class in the Security component of OpenJDK failed to properly check if a certificate satisfies all defined constraints in certain cases. This could cause a Java application to accept an X.509 certificate which does not meet requirements of the policy defined in the java.security file.

A flaw was found in the way the IIOPInputStream class in the CORBA component of OpenJDK performed deserialization of String objects. An untrusted Java application or applet could use this flaw to crash the Java Virtual Machine.

An information disclosure flaw was found in the JAXP component of OpenJDK. An untrusted Java application or applet could use this flaw to get information about user home directory location (the content of the "user.dir" system property), hence bypassing certain Java sandbox restrictions.

It was discovered that the 2D component of OpenJDK could perform out of bounds access and possibly disclose portions of the Java Virtual Machine memory when processing specially crafted color profiles. The issue was caused by having bundled lcms2 code use fast floor() implementation. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

Andrea Palazzo reported the following problem affecting IcedTea-Web:

""" Using HTTPUrlConnection it is possible to set custom values for blacklisted headers, even if allowRestrictedHeaders is false, by supplying "Name:value" as name.

Also, if needed, trailing ":" could be stripped off using an array as header value. """

Acknowledgement:

Red Hat would like to thank Andrea Palazzo of Truel IT for reporting this issue.

It was discovered that the JAXP component of OpenJDK did not use efficient data structures to store data from parsed XML documents. A specially-crafted XML input could cause a Java application using JAXP to use an excessive amount of CPU time by e.g. triggering hash collisions.

It was discovered that the JGSS component of OpenJDK did not properly hide Kerberos realm information from all error exceptions when running under Security Manager. An untrusted Java application or applet could use this flaw to obtain certain information about the Kerberos configuration on the host where they were executed, bypassing certain Java sandbox restrictions.

Oracle Java SE 6u101, 7u85 and 8u51 fixes an unspecified vulnerability in the Deployment component (CVE-2015-2664). Upstream has CVSSv2 scored this issue as: 6.9/AV:L/AC:M/Au:N/C:C/I:C/A:C

External Reference:

http://www.oracle.com/technetwork/topics/security/cpujul2015-2367936.html#AppendixJAVA

Oracle Java SE 6u101, 7u85 and 8u51 fixes an unspecified vulnerability in the 2D component (CVE-2015-2637). Upstream has CVSSv2 scored this issue as: 5.0/AV:N/AC:L/Au:N/C:P/I:N/A:N

External Reference:

http://www.oracle.com/technetwork/topics/security/cpujul2015-2367936.html#AppendixJAVA

It was discovered that the JCE (Java Cryptography Extension) component in OpenJDK failed to use constant time comparisons in multiple cases. An attacker could possibly use these flaws to disclose sensitive information by measuring time used to perform operations using these non-constant time comparisons.

It was discovered that the RMIConnectionImpl class in the JMX component of OpenJDK failed to properly check code permissions when creating repository class loaders. An untrusted Java application or applet could use this flaw to read information access to which should be restricted by the Java sandbox, partially bypassing sandbox restrictions.

A flaw was found in expat. A stack exhaustion in doctype parsing could be triggered by a file with a large number of opening braces, resulting in a denial of service.

It was discovered that ICC profiles were not parsed correctly. An untrusted Java application or applet could possibly use this flaw to cause a denial of service.

A bug that allows linux kernel lockdown to be trivially bypassed using IMA.

The Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.5 and 1.19.x before 1.19.3 has a NULL pointer dereference in kdc/dotgsreq.c via a FAST inner body that lacks a server field.

Impact

Users who are using an HTTPS proxy to issue HTTPS requests and haven't configured their own SSLContext via proxyconfig. Only the default SSLContext is impacted.

Patches

urllib3 >=1.26.4 has the issue resolved. urllib3<1.26 is not impacted due to not supporting HTTPS requests via HTTPS proxies.

Workarounds

Upgrading is recommended as this is a minor release and not likely to break current usage.

Configuring an SSLContext with checkhostname=True and passing via proxyconfig instead of relying on the default SSLContext

For more information If you have any questions or comments about this advisory: Email us at sethmichaellarson@gmail.com

A flaw was found in curl. The flaw lies in how curl handles cached or pipelined responses that it receives from either a IMAP, POP3, SMTP or FTP server before the TLS upgrade using STARTTLS. In such a scenario curl even after upgrading to TLS would trust these cached responses treating them as valid and authenticated and use them. An attacker could potentially use this flaw to carry out a Man-In-The-Middle attack. The highest threat from this vulnerability is to data confidentiality.