Kafka

Hello Luke and Vivek, I have gone ahead and created KAFKA-21004 <https://issues.apache.org/jira/browse/KAFKA-21004> to track the CVE fix (also opened a PR) Regards, Gergely On Mon, 31 Aug 2026 at 11:10, Luke Chen <showuon@gmail.com> wrote: > Hi Vivek, > > Thanks for reporting this issue. > Could you please open a JIRA > <http://issues.apache.org/jira/browse/KAFKA> ticket > for this issue? > And if possible, welcome to create a PR for it. > > From the current schedule, it should be included in v4.5.0. > > Thanks, > Luke > > On Mon, Aug 31, 2026 at 5:40 PM Vivek Agarwal B via users < > users@kafka.apache.org> wrote: > > > Hi, > > > > In our product, kafka v4.3.0 is used. Below Jackson related > vulnerability > > is reported on this kafka version - > > > > CVE-2026-68497 > > This vulnerability is fixed in jackson databind v2.21.6. I se...

Hi Vivek, Thanks for reporting this issue. Could you please open a JIRA <http://issues.apache.org/jira/browse/KAFKA> ticket for this issue? And if possible, welcome to create a PR for it. From the current schedule, it should be included in v4.5.0. Thanks, Luke On Mon, Aug 31, 2026 at 5:40 PM Vivek Agarwal B via users < users@kafka.apache.org> wrote: > Hi, > > In our product, kafka v4.3.0 is used. Below Jackson related vulnerability > is reported on this kafka version - > > CVE-2026-68497 > This vulnerability is fixed in jackson databind v2.21.6. I see upcoming > release kafka v4.4.0 bumped Jackson bind version to v2.21.5 > Please confirm which apache kafka upcoming versions will upgrade to > Jackson bind v2.21.6 > > Regards > Vivek > >

Hi, In our product, kafka v4.3.0 is used. Below Jackson related vulnerability is reported on this kafka version - CVE-2026-68497 This vulnerability is fixed in jackson databind v2.21.6. I see upcoming release kafka v4.4.0 bumped Jackson bind version to v2.21.5 Please confirm which apache kafka upcoming versions will upgrade to Jackson bind v2.21.6 Regards Vivek

Good Afternoon, Am looking to control log4j2 output produced by Kafka...but am having a little difficultly getting this to work as expected. During the kafka producer startup I've added this command: -Dlog4j2.configurationFile=/<whatever>/kafka/producers/log4j2.properties I've created a log4j2.properties file as follows: # Root Logger rootLogger=INFO, STDERR # Direct log messages to stderr appender.console.type = Console appender.console.name = STDERR appender.console.layout.type = PatternLayout appender.console.layout.pattern = [%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %C{1} - %msg%n Yet, when I look at STDERR am not seeing the desired messages. Do I need to configure slf4j instead or in conjunction? Anything I'm possibly doing wrong? Anyone with experience on customizing kafka message logging, will to chime in? Thank You, --Alex

Not sure if this is at all helpful, but we also experienced poor performance with Kafka Streams, and it took us quite a while to figure out all the tuning knobs, but we found that in our case we were experiencing extended RocksDB write stalls (overfilling memtables causing RocksDB to stall and eventually pause writes) which led to extended commit periods which led to large application latency gaps... I am not at all sure if you hit the same problem, but I would recommend enabling as many debug metrics as you can handle, turn on RocksDB stats logging, and in our case we ran a Claude Code instance with access to logs, dashboards, JFR dump (incl stack sampling) and it was actually quite good at identifying problematic configuration. You can't trust everything it says, but it can highlight things you didn't even consider... > On Aug 8, 2026, at 6:52 PM, Brebner, Paul via users <users@kafka.apache.org> wrote: > > Hi Tamar, > > Interesting problem...

Congrats! On 8/24/26 12:26 PM, o.g.h.ibrahim@gmail.com wrote: > Congratulations! > > Omnia > Sent from my iPhone > >> On 24 Aug 2026, at 08:27, Sanghyeok An <ojt90902@gmail.com> wrote: >> >> Congratulations! Well-deserved! >> >> Regards, >> Sanghyeok An >> >> 2026년 8월 24일 (월) 오후 4:15, Muralidhar Basani via dev <dev@kafka.apache.org>님이 >> 작성: >> >>> Congratulations! >>> >>> Regards, >>> Murali >>> >>>> On Mon, Aug 24, 2026 at 2:55 AM Luke Chen <showuon@gmail.com> wrote: >>>> >>>> Congratulations! Well deserved! >>>> Please remember to help review PRs and KIPs. :) >>>> >>>> Luke >>>> >>>>> On Mon, Aug 24, 2026 at 9:35 AM jian fu <fujian1115@gmail.com> wrote: >>>> >>>>> Congratulations！ ...

