Last updated 24 July 2024

A flaw was found in Undertow. A regression in the fix for CVE-2020-10687 was found. HTTP request smuggling related to CVE-2017-2666 is possible against HTTP/1.x and HTTP/2 due to permitting invalid characters in an HTTP request. This flaw allows an attacker to poison a web-cache, perform an XSS attack, or obtain sensitive information from request other than their own. The highest threat from this vulnerability is to data confidentiality and integrity.

A vulnerability was found in Hibernate-Validator. The SafeHtml validator annotation fails to properly sanitize payloads consisting of potentially malicious code in HTML comments and instructions. This vulnerability can result in an XSS attack.

In Spring Security, versions 5.7.x prior to 5.7.8, versions 5.8.x prior to 5.8.3, and versions 6.0.x prior to 6.0.3, the logout support does not properly clean the security context if using serialized versions. Additionally, it is not possible to explicitly save an empty security context to the HttpSessionSecurityContextRepository. This vulnerability can keep users authenticated even after they performed logout. Users of affected versions should apply the following mitigation. 5.7.x users should upgrade to 5.7.8. 5.8.x users should upgrade to 5.8.3. 6.0.x users should upgrade to 6.0.3.

In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "limited" path traversal), if the calling code would use the result to construct a path value.

References:

https://www.openwall.com/lists/oss-security/2021/04/12/1 https://issues.apache.org/jira/browse/IO-556

Fasterxml Jackson version Before 2.9.8 contains a CWE-20: Improper Input Validation vulnerability in Jackson-Modules-Java8 that can result in Causes a denial-of-service (DoS). This attack appear to be exploitable via The victim deserializes malicious input, specifically very large values in the nanoseconds field of a time value. This vulnerability appears to have been fixed in 2.9.8.

A vulnerability was found in OpenSSL 1.0.2. When an application encounters a fatal protocol error and then calls SSLshutdown() twice, OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. This difference in behaviour can be detected by a remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Also the application must call SSLshutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). AEAD ciphersuites are not impacted. This issue does not impact OpenSSL 1.1.1 or 1.1.0.

Upstream bug: https://www.openssl.org/news/secadv/20190226.txt

Upstream Patch: https://github.com/openssl/openssl/commit/e9bbefbf0f24c57645e7ad6a5a71ae649d18ac8e

Impact Passing HTML containing <option> elements from untrusted sources - even after sanitizing them - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code.

Patches This problem is patched in jQuery 3.5.0.

Workarounds To workaround this issue without upgrading, use DOMPurify with its SAFEFORJQUERY option to sanitize the HTML string before passing it to a jQuery method.

References https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/

For more information If you have any questions or comments about this advisory, search for a relevant issue in the jQuery repo. If you don't find an answer, open a new issue.

A flaw was found in the Apache Xerces Java (XercesJ) XML parser when handling specially crafted XML document payloads. This issue causes the XercesJ XML parser to wait in an infinite loop, which may consume system resources for a prolonged duration, leading to a denial of service condition.

It was discovered that the XMLEntityManager class implementation in the JAXP component of OpenJDK did not properly perform access checks. A Java application using SAX XML parser in certain configuration could be tricked into disclosing information when parsing a specially-crafted XML file.

A flaw was found in the way the XMLEntityScanner and XML11EntityScanner classes in the JAXP component of OpenJDK handled and normalized newlines in XML entities. A specially-crafted XML document could cause a Java application to enter an infinite loop when parsed.

Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with " (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: DISPLAYLANGUAGE="b; JSESSIONID=1337; c=d" will be parsed as one cookie, with the name DISPLAYLANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAYLANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAYLANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.

Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-2c6g-pfx3-w7h8. This link is maintained to preserve external references.

Original Description In RESTEasy the insecure File.createTempFile() is used in the DataSourceProvider, FileProvider and Mime4JWorkaround classes which creates temp files with insecure permissions that could be read by a local user.

In Spring Framework versions 5.3.0 - 5.3.38 and older unsupported versions, it is possible for a user to provide a specially crafted Spring Expression Language (SpEL) expression that may cause a denial of service (DoS) condition.

Specifically, an application is vulnerable when the following is true:

The application evaluates user-supplied SpEL expressions.

Apache HttpClient versions prior to version 4.5.13 and 5.0.3 can misinterpret malformed authority component in request URIs passed to the library as java.net.URI object and pick the wrong target host for request execution.

Last updated 5 May 2025

Impact

When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled.

The CVSSv3.1 score of this vulnerability is calculated to be a 6.2/10

Vulnerability Details

On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems.

The method File.createTempFile on unix-like systems creates a random file, but, by default will create this file with the permissions -rw-r--r--. Thus, if sensitive information is written to this file, other local users can read this information.

This is the case in netty's AbstractDiskHttpData is vulnerable.

https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101

AbstractDiskHttpData is used as a part of the DefaultHttpDataFactory class which is used by HttpPostRequestDecoder / HttpPostMultiPartRequestDecoder.

You may be affected by this vulnerability your project contains the following code patterns:

java channelPipeline.addLast(new HttpPostRequestDecoder(...));

java channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...));

Patches

This has been patched in version 4.1.59.Final.

Workarounds

Specify your own java.io.tmpdir when you start the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.

References

- CWE-378: Creation of Temporary File With Insecure Permissions - CWE-379: Creation of Temporary File in Directory with Insecure Permissions

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 If you have any questions or comments about this advisory: Open an issue in netty Email us here

Original Report

Hi Netty Security Team, I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: https://lgtm.com/query/7723301787255288599/ Netty contains three local information disclosure vulnerabilities, so far as I can tell. One is here, where the private key for the certificate is written to a temporary file. https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 One is here, where the certificate is written to a temporary file. https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 All of these vulnerabilities exist because File.createTempFile(String, String) will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: -rw-r--r--, thus, any other local user on that system can read the contents of that file. Impacted OS: - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. Mitigation. Moving to the Files API instead will fix this vulnerability. https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- This API will explicitly set the posix file permissions to something safe, by default. I recently disclosed a similar vulnerability in JUnit 4: https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. https://github.com/netty/netty/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

Accessibility. A logging issue was addressed with improved data redaction.

A shortcoming in the HMEF package of poi-scratchpad (Apache POI) allows an attacker to cause an Out of Memory exception. This package is used to read TNEF files (Microsoft Outlook and Microsoft Exchange Server). If an application uses poi-scratchpad to parse TNEF files and the application allows untrusted users to supply them, then a carefully crafted file can cause an Out of Memory exception. This issue affects poi-scratchpad version 5.2.0 and prior versions. Users are recommended to upgrade to poi-scratchpad 5.2.1.

GStreamer before 1.18.4 may perform an out-of-bounds read when handling certain ID3v2 tags.

Last updated 18 August 2025

Last updated 18 August 2025

Last updated 18 August 2025

Last updated 18 August 2025

It was discovered that the Kerberos implementation in the Security component of OpenJDK used RSA-MD5 checksum in Ticket Granting Service (TGS) requests even though MD5 algorithm is no longer considered safe for such use case. A remote attacker could possibly use this flaw to manipulate TGS requests.

A flaw was found in the URL class implementation in the Networking component of OpenJDK. An incorrect check to determine if a URLStreamHandler is builtin or not can lead to incorrect URL normalization in certain cases.

Last updated 18 August 2025

Last updated 18 August 2025

Last updated 18 August 2025

Last updated 18 August 2025