In Eclipse Jetty, TryPathsHandler and TryFilesFilter can be configured to forward requests to template URIs such as index?p=$path, where $path is the request path in context.

However, URI paths may contain characters that are reserved in URI queries so that a path of /s&a=1 when applied to the template becomes index?p=/s&a=1, which is interpreted as 2 query parameters: p=/s and a=1, rather than just one query parameter p whose value is /s&a=1.

In Eclipse Jetty, HttpClient may receive a redirect of the form:

/secure/../evil

If an attacker is able to control the redirects, then HttpClient matches authentication credentials against /secure rather than normalizing the path to /evil, and will therefore follow the redirect sending the Authorization header for /secure to /evil.

This also mean that the attacker must have an evil application deployed on the same domain as the target.

In Eclipse Jetty, across various versions of jetty-annotations, and jetty-eeN-annotations, the Jakarta Spec authoritative url-pattern rules for mixed @ServletSecurity annotation, and web.xml defined security-constraint on the same url-pattern were not being applied if the web.xml had more than 1 url-pattern for a servlet, and had a security-constraint applying to only some of those url-pattern definitions.

In Eclipse Jetty, across various versions of jetty-server, and jetty-proxy, the host whitelist/blacklist is case-sensitive, and would allow hosts through that only differ by case.

In Eclipse Jetty, across various versions of jetty-security, and jetty-eeN-security, two or more security constraints with the same http-method-omission set, and no url-patterns, are not combined properly per Jakarta Servlet Spec.

Resulting in later http-method-omission sets overriding previous constraints with the same http-method-omission set.

Eclipse Jetty's SessionAuthentication retains authentication credentials in a serializable object. When the credentials contain a plaintext password and the authenticated session is persisted to a session data store, the password may consequently be written to persistent storage in plaintext.

An attacker with sufficient privileges to read the persisted session data may obtain the plaintext passwords of authenticated users.

In Eclipse Ditto versions 3.6.0 to 3.8.13 and 3.9.0 to 3.9.7, the Ditto Explorer UI loads its complete environment configuration, including the Ditto API URI and the OpenID Connect (OIDC) provider settings, from an arbitrary cross-origin URL supplied in the environmentsURL query parameter. It adopts this configuration without user confirmation and persists it in the browser's localStorage. A crafted link can therefore set an attacker-controlled OIDC authority with autoSso enabled. The UI then automatically starts a login at the genuine identity provider but exchanges the returned authorization code together with its PKCE codeverifier at an attacker-controlled token endpoint. This lets the attacker redeem the code for the victim's access and refresh tokens. Alternatively, an attacker-controlled apiuri causes the UI to send the victim's bearer token or Basic credentials to the attacker. Because the configuration is persisted, later visits to the UI without the crafted link repeat the token theft. In versions 3.9.0 to 3.9.7, the Swagger UI OIDC integration of the Helm chart and the Docker Compose deployment is affected in the same way, but requires the user to start the login. The issue is fixed in 3.8.14 and 3.9.8.

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.

In the Eclipse OMR compiler component, since release 0.7.0, an optimization enabled for Eclipse OpenJ9 consumers of OMR on Z processors incorrectly handles NUL (0x00) characters during the Latin-compatible charset (UTF-8, ISO8859-1, ASCII, etc) to IBM-1047/037 translation sequence. This can cause the output byte array to be truncated, discarding the first NUL byte and all subsequent characters, and thereby exposing a possible buffer over-read problem. This issue is fixed in Eclipse OMR version 0.8.0.

In Eclipse Foundation NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in nxipv4optionprocess() when processing an IPv4 packet with the timestamp option.

In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in nxipv4packetreceive() when handling unicast DHCP messages that could cause corruption of 4 bytes of memory.

In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in uxhostclasshidreportdescriptorget()  when parsing a descriptor of an USB HID device.

In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in nxicmpv6validateoptions() when handling a packet with ICMP6 options.

In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in uxhostclassaudiostreamingsamplingget() when parsing a descriptor of an USB streaming device.

In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in uxhostclassaudio10samparsefunc() when parsing a list of sampling frequencies.

In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in uxhostclassaudiodevicetypeget() when parsing a descriptor of an USB audio device.

In USBX before 6.4.3, the USB support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in uxhostclassaudioalternatesettinglocate() when parsing a descriptor with attacker-controlled frequency fields.

In NextX Duo's snmp addon versions before 6.4.4, a part of the Eclipse Foundation ThreadX, an attacker could cause an out-of-bound read by a crafted SNMPv3 security parameters.

In NextX Duo before 6.4.4, in the HTTP client module, the network support code for Eclipse Foundation ThreadX, the parsing of HTTP header fields was missing bounds verification. A crafted server response could cause undefined behavior.

In NetXDuo version before 6.4.4, a networking support module for Eclipse Foundation ThreadX, in the DHCPV6 client there was an unchecked index extracting the server DUID from the server reply. With a crafted packet, an attacker could cause an out of memory read.

In Eclipse ThreadX before version 6.4.3, an attacker can cause a denial of service (crash) by providing a pointer to a reserved or unmapped memory region. Vulnerable system calls had a check of pointers, but that check wasn't verifying whether the pointer is outside the module memory region.

In Eclipse ThreadX before version 6.4.3, the thread module has a setting of maximum priority. In some cases the check of that maximum priority wasn't performed, allowing, as a result, to obtain a thread with higher priority than expected and causing a possible denial of service.

In Eclipse ThreadX before 6.4.3, when memory protection is enabled, syscall parameters verification wasn't enough, allowing an attacker to obtain an arbitrary memory read/write.

In Eclipse Foundation NextX Duo before 6.4.4, a module of ThreadX, the nxsecuretlsprocessclienthello() function was missing length verification of certain SSL/TLS client hello message: the ciphersuite length and compression method length. In case of an attacker-crafted message with values outside of the expected range, it could cause an out-of-bound read.

In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was a potential out of bound read in nxsecuretlsprocessclienthello() because of a missing validation of PSK length provided in the user message.

In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was an incorrect bound check resulting it out by two out of bound read.

In NetX Duo version before 6.4.4, the component of Eclipse Foundation ThreadX, there was an incorrect bound check innxsecuretlsprocclienthellosupportedversionsextension() in the extension version field.

In FileX before 6.4.2, the file support module for Eclipse Foundation ThreadX, there was a possible buffer overflow in the FileX RAM disk driver. It could cause a remote execurtion after receiving a crafted sequence of packets

In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in nxipv4packetreceive() function when received an Ethernet frame with less than 4 bytes of IP packet.

In NetX Duo before 6.4.4, the networking support module for Eclipse Foundation ThreadX, there was a potential out of bound read issue in nxippacketreceive() function when received an Ethernet with type set as IP but no IP data.