An out-of-bounds read in cmstypes.c in TypeMLURead function was found, leading to heap memory leak triggered by crafted ICC profile.

Upstream patch:

https://github.com/mm2/Little-CMS/commit/5ca71a7bc18b6897ab21d815d15e218e204581e2

CVE request:

http://seclists.org/oss-sec/2016/q3/288

HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RSTSTREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RSTSTREAM frame, before any other data from that TCP connection is processed.

Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RSTSTREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open.

The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately.

The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth.

In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RSTSTREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client.

Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows.

swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress.

swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

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.

A use of incorrectly resolved name vulnerability fixed in 7.83.1 might remove the wrong file when --no-clobber is used together with --remove-on-error.

A flaw was found in OpenSSL. The crehash script does not properly sanitize shell meta-characters to prevent command injection. Some operating systems distribute this script in a manner where it is automatically executed. This flaw allows an attacker to execute arbitrary commands with the privileges of the script on these operating systems.

ecverify in kdc/kdcpreauthec.c in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.4 and 1.19.x before 1.19.2 allows remote attackers to cause a NULL pointer dereference and daemon crash. This occurs because a return value is not properly managed in a certain situation.

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.

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.

A use-after-free flaw was found in the way curl handled TLS session data. The curl versions using the OpenSSL library as their TLS backend could use freed memory after TLS session renegotiation was performed by the OpenSSL library. A malicious TLS server could use this flaw to crash or, possibly, execute arbitrary code with the privileges of a client application using the curl library.

A heap-based buffer overflow was found in libxml2 when processing truncated UTF-8 input.

Reference: https://gitlab.gnome.org/GNOME/libxml2/-/issues/235

Upstream patch: https://gitlab.gnome.org/GNOME/libxml2/-/commit/bf22713507fe1fc3a2c4b525cf0a88c2dc87a3a2

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.

cURL libcurl is vulnerable to a heap-based buffer overflow, caused by improper bounds checking by the tftpreceivepacket function. By sending specially-crafted request containing an OACK without the BLKSIZE option, a remote attacker could overflow a buffer and execute arbitrary code on the system.

A non-privileged user or program can put code and a config file in a known non-privileged path (under C:/usr/local/) that will make curl <= 7.65.1 automatically run the code (as an openssl "engine") on invocation. If that curl is invoked by a privileged user it can do anything it wants.

In SQLite through 3.29.0 whereLoopAddBtreeIndex in sqlite3.c can crash a browser or other application because of missing validation of a sqlitestat1 sz field aka a "severe division by zero in the query planner."

A flaw was found in Spring Framework Applications. Applications that use STOMP over the WebSocket endpoint are vulnerable to a denial of service attack caused by an authenticated user.

An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signaturealgorithms extension (where it was present in the initial ClientHello), but includes a signaturealgorithmscert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j).

Impact The Snappy frame decoder function doesn't restrict the chunk length which may lead to excessive memory usage. Beside this it also may buffer reserved skippable chunks until the whole chunk was received which may lead to excessive memory usage as well.

This vulnerability can be triggered by supplying malicious input that decompresses to a very big size (via a network stream or a file) or by sending a huge skippable chunk.

Impact

All users of SnappyFrameDecoder are affected and so the application may be in risk for a DoS attach due excessive memory usage.

References https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L79 https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L171 https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/SnappyFrameDecoder.java#L185

Impact The Bzip2 decompression decoder function doesn't allow setting size restrictions on the decompressed output data (which affects the allocation size used during decompression).

All users of Bzip2Decoder are affected. The malicious input can trigger an OOME and so a DoS attack

Workarounds No workarounds other than not using the Bzip2Decoder

References

Relevant code areas:

https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L80 https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L294 https://github.com/netty/netty/blob/netty-4.1.67.Final/codec/src/main/java/io/netty/handler/codec/compression/Bzip2Decoder.java#L305

A flaw was found in apache-commons-compress. When reading a specially crafted TAR archive, Compress can allocate large amounts of memory that leads to an out-of-memory error for small inputs. This flaw allows the mounting of a denial of service attack against services that use Compress' TAR package. The highest threat from this vulnerability is to system availability.

In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.

An old inffast.c optimization turns out to not be optimal anymore with modern compilers, and furthermore was not compliant with the C standard, for which decrementing a pointer before its allocated memory is undefined.

External References:

https://wiki.mozilla.org/images/0/09/Zlib-report.pdf https://docs.google.com/document/d/10i1KZS5so8xDqH2rplRa2xet0tyTvvJlLbQQmZIUIKE/edit#heading=h.t13tvnx4loq7

Upstream patch:

https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3618fc380cecb

CVE assignment:

http://seclists.org/oss-sec/2016/q4/602

Last updated 18 August 2025

In Apache Tomcat 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8. ...

Last updated 25 August 2025

A malicious web application running on Apache Tomcat 9.0.0.M1 to 9.0.0.M9, 8.5.0 to 8.5.4, 8.0.0.RC1 to 8.0.36, 7.0.0 to 7.0.70 and 6.0.0 to 6.0.45 was able to bypass a configured SecurityManager via manipulation of the configuration parameters for the JSP Servlet.

A flaw was found in Spring Framework. Applications that handle file uploads are vulnerable to a denial of service (DoS) attack if they rely on data binding to set a MultipartFile or javax.servlet.Part to a field in a model object.

A flaw was found in openssl. A miscalculation of a buffer size was found in openssl's SM2 decryption function, allowing up to 62 arbitrary bytes to be written outside of the buffer. A remote attacker could use this flaw to crash an application supporting SM2 signature or encryption algorithm, or, possibly, execute arbitrary code with the permissions of the user running that application. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in apache-commons-compress. When reading a specially crafted ZIP archive, Compress can allocate large amounts of memory that leads to an out-of-memory error for small inputs. This flaw allows the mounting of a denial of service attack against services that use Compress' zip package. The highest threat from this vulnerability is to system availability.

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.