Kafka

Hi Vivek, Apache Kafka 4.3.1 is already released and won't get changed after the fact. Our binaries are immutable. What I can tell you is that both branches, 4.2 and 4.3 contain the updated dependencies, so subsequent releases in these both version families will include it. At the time of writing this, there is no planned date yet for 4.3.2 or 4.2.2, sorry. Best, ------------------ Josep Prat Sr. Engineering Director - Streaming Services, Aiven josep.prat@aiven.io | +491715557497 | aiven.io Aiven Deutschland GmbH Rosenthaler Straße 43-45, 10178 Berlin Geschäftsführer: Oskari Saarenmaa, Kenneth Chen Amtsgericht Charlottenburg, HRB 209739 B On Mon, Jul 20, 2026, 14:45 Vivek Agarwal B <vivek.b.agarwal@ericsson.com> wrote: > Hi Josep, > > Please can you confirm when will the Apache kafka v4.2 and v4.3.1 will > backport to latest Jackson version where the mentioned CVEs are fixed. > Also what is the tentative date for release of...

Hi Josep, Please can you confirm when will the Apache kafka v4.2 and v4.3.1 will backport to latest Jackson version where the mentioned CVEs are fixed. Also what is the tentative date for release of v4.3.2. Regards Vivek -----Original Message----- From: Josep Prat via users <users@kafka.apache.org> Sent: 14 July 2026 18:10 To: users@kafka.apache.org Cc: Josep Prat <josep.prat@aiven.io> Subject: Re: FW: Kafka new version info with vulnerabilities fixes Hi Vivek, On June 25th, Apache Kafka 4.3.1 was released and is available for use Of the CVEs you mentioned: Kafka Core - CVE-2026-41115 -> Fixed in 4.3.1 (documentation update) OpenTelemetry - CVE-2026-39882 -> seems to refer to opentelemetry-go and we use opentelemetry-proto only - CVE-2026-41078 -> seems to refer to opentelemetry-dotnet, we use opentelemetry-proto only - CVE-2026-40894 -> seems to refer to opentelemetry-dotnet, we use opentelemetry-proto only - CVE-2026-44967 -...

Hi Vivek, On June 25th, Apache Kafka 4.3.1 was released and is available for use Of the CVEs you mentioned: Kafka Core - CVE-2026-41115 -> Fixed in 4.3.1 (documentation update) OpenTelemetry - CVE-2026-39882 -> seems to refer to opentelemetry-go and we use opentelemetry-proto only - CVE-2026-41078 -> seems to refer to opentelemetry-dotnet, we use opentelemetry-proto only - CVE-2026-40894 -> seems to refer to opentelemetry-dotnet, we use opentelemetry-proto only - CVE-2026-44967 -> seems to refer to opentelemetry-c++, we use opentelemetry-proto only JLine - GHSA-2r2c-cx56-8933 -> seems to refer to JLine-telnet. We don't use this submodule - GHSA-47qp-hqvx-6r3f -> seems to refer to JLine-telnet. We don't use this submodule - XRAY-1005950 and XRAY-1005951 -> these appear to be JFrog Xray internal database identifiers rather than CVEs, so we can't look them up publicly. Could you share the affected component and version fr...

Hello Team, Could you please confirm the plan to release a new Kafka version that includes fixes for vulnerabilities identified primarily in transient dependencies such as Jackson, JLine, OpenTelemetry and a few others? These are detected in kafka v4.3.0. Below is the list of identified vulnerabilities for reference: Kafka core CVE-2026-41115 OpenTelemetry CVE-2026-39882 CVE-2026-41078 CVE-2026-40894 CVE-2026-44967 JLine GHSA-2r2c-cx56-8933 GHSA-47qp-hqvx-6r3f XRAY-1005950 XRAY-1005951 Jackson - CVE-2026-54512 CVE-2026-54513 CVE-2026-54514 CVE-2026-54515 CVE-2026-54516 CVE-2026-54517 CVE-2026-54518 Regards Vivek

Hello Team, Could you please confirm the plan to release a new Kafka version that includes fixes for vulnerabilities identified primarily in transient dependencies such as Jackson, JLine, OpenTelemetry and a few others? These are detected in kafka v4.3.0. Below is the list of identified vulnerabilities for reference: Kafka core CVE-2026-41115 OpenTelemetry CVE-2026-39882 CVE-2026-41078 CVE-2026-40894 CVE-2026-44967 JLine GHSA-2r2c-cx56-8933 GHSA-47qp-hqvx-6r3f XRAY-1005950 XRAY-1005951 Jackson - CVE-2026-54512 CVE-2026-54513 CVE-2026-54514 CVE-2026-54515 CVE-2026-54516 CVE-2026-54517 CVE-2026-54518 Regards Vivek

Hi I have run into a strange behaviour. I have a topic that has retention.ms and segment.ms set to one week. Hasn't been any traffic there for a long time, more than a week. So the logfile was empty. Name och the old logfile was 00000000000000069531.log. We have a job that checks the offset and fetches latest records if there are any, latest record fetched had offset 69530. So that indicates that no records had actually been added to the partition. Shortly after the restart, due to a operator upgrade, of the cluster the file got swiped and a new one created. [LocalLog partition=o01.qdpo01.qto01hah-1, dir=/var/lib/kafka/data/kafka-log1/o01.qdpo01.qto01hah-1] Rolled new log segment at offset 69532 in 1 ms. And also: [UnifiedLog partition=o01.qdpo01.qto01hah-1, dir=/var/lib/kafka/data/kafka-log1] Deleting segment LogSegment(baseOffset=69531, size=3819, lastModifiedTime=1783335231543, largestRecordTimestamp=0) due to log retention time 604800000ms breach based on the lar...

hi Soby Did you set the internal config group.share.enable=true? That is another switch that allows us to test the share protocol quickly. Best, Chia-Ping On 2025/09/04 20:09:12 Soby Chacko wrote: > Hi, > > When using the Kafka 4.0.0 client, we could enable shared consumers by > providing the following properties in an embedded Kafka environment. > > For example, > > "unstable.api.versions.enable=true", > "group.coordinator.rebalance.protocols=classic,share", > "share.coordinator.state.topic.replication.factor=1", > "share.coordinator.state.topic.min.isr=1" > > When upgrading to Kafka 4.1.0, the same tests work with just the last > two properties. Is that expected? (Basically, I don't need to set > unstable.api.versions.enable or group.coordinator.rebalance.protocols > in 4.1.0). > > The documentation shows something like setting share.version to 1 >...