A flaw was found Go's net/http package. Servers using ReverseProxy from net/http in the Go standard library are vulnerable to a data race that results in a denial of service. The highest threat from this vulnerability is to system availability.
A flaw detected in golang: crypto/elliptic, in which P-224 keys as generated can return incorrect inputs, reducing the strength of the cryptography. The highest threat from this vulnerability is confidentiality and integrity.
An unspecified vulnerability in Java SE related to the JNDI 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 cause no confidentiality impact, low integrity impact, and no availability impact.
An unspecified vulnerability in Java SE related to the JAXP 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 found in the way the BMPImageReader class implementation in the ImageIO component of OpenJDK handled memory allocations when processing uncompressed BMP images. A specially-crafted BMP image with a small size could cause a Java application to allocate an excessive amount of memory and possibly terminate on out-of-memory condition.
A flaw was found in the SSL logger implementation in the JSSE component of OpenJDK. A malicious client could cause a Java application acting as TLS server to raise an unexpected exception during TLS handshake.
An unspecified vulnerability in Java SE related to the JSSE component could allow an unauthenticated attacker to obtain sensitive information resulting in a high confidentiality impact using unknown attack vectors.
It was discovered that the Kerberos protocol implementation in the Libraries component of OpenJDK did not correctly report subject principals when using Kerberos Constrained Delegation. This could lead to the use of wrong Kerberos tickets.
A flaw was found in the way the Keytool component of OpenJDK handled X.509 certificates with validity period ending too far in the future, after year 9999. When such certificates were imported into a keystore, they could cause corruption of the keystore.
A flaw was found in the way the RTFReader class implementation in the Swing component of OpenJDK handled style keyword parameters. A specially crafted Rich Text Format (RTF) file could cause a Java application using RTFReader to allocate an excessive ammount of memory and possibly terminate on out-of-memory condition.
An inifinte loop flaw was found in the HttpsServer class implementation in the JSSE component of OpenJDK. A remote attacker could possibly use this flaw to cause a Java application implementing HTTPS server functionality to loop during the TLS session closing and consume an excessive amount of CPU time.
A flaw was found in the way the RTFParser class implementation in the Swing component of OpenJDK handled memory allocations. A specially crafted Rich Text Format (RTF) file could cause a Java application using RTFParser to allocate an excessive amount of memory and possibly terminate on out-of-memory condition.
A CRLF injection flaw was found in the Lightweight HTTP Server component of OpenJDK. The HttpServer implementation did not restrict the use of CR and LF characters in values for HTTP headers, possibly allowing HTTP response splitting attacks.
A flaw was found in the way the HashMap and the HashSet classes implementations in the Utility component of OpenJDK validated the load factor value during deserialization. A specially crafted serialized data stream could cause a Java application to allocate an excessive amount of memory and possibly terminate on out-of-memory condition when deserialized.
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.
A flaw was found in the way the TLS implementation in the JSSE component of OpenJDK re-used single null TLS sessions for new TLS connections. A remote attacker could possibly use this flaw to impact availability of a Java application providing TLS server.
An infinite loop flaw was found in the RIFF (Resource Interchange File Format) file format reader in the Sound component of OpenJDK. A specially crafted RIFF file could cause a Java application to enter an infinite loop while reading the RIFF file.
A certificate verification flaw was found in the JSSE component of OpenJDK. No check was preformed during the TLS session resumption to ensure that the same endpoint identification algorithm had been used when originally opening the session as was required when resuming the session. In certain cases, this could lead to having TLS connection established without required server identity verification.
A flaw was found in Apache Tomcat. When serving resources from a network location using the NTFS file system, it was possible to bypass security constraints and view the source code for JSPs in some configurations. The root cause was the unexpected behavior of the JRE API File.getCanonicalPath(), which was caused by the inconsistent behavior of the Windows API (FindFirstFileW) in some circumstances. The highest threat from this vulnerability is to confidentiality.
Pivotal Spring Framework is vulnerable to cross-site tracing, caused by a flaw in the HiddenHttpMethodFilter in Spring MVC. By persuading a victim to visit a specially-crafted Web site, an attacker could exploit this vulnerability to cause the victim's browser to invoke a TRACE request to return sensitive header information including cookies or authentication data from third-party domains.
Apache Tomcat is vulnerable to HTTP request smuggling, caused by a flaw when handling unusual Transfer-Encoding HTTP header. 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.
Impact Accepting the value of various Text options of the Datepicker widget from untrusted sources may execute untrusted code. For example, initializing the datepicker in the following way: js $( "#datepicker" ).datepicker( { showButtonPanel: true, showOn: "both", closeText: "<script>doEvilThing( 'closeText XSS' )</script>", currentText: "<script>doEvilThing( 'currentText XSS' )</script>", prevText: "<script>doEvilThing( 'prevText XSS' )</script>", nextText: "<script>doEvilThing( 'nextText XSS' )</script>", buttonText: "<script>doEvilThing( 'buttonText XSS' )</script>", appendText: "<script>doEvilThing( 'appendText XSS' )</script>", } ); will call doEvilThing with 6 different parameters coming from all Text options.
Patches The issue is fixed in jQuery UI 1.13.0. The values passed to various Text options are now always treated as pure text, not HTML.
Workarounds A workaround is to not accept the value of the Text options from untrusted sources.
For more information If you have any questions or comments about this advisory, search for a relevant issue in the jQuery UI repo. If you don't find an answer, open a new issue.
Impact Accepting the value of the altField option of the Datepicker widget from untrusted sources may execute untrusted code. For example, initializing the datepicker in the following way: js $( "#datepicker" ).datepicker( { altField: "<img onerror='doEvilThing()' src='/404' />", } ); will call the doEvilThing function.
Patches The issue is fixed in jQuery UI 1.13.0. Any string value passed to the altField option is now treated as a CSS selector.
Workarounds A workaround is to not accept the value of the altField option from untrusted sources.
For more information If you have any questions or comments about this advisory, search for a relevant issue in the jQuery UI repo. If you don't find an answer, open a new issue.
Apache Tomcat 10.0.0-M1 to 10.0.6, 9.0.0.M1 to 9.0.46 and 8.5.0 to 8.5.66 did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility to request smuggling when used with a reverse proxy. Specifically: - Tomcat incorrectly ignored the transfer encoding header if the client declared it would only accept an HTTP/1.0 response; - Tomcat honoured the identify encoding; and - Tomcat did not ensure that, if present, the chunked encoding was the final encoding.
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
DISPUTED Unbound before 1.9.5 allows configuration injection in createunboundadservers.sh upon a successful man-in-the-middle attack against a cleartext HTTP session. NOTE: The vendor does not consider this a vulnerability of the Unbound software. createunboundadservers.sh is a contributed script from the community that facilitates automatic configuration creation. It is not part of the Unbound installation.
A flaw was found in the Linux kernel. A local attacker, able to inject conntrack netlink configuration, could overflow a local buffer causing crashes or triggering the use of incorrect protocol numbers in ctnetlinkparsetuplefilter in net/netfilter/nfconntracknetlink.c. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
Fixed bug (Use-after-free in exif parsing under memory sanitizer). (CVE-2019-11050)