Force HTTP/1.1 at startup with -Dsolr.http1=true. The scanner may still flag the JAR (because it’s present), but the CVE is no longer applicable since Solr is running over HTTP/1.1.
— Sanjay > On 25-Sep-2025, at 3:02 AM, Jan Høydahl <[email protected]> wrote: > > V9.10 will have 10.0.26 > > Jan Høydahl > >> 24. sep. 2025 kl. 20:54 skrev Vijay Mhaskar <[email protected]>: >> >> Hello Team, >> >> I see this question is not answered yet. I am also looking for a >> recommended solution for this issue. Does anyone know how we can >> fix/mitigate this vulnerability in Solr 9.9.0. Solr 9.9.0 >> contains http2-common-10.0.22.jar which is also affected. >> Any pointer/information about mitigation would be helpful. >> >> -- >> Vijay >> >>> On Wed, Aug 27, 2025 at 12:40 AM Rao, Vanishree >>> <[email protected]> wrote: >>> >>> Hello Team, >>> >>> We are seeing a high severity vulnerability CVE-2025-5115 >>> <https://ast.checkmarx.net/vulnerabilities/CVE-2025-5115%3AMaven-org.eclipse.jetty.http2%3Ahttp2-common-10.0.22/vulnerabilityDetailsGql> >>> under >>> category CWE-400 (Uncontrolled Resource Consumption) because of org >>> eclipse.jetty.http2:http2-common 10.0.22 coming from solr-solrj 9.8.0 in >>> the Software Composition Analysis Scan. >>> >>> Please let us know if it affects Solr 9.8.0 and the plans/timelines for >>> the remediation of this vulnerability. >>> >>> *CVE-2025-5115 | Category CWE-400 | Uncontrolled Resource Consumption* >>> In Eclipse Jetty, an HTTP/2 client may trigger the server to send >>> "RST_STREAM" frames, for example, by sending frames that are malformed or >>> that should not be sent in a particular stream state, therefore forcing the >>> server to consume resources such as CPU and memory. >>> For example, a client can open a stream and then send "WINDOW*UPDATE" >>> frames with a window size increment of 0, which is illegal. Per >>> specification https://www.rfc-editor.org/rfc/rfc9113.html#name-window >>> <https://www.rfc-editor.org/rfc/rfc9113.html#name-window>*update , the >>> server should send a "RST*STREAM" frame. The client can then open another >>> stream and send another invalid "WINDOW*UPDATE" frame, causing the server >>> to again consume unnecessary resources. This behavior does not exceed the >>> maximum number of concurrent streams, yet the client is able to create an >>> enormous number of streams in a short period of time. The attack can also >>> be carried out under other conditions, for example, by sending a "DATA" >>> frame for a closed stream, that cause the server to send a "RST_STREAM" >>> frame. This issue affects org.eclipse.jetty.http2:jetty-http2-common >>> package 12.0.x prior to 12.0.25, and 12.1.x prior to 12.1.0.beta2 and >>> org.eclipse.jetty.http2:http2-common versions 9.3.0M0 through 9.4.57, >>> 10.0.0-alpha0 through 10.0.25, 11.0.0-alpha0 through 11.0.25. >>> >>> Thanks & Regards, >>> >>> *Vanishree Rao* >>> >>> *(Vaa-nee Shree Ra-ao)* >>> >>> Sr. Developer, Application Development >>> >>> *[email protected] <[email protected]>* >>> >>> *M:* +91 8097034710 >>> >>> Pronouns: She/Her >>> >>> [image: TULogo-blue-rgb-120px-01] >>> >>> >>> >>> This email including, without limitation, the attachments, if any, >>> accompanying this email, may contain information which is confidential or >>> privileged and exempt from disclosure under applicable law. >>> >>> The information is for the use of the intended recipient. If you are not >>> the intended recipient, be aware that any disclosure, copying, >>> distribution, review or use of the contents of this email, and/or its >>> attachments, is without authorization and is prohibited. If you have >>> received this email in error, please notify us by reply email immediately >>> and destroy all copies of this email and its attachments. >>> >>> >>> >> >> >> -- >> -- >> Vijay