Hi Vivek, The CVE was fixed in the scope of KAFKA-20815 <https://issues.apache.org/jira/browse/KAFKA-20815> and will be included in the upcoming 4.4 release. You can find my analysis about the CVE in this <https://issues.apache.org/jira/browse/KAFKA-20815?focusedCommentId=18097890&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-18097890> comment. Best regards, Gergely On Fri, 21 Aug 2026 at 08:22, Vivek Agarwal B via users < users@kafka.apache.org> wrote: > Hello Apache Kafka Team, > > In our product, kafka v4.3.0 is used. Below 2 Jline related > vulnerabilities are reported on this kafka version - > > CVE-2026-56740 > CVE-2026-56741 > > I see in kafka v4.3.0, jline-3.30.4.jar is present in the libs folder - > libs/jline-3.30.4.jar/META-INF/maven/org.jline/jline-remote-telnet/pom.xml. > > As per github advisory, these vulnerabilities are fixed in Jline v4.2.1 > ver...

Hello Apache Kafka Team, In our product, kafka v4.3.0 is used. Below 2 Jline related vulnerabilities are reported on this kafka version - CVE-2026-56740 CVE-2026-56741 I see in kafka v4.3.0, jline-3.30.4.jar is present in the libs folder - libs/jline-3.30.4.jar/META-INF/maven/org.jline/jline-remote-telnet/pom.xml. As per github advisory, these vulnerabilities are fixed in Jline v4.2.1 versions. [1] CVE-2026-56740 Official Advisory - https://github.com/advisories/GHSA-47qp-hqvx-6r3f [2] CVE-2026-56741 Official Advisory - https://github.com/advisories/GHSA-2r2c-cx56-8933 Please confirm what apache kafka upcoming versions will upgrade to Jline v.4.2.1. Regards Vivek

In general, Kafka has a 1-year support window, so currently we are supporting 4.3, 4.2, and 4.1 release: https://kafka.apache.org/community/downloads/#supported-releases With the upcoming 4.4.0 release, 4.1 will drop out of the support window. So it's very unlikely that we would ship another 3.9.x bug-fix release. Given that 3.9 is the last release with ZK support, and upgrading to 4.x requires to migrate to KRaft, there is a possibility that we might maintain 3.9.x for a little longer than usual. However, officially 3.9 is not supported any longer, and the 3.9 and 4.0 release got archived already: https://kafka.apache.org/community/downloads/#archived-releases -Matthias On 8/19/26 7:21 AM, Gergely Harmadás wrote: > Hi James, > > I am not a project maintainer, just an enthusiastic contributor who > happened to have the same problem with lz4 :) There are some discussion > about a possible 3.9 release in this thread, so far no concrete...

Hi James, I am not a project maintainer, just an enthusiastic contributor who happened to have the same problem with lz4 :) There are some discussion about a possible 3.9 release in this thread, so far no concrete plans https://lists.apache.org/thread/bq27on99lf5b24d16zt5g5hnysd30c3w Best regards, Gergely On Mon, 17 Aug 2026 at 13:54, JAMES JOSE <jamejose@in.ibm.com> wrote: > Hello Gergely, > > Any plan for patching 3.9.* release with fixed version of lz4-java ? > > Regards, > James > > -----Original Message----- > From: JAMES JOSE > Sent: 17 August 2026 16:10 > To: 'users@kafka.apache.org' <users@kafka.apache.org> > Subject: RE: [EXTERNAL] Re: CVE-2026-59949 – Impact on Kafka (lz4-java) > > Thanks for the information. > > Regards, > James > > -----Original Message----- > From: Gergely Harmadás <harmadasg@gmail.com> > Sent: 14 August 2026 16:58 > To: users@k...

Hi, we have recently observed an increased amount of decreasing logappendtime events when the leader changed. It would be very helpful, if the logappendtime would never decrease for our use case. It seems possible to fix this with a minimal change by tracking the lastLogAppendTimeMs in the UnifiedLog.java and then force the now timestamp to be clamped with this lower bound. Is this something that we could contribute? thanks Alexander

