Consider purchasing support from Confluent to get this sort of request answered quickly.
From: Sahil Sharma D <sahil.d.sha...@ericsson.com.INVALID> Date: Tuesday, May 9, 2023 at 12:40 PM To: users@kafka.apache.org <users@kafka.apache.org> Subject: [EXTERNAL] RE: CVEs related to Kafka Gentle reminder-2 ! -----Original Message----- From: Sahil Sharma D <sahil.d.sha...@ericsson.com.INVALID> Sent: 03 May 2023 04:34 PM To: users@kafka.apache.org Subject: RE: CVEs related to Kafka Gentle reminder! From: Sahil Sharma D Sent: 03 May 2023 08:57 AM To: 'users@kafka.apache.org' <users@kafka.apache.org> Subject: RE: CVEs related to Kafka Importance: High Hi Team, We have found few more Vulnerabilities on Kafka, below are the list: CVE-2022-36944<https://urldefense.com/v3/__https://nvd.nist.gov/vuln/detail/CVE-2022-36944__;!!K_cMf-SQz-o!dVr1QtyQ4T63P401cAOMN0HLlWf5PlvvulL4LX7JGrbK8mSYbhhN6Snv5XQ7NzMg6wcdPjVpi6k_LPbS9gMBugc0ucxXd2_9ywOkKoY$ > Scala 2.13.x before 2.13.9 has a Java deserialization chain in its JAR file. On its own, it cannot be exploited. There is only a risk in conjunction with Java object deserialization within an application. In such situations, it allows attackers to erase contents of arbitrary files, make network connections, or possibly run arbitrary code (specifically, Function0 functions) via a gadget chain CVE-2023-26048<https://urldefense.com/v3/__https://nvd.nist.gov/vuln/detail/CVE-2023-26048__;!!K_cMf-SQz-o!dVr1QtyQ4T63P401cAOMN0HLlWf5PlvvulL4LX7JGrbK8mSYbhhN6Snv5XQ7NzMg6wcdPjVpi6k_LPbS9gMBugc0ucxXd2_9GQ1_xXo$ > Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory). CVE-2023-26049<https://urldefense.com/v3/__https://nvd.nist.gov/vuln/detail/CVE-2023-26049__;!!K_cMf-SQz-o!dVr1QtyQ4T63P401cAOMN0HLlWf5PlvvulL4LX7JGrbK8mSYbhhN6Snv5XQ7NzMg6wcdPjVpi6k_LPbS9gMBugc0ucxXd2_9K3-reco$ > Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `"` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue. Kindly confirm about the mitigation plan and impact of these CVEs. Regards, Sahil From: Sahil Sharma D Sent: 02 May 2023 02:16 PM To: users@kafka.apache.org<mailto:users@kafka.apache.org> Subject: CVEs related to Kafka Importance: High Hi team, We have got below two vulnerabilities on Kafka 3PP. CVE-2022-42003<https://urldefense.com/v3/__https://nvd.nist.gov/vuln/detail/CVE-2022-42003__;!!K_cMf-SQz-o!dVr1QtyQ4T63P401cAOMN0HLlWf5PlvvulL4LX7JGrbK8mSYbhhN6Snv5XQ7NzMg6wcdPjVpi6k_LPbS9gMBugc0ucxXd2_9CZqAV4I$ > In FasterXML jackson-databind before 2.14.0-rc1, resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled. Additional fix version in 2.13.4.1 and 2.12.17.1 CVE-2022-42004<https://urldefense.com/v3/__https://nvd.nist.gov/vuln/detail/CVE-2022-42004__;!!K_cMf-SQz-o!dVr1QtyQ4T63P401cAOMN0HLlWf5PlvvulL4LX7JGrbK8mSYbhhN6Snv5XQ7NzMg6wcdPjVpi6k_LPbS9gMBugc0ucxXd2_9zv_JhHY$ > In FasterXML jackson-databind before 2.13.4, resource exhaustion can occur because of a lack of a check in BeanDeserializer._deserializeFromArray to prevent use of deeply nested arrays. An application is vulnerable only with certain customized choices for deserialization. Is 3PP is using the impacted functionality and in which version of Kafka these will be fixed? Regards, Sahil This e-mail and any files transmitted with it are confidential, may contain sensitive information, and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please notify the sender by reply e-mail immediately and destroy all copies of the e-mail and any attachments.