Kafka

Hello, forwarding a message from the ASF Travel Assistance Committee: > The Travel Assistance Committee are now accepting applications for Community Over Code Asia, 2026. To be held in Beijing, China between the 7th and the 9th August. The Application deadline is set at the 29th of May - so plenty of time to apply. If you require a Visa then please do apply early, do not wait until you know if you are accepted or not. Same for Speakers, you should apply even though you do not know if you will be accepted, so that your application is in. Places are limited for Travel Assistance, so those deemed most in need will get higher priority. If you do not need assistance to get to Beijing, but you know of others who might be interested, then feel free to spread the word! > > Good luck to all those that apply. For more details, checkout https://tac.apache.org/ -Matthias

Hi, while testing Kafka 3.9 (KRaft), we encountered Unclean Leader Elections (ULE) during a partition reassignment. We found an existing issue that describes the problem: https://issues.apache.org/jira/browse/KAFKA-19148 (https://issues.apache.org/jira/browse/KAFKA-19148) As suggested in the issue, the ULE appears to be a false positive and is fixed in Kafka 4.1 (which we have verified). However, when reproducing the problem using the README attached to KAFKA- 19148, we observed message loss (not only reordering) while producing to the cluster with acks=1 (--producer-property acks=1) during the reassignment. My question: Is this message loss expected behavior when producing with acks=1 during partition reassignment? Notes: - The KAFKA-19148 issue has not received any updates for a long time (and is primarily about ULE). - I understand that acks=1 increases throughput but is not safe if the leader is removed imme...

Severity: moderate Affected versions: - Apache Kafka 0.11.0 through 3.9.1 - Apache Kafka 4.0.0 - Apache Kafka Clients (org.apache.kafka:kafka-clients) 0.11.0 through 3.9.1 - Apache Kafka Clients (org.apache.kafka:kafka-clients) 4.0.0 Description: Information exposure vulnerability has been identified in Apache Kafka. The NetworkClient component will output entire requests and responses information in the DEBUG log level in the logs. By default, the log level is set to INFO level. If the DEBUG level is enabled, the sensitive information will be exposed via the requests and responses output log. The entire lists of impacted requests and responses are: * AlterConfigsRequest * AlterUserScramCredentialsRequest * ExpireDelegationTokenRequest * IncrementalAlterConfigsRequest * RenewDelegationTokenRequest * SaslAuthenticateRequest * createDelegationTokenResponse * describeDelegationTokenResponse * SaslAuthenticateRespon...

Severity: important Affected versions: - Apache Kafka 4.1.0 through 4.1.1 Description: A possible security vulnerability has been identified in Apache Kafka. By default, the broker property `sasl.oauthbearer.jwt.validator.class` is set to `org.apache.kafka.common.security.oauthbearer.DefaultJwtValidator`. It accepts any JWT token without validating its signature, issuer, or audience. An attacker can generate a JWT token from any issuer with the `preferred_username` set to any user, and the broker will accept it. We advise the Kafka users using kafka v4.1.0 or v4.1.1 to set the config `sasl.oauthbearer.jwt.validator.class` to `org.apache.kafka.common.security.oauthbearer.BrokerJwtValidator` explicitly to avoid this vulnerability. Since Kafka v4.1.2 and v4.2.0 and later, the issue is fixed and will correctly validate the JWT token. Credit: Павел Романов <promanov1994@gmail.com> (finder) References: https://kafka.apache.org/cve-list https://kafka.apac...

Jun, thanks for your interest. We follow self-serve model. I just granted you permission to assign tickets. Side note: if you contribute, you might want to subscribe to the dev mailing list, which is more suitable for this purpose. -Matthias On 4/10/26 6:45 PM, 조형준 wrote: > Hi, > > I'd like to contribute to Apache Kafka. Could you please add me to the > Kafka contributors group on JIRA? I'm interested in working on KAFKA-20364 > > JIRA ID: xxxxxxjun > > Thanks, Jun >

Hello Kafka Community, We have a use case that requires attaching custom metadata to topics — things like SLA, durability guarantees, and PagerDuty account references. While exploring this in Kafka 4.2.0, we noticed an interesting inconsistency between broker-level and topic-level configuration behavior. Broker-level custom configs work fine: Running the following command succeeds without errors: ./bin/kafka-configs.sh --bootstrap-server localhost:9092 \ --entity-type brokers --entity-name 1 \ --alter --add-config 'durability.level=1' And describing the broker returns the config as expected: ./bin/kafka-configs.sh --bootstrap-server localhost:9092 \ --entity-type brokers --entity-name 1 \ --describe Output: Dynamic configs for broker 1 are: durability.level=null sensitive=true synonyms={DYNAMIC_BROKER_CONFIG:durability.level=null} Topic-level custom configs throw an exception: Running a similar command on a topic: ./bin/kafka-...

Hi Manikumar, The CVE seems to be still reserved and not published yet. Best, On Tue, Apr 7, 2026 at 1:49 PM Manikumar <manikumar@apache.org> wrote: > Severity: moderate > > Affected versions: > > - Apache Kafka Clients (org.apache.kafka:kafka-clients) 2.8.0 through 3.9.1 > - Apache Kafka Clients (org.apache.kafka:kafka-clients) 4.0.0 through 4.0.1 > - Apache Kafka Clients (org.apache.kafka:kafka-clients) 4.1.0 through 4.1.1 > > Description: > > A race condition in the Apache Kafka Java producer client’s buffer > pool management can cause messages to be silently delivered to > incorrect topics. > > When a produce batch expires due to delivery.timeout.ms while a > network request containing that batch is still in flight, the batch’s > ByteBuffer is prematurely deallocated and returned to the buffer pool. > If a subsequent producer batch—potentially destined for a different > topic—reuses this fr...