Hello Gergely, Any plan for patching 3.9.* release with fixed version of lz4-java ? Regards, James -----Original Message----- From: JAMES JOSE Sent: 17 August 2026 16:10 To: 'users@kafka.apache.org' <users@kafka.apache.org> Subject: RE: [EXTERNAL] Re: CVE-2026-59949 – Impact on Kafka (lz4-java) Thanks for the information. Regards, James -----Original Message----- From: Gergely Harmadás <harmadasg@gmail.com> Sent: 14 August 2026 16:58 To: users@kafka.apache.org Subject: [EXTERNAL] Re: CVE-2026-59949 – Impact on Kafka (lz4-java) Hi James, The update to 1.11.1 was covered in KAFKA-20842 <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_KAFKA-2D20842&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=wFuRXeZ1jY-k5xudtTTZ60tgwyI060iX_RvaTA5osQs&m=1D8DzNrAXlo6oFOad6b3jmLZxFQNXN36k_qrhHmAnqsr_1M7DWODVs6nR5clcUX4&s=Rtskq3UpzxYUDRvG-RkTH59cAW9Z8_015-CxCexEG0M&e= >. The CVE fix will be includ...

Thanks for the information. Regards, James -----Original Message----- From: Gergely Harmadás <harmadasg@gmail.com> Sent: 14 August 2026 16:58 To: users@kafka.apache.org Subject: [EXTERNAL] Re: CVE-2026-59949 – Impact on Kafka (lz4-java) Hi James, The update to 1.11.1 was covered in KAFKA-20842 <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_KAFKA-2D20842&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=wFuRXeZ1jY-k5xudtTTZ60tgwyI060iX_RvaTA5osQs&m=1D8DzNrAXlo6oFOad6b3jmLZxFQNXN36k_qrhHmAnqsr_1M7DWODVs6nR5clcUX4&s=Rtskq3UpzxYUDRvG-RkTH59cAW9Z8_015-CxCexEG0M&e= >. The CVE fix will be included in the upcoming Kafka 4.4 release which is targeted for September according to the Release Plan <https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_spaces_KAFKA_pages_429064575_Release-2BPlan-2B4.4.0&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=wFuRXeZ1jY-k5xudtTTZ60tgwyI060iX_RvaTA5osQs...

Hi James, The update to 1.11.1 was covered in KAFKA-20842 <https://issues.apache.org/jira/browse/KAFKA-20842>. The CVE fix will be included in the upcoming Kafka 4.4 release which is targeted for September according to the Release Plan <https://cwiki.apache.org/confluence/spaces/KAFKA/pages/429064575/Release+Plan+4.4.0>. There was also a backport to the 4.3 branch which means the CVE fix will be included in a subsequent release, but AFAIK there is no planned date yet for 4.3.2. As a side-note I have noticed there is new security release for lz4, created KAFKA-20937 <https://issues.apache.org/jira/browse/KAFKA-20937> to track the update. Best regards, Gergely On Thu, 13 Aug 2026 at 05:59, JAMES JOSE <jamejose@in.ibm.com> wrote: > Hi Team, > > As per the GitHub advisory for GHSA-xx22-p4ch-683r (CVE-2026-59949), > lz4-java versions up to and including 1.11.0 are affected, with the issue > fixed in version 1.11.1. GitHub A...

Hi Team, As per the GitHub advisory for GHSA-xx22-p4ch-683r (CVE-2026-59949), lz4-java versions up to and including 1.11.0 are affected, with the issue fixed in version 1.11.1. GitHub Advisory – GHSA-xx22-p4ch-683r<https://github.com/advisories/GHSA-xx22-p4ch-683r?utm_source=chatgpt.com> We understand that the latest Kafka version currently uses lz4-java-1.10.2. Could you please confirm whether this means Kafka is affected by CVE-2026-59949 and whether Kafka needs to be updated to use lz4-java 1.11.1 or later? If a Kafka update is required, could you also let us know whether there is a planned Kafka release that will include the fixed version, and the expected release date? Thanks, James

Hi Tamar, Interesting problem! Kafka Streams is actually the only Kafka API I haven’t done extensive performance testing/benchmarking on over the years. A couple of thoughts to start with. Is this behaviour only obvious at increasing load? Do you have sufficient cluster resources, Kafka clients? For Kafka Streams I recall that increasing the partitions (and therefore having sufficient clients and cluster resources) is the only real scalability knob? And for Kafka Streams, windowing size and state store may impact scalability. We tried Kafka Streams a few years internally for aggregating performance data and found resource usage too high and scalability poor, and resorted to custom Kafka clients. I’ve talked about this at C/C a few years ago, and here’s a bog from the internal team: https://www.instaclustr.com/blog/the-introduction-of-apache-kafka-infrastructure/ Others have used alternative streams processing tech including Flink, ClickHouse, RisingWave, etc. ...