Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2025/VULN295 _____________________________________________________________________ DATE : 12/05/2025 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): org.eclipse.jetty.http2:jetty-http2-common (Maven) versions prior to 12.0.17, org.eclipse.jetty.server:jetty-server (Jetty) versions prior to 9.4.57 (EOL). ===================================================================== https://github.com/jetty/jetty.project/security/advisories/GHSA-889j-63jv-qhr8 https://github.com/jetty/jetty.project/security/advisories/GHSA-q4rv-gq96-w7c5 _____________________________________________________________________ HTTP/2 client can force the server to allocate a humongous byte buffer that may lead to OoM and subsequently the JVM to exit High joakime published GHSA-889j-63jv-qhr8 May 8, 2025 Package org.eclipse.jetty.http2:jetty-http2-common (Maven) Affected versions >=12.0.0, <=12.0.16 Patched versions 12.0.17 Description Original Report Bjørn Seime bjorncs@vespa.ai 10:27 AM (10 minutes ago) Hi. We've identified a potential denial of service vulnerability affecting Jetty HTTP/2 servers on 12.0.16. A HTTP/2 client can force the server to allocate a humongous byte buffer that may lead to OoM and subsequently the JVM to exit. See attached zip file for readme and a full proof of concept. -- Bjorn C Seime Vespa.ai, Trondheim - Norway Impact Remote peers can cause the JVM to crash or continuously report OOM. Patches 12.0.17 Workarounds No workarounds. References #12690 Severity High 7.5/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Unchanged Confidentiality None Integrity None Availability High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID CVE-2025-1948 Weaknesses CWE-400 Credits @bjorncs bjorncs Reporter _____________________________________________________________________ **UNSUPPORTED WHEN ASSIGNED** GzipHandler causes part of request body to be seen as request body of a separate request High joakime published GHSA-q4rv-gq96-w7c5 May 8, 2025 Package org.eclipse.jetty.server:jetty-server (Jetty) Affected versions >=9.4.0,<=9.4.56 Patched versions 9.4.57 (EOL) Description Impact The original report: A year ago we added Jetty’s GzipHandler to decompress requests with a certain URL path. We hit CVE-2020-27218 (GHSA-86wm-rrjm-8wh8) and upgrading to Jetty 9.4.53 fixed the issue. Over the past few months we upgraded Jetty several times and we are currently on 9.4.56. Recently we received reports from a customer where they saw unexpected results from their API requests. Upon investigation we narrowed down the problem in the Jetty layer and the issue looks very similar to CVE-2020-27218 but slightly different. The symptom: A portion of the request body from request A overwrites a portion of the request body from request B. The resulting content of request A seems to be intact with no modifications. The resulting content of request B is a mix of original content A and original content B. There is no exception from neither request A nor request B, and both requests are consumed fully. Both requests have an uncompressed request body. To understand when this issue started, we looked at occurrences of this data leakage and the first occurrence of it was when we upgraded to Jetty 9.4.53 to fix CVE-2020-27218. To fix the new issue, we implemented our own GzipHandler that extends from Jetty’s GzipHandler and found that if we bypass Jetty’s handler for such requests then the issue no longer occurs. We suspect that this portion (https://github.com/jetty/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/handler/gzip/GzipHandler.java#L630-L717) of the GzipHandler code unintentionally affects uncompressed requests in high volume environments. Here is some additional information on the different types of requests handled by Jetty in our environment. /path1: This path is set in the includedPaths for the GzipHandler. These are gzip’ed requests. /path2: This path is not set in the includedPaths. Requests to this path can be either uncompressed or compressed. If compressed, servlet handles it based on the content encoding. We have observed the issue only in uncompressed requests to /path2. (Both requests A and B described in the symptom are uncompressed.) The custom GzipHandler we implemented checks if the request is to /path2 and calls _handler.handle, essentially bypassing Jetty’s GzipHandler for all requests going to this path. For requests to /path1, it calls super.handle and defers to Jetty’s GzipHandler. How to reproduce? We have yet to find a way to reproduce. So far this issue is only observed in our production environment with a very high volume of requests. Workarounds The issue can be avoid by disabling (or not enabling) gzip inflation of request body content. Severity High 7.2/ 10 CVSS v3 base metrics Attack vector Network Attack complexity Low Privileges required None User interaction None Scope Changed Confidentiality Low Integrity Low Availability None CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N CVE ID CVE-2024-13009 Weaknesses CWE-404 Credits @maimaisie maimaisie Reporter @samjsong samjsong Other @nchudasmasumo nchudasmasumo Other @lei-sumo lei-sumo Other ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================