Community

• 1: Books and Papers
• 2: Contact
• 3: CVE List
• 4: Developer Guide
• 5: Downloads
• 6: Events
• 7: Podcasts
• 8: Project Security
• 9: The Committers
• 10: Trademark
• 11: Videos

1 - Books and Papers

Books

The following books cover Apache Kafka and/or the subject of event streaming in general.

Academic References and Papers

The following academic papers and publications cover Apache Kafka and/or the subject of event streaming in general.

• KSQL: Streaming SQL Engine for Apache Kafka by Hojjat Jafarpour, Rohan Desai, Damian Guy; EDBT ‘19: Proceedings of the 22nd International Conference on Extending Database Technology, 2019
• Streams and Tables: Two Sides of the Same Coin by Matthias J. Sax, Guozhang Wang, Matthias Weidlich, Johann-Christoph Freytag; BIRTE ‘18: Proceedings of the International Workshop on Real-Time Business Intelligence and Analytics, 2018
• Apache Kafka by Matthias J. Sax; Encyclopedia of Big Data Technologies, Springer, Cham, 2018
• Building a Replicated Logging System with Apache Kafka by Guozhang Wang, Joel Koshy, Sriram Subramanian, Kartik Paramasivam, Mammad Zadeh, Neha Narkhede, Jun Rao, Jay Kreps, Joe Stein; VLDB Endowment ‘15: Proceedings of the VLDB Endowment,Vol. 8, No. 12, 2015
• Liquid: Unifying Nearline and Offline Big Data Integration by Raul Castro Fernandez, Peter R. Pietzuch, Jay Kreps, Neha Narkhede, Jun Rao, Joel Koshy, Dong Lin, Chris Riccomini, Guozhang Wang; CIDR ‘15: 7th Biennial Conference on Innovative Data Systems Research, 2015
• Kafka, Samza and the Unix Philosophy of Distributed Data by Martin Kleppmann, Jay Kreps, Bulletin of the IEEE Computer Society Technical Committee on Data Engineering, 2015
• The Log: What every software engineer should know about real-time data’s unifying abstraction, by Jay Kreps, 2013
• Building LinkedIn’s Real-time Activity Data Pipeline by Ken Goodhope, Joel Koshy, Jay Kreps, Neha Narkhede, Richard Park, Jun Rao, Victor Yang Ye; Bulletin of the IEEE Computer Society Technical Committee on Data Engineering, 2012
• Data Infrastructure at LinkedIn by Aditya Auradkar et al.; IEEE 28th International Conference on Data Engineering, 2012
• Kafka: a Distributed Messaging System for Log Processing by Jay Kreps, Neha Narkhede, Jun Rao; NetDB workshop ‘11, 2011

2 - Contact

Mailing Lists

We have a few mailing lists hosted by Apache:

• User mailing list : A list for general user questions about Kafka®. To subscribe, send an email to users-subscribe@kafka.apache.org. Once subscribed, you can ask general user questions by mailing to users@kafka.apache.org. Archives are available here. To unsubscribe, send an email to users-unsubscribe@kafka.apache.org. Note that the mailing list works on plain text emails. Sending HTML based emails can leads to issues and should be avoided.
• Developer mailing list : A list for discussion on Kafka® development. To subscribe, send an email to dev-subscribe@kafka.apache.org. Once subscribed, you can have discussion on Kafka® development by mailing to dev@kafka.apache.org. Archives are available here. To unsubscribe, send an email to dev-unsubscribe@kafka.apache.org. Note that the mailing list works on plain text emails. Sending HTML based emails can leads to issues and should be avoided.
• JIRA mailing list : A list to track Kafka® JIRA notifications. To subscribe, send an email to jira-subscribe@kafka.apache.org. Archives are available here. To unsubscribe, send an email to jira-unsubscribe@kafka.apache.org.
• Commit mailing list : A list to track Kafka® commits. To subscribe, send an email to commits-subscribe@kafka.apache.org. Archives are available here. To unsubscribe, send an email to commits-unsubscribe@kafka.apache.org.

For all Apache mailing lists, you must confirm your subscription by replying to an email. See the Apache Mailing Lists page for more information.

Prior to the move to Apache we had a Google group we used for discussion. Archives can be found here. After that we were in Apache Incubator which has its own archives for user, dev, and commit lists.

3 - CVE List

Apache Kafka Security Vulnerabilities

This page lists all security vulnerabilities fixed in released versions of Apache Kafka.

This page does not list security advisories for dependencies of Kafka. If your security scanner warns that there is an advisory for a dependency of Kafka, please see this documentation. You can find the current development versions of various dependencies here. You can find a list of advisories that have been confirmed not to apply to Kafka here. You are invited to contribute version updates or (motivated) suppressions.

CVE-2026-114349 Apache Kafka: Denial of service via unbounded memory allocation when decoding compressed record batches

When a broker decodes a compressed record batch, the per-record decoder reads a declared body size from the decompressed stream and allocates a buffer of that size before validating it against the bytes available or any configured limit. The size is attacker-controlled, and the batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce request can declare a body size of up to about 2 GiB and force the broker to attempt that allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request size limit, and client/broker quotas bound only the compressed wire size, not the declared decompressed size.

Credit: Peyton Kennedy (reporter), Trung Nguyen (CyStack) (reporter), Bartłomiej Dmitruk (Striga) (reporter), 임성민 (reporter), Mike Read (GitHub: Michael-JRead) (reporter), Salman Aljardan (reporter), Yuchao Zhang (reporter), Yu Bao (PayPal Cyber Security Team) (reporter), Vamsi K (reporter), Srinivas Akhil Mallela (remediation developer)

References: CVE-2026-114349

CVE-2026-112375 Apache Kafka: Unauthorized principal can read arbitrary broker files via IncrementalAlterConfigs

An authenticated Kafka principal with no authorization grants (not even ALTER_CONFIGS) can make a broker read a file or an environment variable from the broker host and return its contents. An IncrementalAlterConfigs (or AlterConfigs) request targeting a BROKER resource reaches the broker’s configuration validation before any authorization check is applied to that path. Validation resolves configuration variables such as ${file:/path:key} or ${env:VAR} using a ConfigProvider named in the request, and this resolution bypasses the org.apache.kafka.automatic.config.providers allowlist that was added as the mitigation for CVE-2024-31141. An arbitrary ConfigProvider (for example FileConfigProvider or EnvVarConfigProvider) is therefore instantiated and the referenced file or environment variable is read, and a type-validation error returns the resolved content to the caller.

Credit: Arthur Chan (Ada Logics and Anthropic Research) (reporter), OpenAI Codex Security - Amy Burnett and Khai Tran (reporter), Mickael Maison (remediation developer), Manikumar Reddy (remediation developer), Chia-Ping Tsai (remediation developer)

References: CVE-2026-112375

CVE-2026-111551 Apache Kafka: Denial of service in Kafka Streams and client deserializers via unbounded memory allocation

Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde).

Credit: Peyton Kennedy (reporter), Bartłomiej Dmitruk (Striga) (reporter), Mike Read (GitHub: Michael-JRead) (reporter), Matthias J. Sax (remediation developer), Lucy Liu (remediation developer)

References: CVE-2026-111551

CVE-2026-111115 Apache Kafka: Broker OutOfMemoryError via tagged-field allocation amplification in flexible protocol request parsing

Apache Kafka’s code-generated readers for flexible protocol versions read a tagged-field count declared by the sender and retain a RawTaggedField object for each unknown field. That count was bounded only by the outer request-frame size (socket.request.max.bytes); it was not checked against the remaining buffer bytes or capped. Because each entry can be encoded in as little as two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged fields and force one object allocation per declared field. Flexible request headers (header version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the amplification applies to the request header itself.

Credit: Mufeed VH (finder), Vivek R (finder), Shay Elkin (remediation developer)

References: CVE-2026-111115

CVE-2026-111108 Apache Kafka: Broker OutOfMemoryError via array allocation amplification in code-generated protocol readers

Apache Kafka’s code-generated protocol readers pre-size an array’s collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count + 1), so a request of a few tens of megabytes can force a heap allocation several times larger before any element is read. The pattern is emitted into every generated reader, so it affects all Kafka API types with an array field.

Credit: Mike Read (GitHub: Michael-JRead) (reporter), Izzy Harker (remediation developer), Alyssa Huang (remediation developer), Truc Nguyen (remediation developer)

References: CVE-2026-111108

CVE-2026-110985 Apache Kafka: Broker silently skips JWT signature verification for SASL/OAUTHBEARER when the JWKS endpoint URL is not configured

A Kafka broker using SASL/OAUTHBEARER with the default validator (sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the JWT signature. When that URL is unset (the default) and no verification key resolver is supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not verify the JWT signature, algorithm, or issuer — and the broker starts with no warning or error. This is the residual of CVE-2026-33557, whose fix restored signature verification only on the path where the JWKS endpoint URL is set.

Credit: San Zhang (reporter), Kaixuan Li (reporter), Evan Zhou (remediation developer)

References: CVE-2026-110985

CVE-2026-116593 Apache Kafka: Kafka Connect configuration provider values exposed via validation REST API endpoint

Apache Kafka Connect has the /connector-plugins/{connector-type}/config/validate endpoint on its REST API to validate connector configurations. Apache Kafka Connect also supports Configuration Providers, which allow the values of sensitive configuration to be hidden and resolved only at runtime.

An attacker with access to the validate endpoint can use it to resolve and return plaintext values via any of the configuration providers installed on a Connect worker.

Credit: Hyunwoo Kim (reporter), Sudhanshu Chauhan (RedHunt Labs) (reporter), Bartłomiej Dmitruk (Striga) (reporter), Andrew MacPherson (reporter), Mickael Maison (remediation developer)

References: CVE-2026-116593

CVE-2026-111073 Apache Kafka: PushTelemetry (KIP-714) metrics payloads are decompressed without a size limit, allowing a broker out-of-memory denial of service

The broker-side PushTelemetry API (KIP-714) validates only the compressed size of a client’s metrics payload against telemetry.max.bytes (default 1 MB) before decompressing it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the decompressed output size, growing a heap buffer until the compressed input is exhausted. A small, highly compressible payload (for example gzip-compressed zeros) can therefore expand to hundreds of megabytes of broker heap.

Credit: Dawit Jeong (reporter), Apoorv Mittal (remediation developer), Andrew Schofield (remediation reviewer)

References: CVE-2026-111073

CVE-2026-110952 Apache Kafka: Broker does not enforce JWT issuer and audience validation for SASL/OAUTHBEARER by default

A Kafka broker that authenticates clients with SASL/OAUTHBEARER using the bundled JWKS-backed validator always verifies the JWT signature, but two further checks are only performed when explicitly configured:

• The issuer (iss) claim is verified only when sasl.oauthbearer.expected.issuer is set. When it is unset, a validly-signed token carrying the expected audience is accepted regardless of which issuer minted it.
• An audience (aud) claim is required only when sasl.oauthbearer.expected.audience is set. When it is unset, a validly-signed token that omits the aud claim is accepted. (A token that carries an aud claim is still rejected when no expected audience is configured.)

Both options default to unset and have been documented as optional (Importance LOW) since KIP-768 (3.1.0).

Credit: Kai Aizen (SnailSploit) (reporter), Evan Zhou (remediation developer)

References: CVE-2026-110952

CVE-2026-115644 Apache Kafka: Connect Admin REST API Authentication Bypass via Unapplied REST Extensions

Apache Kafka Connect contains an authentication bypass vulnerability affecting the admin REST API when admin.listeners is configured with a separate listener from the main listeners property.

When operators isolate the admin REST API by explicitly configuring the admin.listeners property, REST extensions specified via rest.extension.classes (such as BasicAuthSecurityRestExtension) are not registered or applied to the admin resource configuration.

While the primary REST API listener (configured via listeners) enforces configured authentication and authorization filters, endpoints mounted under the separate admin listener (/admin/loggers) fail to inherit or instantiate these extension filters. As a result, the admin logger endpoint accepts unauthenticated read and write requests even when security extensions are active on the main listener.

Credit: Bartłomiej Dmitruk (Striga) (reporter), Mickael Maison (remediation developer)

References: CVE-2026-115644

CVE-2026-111496 Apache Kafka: Kafka Streams StreamThread hang from integer overflow in stream-time punctuation

Kafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next() computed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no overflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that value, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then re-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread.

Credit: Mike Read (GitHub: Michael-JRead) (reporter), Matthias J. Sax (remediation developer)

References: CVE-2026-111496

CVE-2026-83525 Apache Kafka: Incorrect boolean operator in FetchSnapshot RPC handler allows authenticated network clients to crash the KRaft controller via a malformed request

Incorrect operator (CWE-480) in the FetchSnapshot RPC handler in Apache Kafka from 2.8.0 before 4.2.2, and from 4.3.0 before 4.3.2, on all platforms allows an authenticated attacker with CLUSTER_ACTION privilege to cause a denial of service (controller process termination) via a crafted FetchSnapshotRequest with an empty topics array or a topic with no partitions.

Users are recommended to upgrade to version 4.2.2, 4.3.2, or 4.4.0, which fix this issue. Users on unsupported branches (4.1.x and earlier) should upgrade to 4.2.2 or later.

Credit: Mike Read (GitHub: Michael-JRead) (reporter), Kevin Wu (remediation developer)

References: apache/kafka#23185, CVE-2026-83525

CVE-2026-41115 Apache Kafka: Improper Authorization in CONSUMER_GROUP_DESCRIBE API

The implementation of the CONSUMER_GROUP_DESCRIBE (69) API validates the DESCRIBE operation on the GROUP resource instead of the READ operation as documented in the official Kafka documentation and KIP-848. This discrepancy can result in misconfigured Access Control Lists (ACLs) and unintended security postures, like granting READ permission to users who should not be able to join/sync groups, or allowing users without READ permission (but with DESCRIBE permission) to access sensitive group metadata.

The correct permission for CONSUMER_GROUP_DESCRIBE API is DESCRIBE GROUP so the current implementation is correct. However, the Kafka documentation as well as KIP-848 have been updated to reflect the correct permission. We advise the Kafka users to review existing group ACLs to ensure the principle of least privilege.

CVE-2026-33558 Apache Kafka, Apache Kafka Clients: Information Exposure Through Network Client Log Output

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
• SaslAuthenticateResponse

CVE-2026-33557 Apache Kafka: Missing JWT token validation in OAUTHBEARER authentication

When sasl.enabled.mechanisms=OAUTHBEARER is configured on the server side, 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.

CVE-2026-35554 Apache Kafka Clients: Kafka Producer Message Corruption and Misrouting via Buffer Pool Race Condition

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 freed buffer before the original network request completes, the buffer contents may become corrupted. This can result in messages being delivered to unintended topics without any error being reported to the producer.

Data Confidentiality: Messages intended for one topic may be delivered to a different topic, potentially exposing sensitive data to consumers who have access to the destination topic but not the intended source topic.

Data Integrity: Consumers on the receiving topic may encounter unexpected or incompatible messages, leading to deserialization failures, processing errors, and corrupted downstream data.

Credit: Bharath Vissapragada (reporter), Donny Nadolny (finder, remediation developer)

References: KAFKA-19012, CVE-2026-35554

CVE-2025-27819 Apache Kafka: Possible RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration

In CVE-2023-25194, we announced the RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration in Kafka Connect API. But not only Kafka Connect API is vulnerable to this attack, the Apache Kafka brokers also have this vulnerability. To exploit this vulnerability, the attacker needs to be able to connect to the Kafka cluster and have the AlterConfigs permission on the cluster resource.

Since Apache Kafka 3.4.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default “com.sun.security.auth.module.JndiLoginModule” is disabled in Apache Kafka 3.4.0, and “com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule” is disabled by default in Apache Kafka 3.9.1/4.0.0.

CVE-2025-27818 Apache Kafka: Possible RCE attack via SASL JAAS LdapLoginModule configuration

A possible security vulnerability has been identified in Apache Kafka. This requires access to a alterConfig to the cluster resource, or Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config and a SASL-based security protocol, which has been possible on Kafka clusters since Apache Kafka 2.0.0 (Kafka Connect 2.3.0). When configuring the broker via config file or AlterConfig command, or connector via the Kafka Kafka Connect REST API, an authenticated operator can set the sasl.jaas.config property for any of the connector’s Kafka clients to “com.sun.security.auth.module.LdapLoginModule”, which can be done via the producer.override.sasl.jaas.config, consumer.override.sasl.jaas.config, or admin.override.sasl.jaas.config properties. This will allow the server to connect to the attacker’s LDAP server and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server. Attacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath.

Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default “com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule” are disabled in Apache Kafka Connect 3.9.1/4.0.0.

CVE-2025-27817 Apache Kafka Client: Arbitrary file read and SSRF vulnerability

A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including “sasl.oauthbearer.token.endpoint.url” and “sasl.oauthbearer.jwks.endpoint.url”. Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the “sasl.oauthbearer.token.endpoint.url” and “sasl.oauthbearer.jwks.endpoint.url” configuration to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products.

Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls") to set the allowed urls in SASL JAAS configuration. In 3.9.1, it accepts all urls by default for backward compatibility. However in 4.0.0 and newer, the default value is empty list and users have to set the allowed urls explicitly.

CVE-2024-56128 SCRAM authentication vulnerable to replay attacks when used without encryption

Apache Kafka’s implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802. Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message. However, Kafka’s SCRAM implementation did not perform this validation.

This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is strongly discouraged as it is considered an insecure practice. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception. Deployments using SCRAM with TLS are not affected by this issue.

CVE-2024-31141 Files or Directories Accessible to External Parties, Improper Privilege Management vulnerability in Apache Kafka Clients

Apache Kafka Clients accept configuration data for customizing behavior, and includes ConfigProvider plugins in order to manipulate these configurations. Apache Kafka also provides FileConfigProvider, DirectoryConfigProvider, and EnvVarConfigProvider implementations which include the ability to read from disk or environment variables.

In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use these ConfigProviders to read arbitrary contents of the disk and environment variables. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment access, which may be undesirable in certain environments, including SaaS products.

CVE-2024-27309 Potential incorrect access control during migration from ZK mode to KRaft mode

While an Apache Kafka cluster is being migrated from ZooKeeper mode to KRaft mode, in some cases ACLs will not be correctly enforced. Two preconditions are needed to trigger the bug:

1. The administrator decides to remove an ACL
2. The resource associated with the removed ACL continues to have two or more other ACLs associated with it after the removal. When those two preconditions are met, Kafka will treat the resource as if it had only one ACL associated with it after the removal, rather than the two or more that would be correct. The incorrect condition is cleared by removing all brokers in ZK mode, or by adding a new ACL to the affected resource. Once the migration is completed, there is no metadata loss (the ACLs all remain).

CVE-2023-34455 Clients using Snappy compression may cause out of memory error on brokers

This CVE identifies a vulnerability in snappy-java which could be used to cause an Out-of-Memory (OOM) condition, leading to Denial-of-Service(DoS) on the Kafka broker. The vulnerability allows any user who can producer data to the broker to exploit the vulnerability by sending a malicious payload in the record which is compressed using snappy. For more details on the vulnerability, please refer to the following link: snappy-java GitHub advisory.

CVE-2023-25194 Possible RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration using Apache Kafka Connect API

A possible security vulnerability has been identified in Apache Kafka Connect API. This requires access to a Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config and a SASL-based security protocol, which has been possible on Kafka Connect clusters since Apache Kafka 2.3.0. This will allow to perform JNDI requests that result in Denial of service/remote code execution.

CVE-2022-34917 Unauthenticated clients may cause OutOfMemoryError on brokers

This CVE identified a flaw where it allows the malicious unauthenticated clients to allocate large amounts of memory on brokers. This can lead to brokers hitting OutOfMemoryException and causing denial of service.

CVE-2022-23302 Deserialization of Untrusted Data Flaw in JMSSink of Apache Log4j logging library in versions 1.x

This CVE identified a flaw where it allows the attacker to provide a TopicConnectionFactoryBindingName configuration that will cause JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104.

CVE-2022-23305 SQL injection Flaw in Apache Log4j logging library in versions 1.x

This CVE identified a flaw where it allows a remote attacker to run SQL statements in the database if the deployed application is configured to use JDBCAppender with certain interpolation tokens.

CVE-2022-23307 Deserialization of Untrusted Data Flaw in Apache Log4j logging library in versions 1.x

This CVE identified a flaw where it allows an attacker to send a malicious request with serialized data to the component running log4j 1.x to be deserialized when the chainsaw component is run. Chainsaw is a standalone GUI for viewing log entries in log4j. An attacker not only needs to be able to generate malicious log entries, but also, have the necessary access and permissions to start chainsaw (or if it is already enabled by a customer / consumer of Apache Kafka).

CVE-2021-45046 Flaw in Apache Log4j logging library in versions from 2.0-beta9 through 2.12.1 and from 2.13.0 through 2.15.0

Some components in Apache Kafka use Log4j-v1.2.17 there is no dependence on Log4j v2.*. Check with the vendor of any connector plugin that includes a Log4J 2.x JAR file.

Users should NOT be impacted by this vulnerability

CVE-2021-44228 Flaw in Apache Log4j logging library in versions from 2.0.0 and before 2.15.0

Some components in Apache Kafka use Log4j-v1.2.17 there is no dependence on Log4j v2.*. Check with the vendor of any connector plugin that includes a Log4J 2.x JAR file.

Lookups feature was introduced in Log4j v2.x in order to allow specifying Log4j configuration parameters in arbitrary locations (even outside of the configuration files). Log4j v1.x does not offer the same functionality and thus is not vulnerable to CVE-2021-44228.

Users should NOT be impacted by this vulnerability

CVE-2021-4104 Flaw in Apache Log4j logging library in versions 1.x

The following components in Apache Kafka use Log4j-v1.2.17: broker, controller, zookeeper, connect, mirrormaker and tools. Clients may also be configured to use Log4j-v1.x.

Version 1.x of Log4J can be configured to use JMS Appender, which publishes log events to a JMS Topic. Log4j 1.x is vulnerable if the deployed application is configured to use JMSAppender.

CVE-2021-38153 Timing Attack Vulnerability for Apache Kafka Connect and Clients

Some components in Apache Kafka use Arrays.equals to validate a password or key, which is vulnerable to timing attacks that make brute force attacks for such credentials more likely to be successful. Users should upgrade to 2.8.1 or higher, or 3.0.0 or higher where this vulnerability has been fixed.

CVE-2019-12399 Apache Kafka Connect REST API may expose plaintext secrets in tasks endpoint

When Connect workers in Apache Kafka 2.0.0, 2.0.1, 2.1.0, 2.1.1, 2.2.0, 2.2.1, or 2.3.0 are configured with one or more config providers, and a connector is created/updated on that Connect cluster to use an externalized secret variable in a substring of a connector configuration property value (the externalized secret variable is not the whole configuration property value), then any client can issue a request to the same Connect cluster to obtain the connector’s task configurations and the response will contain the plaintext secret rather than the externalized secrets variable. Users should upgrade to 2.2.2 or higher, or 2.3.1 or higher where this vulnerability has been fixed.

CVE-2018-17196 Authenticated clients with Write permission may bypass transaction/idempotent ACL validation

In Apache Kafka versions between 0.11.0.0 and 2.1.0, it is possible to manually craft a Produce request which bypasses transaction/idempotent ACL validation. Only authenticated clients with Write permission on the respective topics are able to exploit this vulnerability. Users should upgrade to 2.1.1 or later where this vulnerability has been fixed.

CVE-2018-1288 Authenticated Kafka clients may interfere with data replication

Authenticated Kafka users may perform action reserved for the Broker via a manually created fetch request interfering with data replication, resulting in data loss.

CVE-2017-12610 Authenticated Kafka clients may impersonate other users

Authenticated Kafka clients may use impersonation via a manually crafted protocol message with SASL/PLAIN or SASL/SCRAM authentication when using the built-in PLAIN or SCRAM server implementations in Apache Kafka.

4 - Developer Guide

Getting the code

Our code is kept in Apache GitHub repo. You can check it out like this:

git clone https://github.com/apache/kafka.git kafka

Information on contributing patches can be found here.

Official releases are available here.

The source code for the web site and documentation can be checked out from Apache GitHub repo:

git clone -b asf-site https://github.com/apache/kafka-site.git

We are happy to received patches for the website and documentation. We think documentation is a core part of the project and welcome any improvements, suggestions, or clarifications. The procedure of contributing to the documentation can also be found here.

To setup IDEs for development, following this guide on the wiki.

How to contribute

We are always very happy to have contributions, whether for trivial cleanups or big new features.

If you don’t know Java or Scala you can still contribute to the project. An important area is the clients. We want to have high quality, well documented clients for each programming language. These, as well as the surrounding ecosystem of integration tools that people use with Kafka®, are critical aspects of the project.

Nor is code the only way to contribute to the project. We strongly value documentation and gladly accept improvements to the documentation.

Reporting An Issue

Reporting potential issues as JIRA tickets is more than welcome as a significant contribution to the project. But please be aware that JIRA tickets should not be used for FAQs: if you have a question or are simply not sure if it is really an issue or not, please contact us first before you create a new JIRA ticket. To create a new JIRA ticket, please follow the instructions in this page.

Contributing A Code Change

To submit a change for inclusion, please do the following:

• If the change is non-trivial please include some unit tests that cover the new functionality.
• If you are introducing a completely new feature or API it is a good idea to start a wiki and get consensus on the basic design first.
• Make sure you have observed the recommendations in the style guide.
• Follow the detailed instructions in Contributing Code Changes.
• Note that if the change is related to user-facing protocols / interface / configs, etc, you need to make the corresponding change on the documentation as well. For wiki page changes feel free to edit the page content directly (you may need to contact us to get the permission first if it is your first time to edit on wiki); website docs live in the code repo under docs so that changes to that can be done in the same PR as changes to the code. Website doc change instructions are given below.
• It is our job to follow up on patches in a timely fashion. Nag us if we aren’t doing our job (sometimes we drop things).

Contributing A Change To The Website

To submit a change for inclusion please do the following:

• Follow the instructions in Contributing Website Changes.
• It is our job to follow up on patches in a timely fashion. Nag us if we aren’t doing our job (sometimes we drop things). If the patch needs improvement, the reviewer will mark the jira back to “In Progress” after reviewing.

Finding A Project To Work On

The easiest way to get started working with the code base is to pick up a really easy JIRA and work on that. This will help you get familiar with the code base, build system, review process, etc. We flag these kind of starter bugs here.

Please request a JIRA account using ASF’s Self-serve portal. After that you can assign yourself to the JIRA ticket you have started working on so others will notice.

If your work is considered a “major change” then you would need to initiate a Kafka Improvement Proposal (KIP) along with the JIRA ticket (more details can be found here). Please ask us to grant you the permission on wiki space in order to create a KIP wiki page.

Once you have gotten through the basic process of checking in code, you may want to move on to a more substantial project. We try to curate this kind of project as well, and you can find these here.

Becoming a Committer

We are always interested in adding new contributors. What we look for is a series of contributions, good taste, and an ongoing interest in the project. Kafka PMC looks at the following guidelines for promoting new committers:

• Made significant contributions in areas such as design, code and/or documentation. The following are some examples (list not exclusive):
  • Submitted and completed non-trivial KIPs.
  • Fixed critical bugs (including performance improvements).
  • Made major tech-debt cleanup.
  • Made major documentation (web docs and java docs) improvements.
• Consistently helped the community in at least one of the following areas since more than 6 months back (list not exclusive):
  • Mailing list participation.
  • Code reviews and KIP reviews.
  • Release validations including testing and benchmarking, etc.
  • Evangelism events: technical talks, blog posts, etc.
• Demonstrated good understanding and exercised good technical judgement on at least one component of the codebase (e.g. core, clients, connect, streams, tests) from contribution activities in the above mentioned areas.

Collaborators

The Apache build infrastructure has provided two roles to make project management easier. These roles allow non-committers to perform some administrative actions like triaging pull requests or triggering builds. See the ASF documentation (note: you need to be logged in to the wiki):

• Jenkins PR Whitelisted Users
• Github Collaborators

In an effort to keep the Apache Kafka project running smoothly, and also to help contributors become committers, we have enabled these roles (See the Apache Kafka Infra config). To keep this process lightweight and fair, we keep the list of contributors full by specifying the top N non-committers (sorted by number of commits they have authored in the last 12 months), where N is the maximum size of that list (currently 10). Authorship is determined by git shortlog. The list will be updated as part of the major/minor release process, three to four times a year.

Coding guidelines

These guidelines are meant to encourage consistency and best practices amongst people working on the Kafka® code base. They should be observed unless there is a compelling reason to ignore them.

Basic Stuff

• Avoid cryptic abbreviations. Single letter variable names are fine in very short methods with few variables, otherwise make them informative.
• Clear code is preferable to comments. When possible make your naming so good you don’t need comments. When that isn’t possible comments should be thought of as mandatory, write them to be read.
• Logging, configuration, and public APIs are our “UI”. Pay special attention to them and make them pretty, consistent, and usable.
• There is not a maximum line length (certainly not 80 characters, we don’t work on punch cards any more), but be reasonable.
• Don’t be sloppy. Don’t check in commented out code: we use version control, it is still there in the history. Don’t leave TODOs in the code or FIXMEs if you can help it. Don’t leave println statements in the code. Hopefully this is all obvious.
• We want people to use our stuff, which means we need clear, correct documentation. User documentation should be considered a part of any user-facing the feature, just like unit tests or performance results.
• Don’t duplicate code (duh).
• Kafka is system software, and certain things are appropriate in system software that are not appropriate elsewhere. Sockets, bytes, concurrency, and distribution are our core competency which means we will have a more “from scratch” implementation of some of these things then would be appropriate for software elsewhere in the stack. This is because we need to be exceptionally good at these things. This does not excuse fiddly low-level code, but it does excuse spending a little extra time to make sure that our filesystem structures, networking code, threading model, are all done perfectly right for our application rather than just trying to glue together ill-fitting off-the-shelf pieces (well-fitting off-the-shelf pieces are great though).

Scala

We are following the style guide given here (though not perfectly). Below are some specifics worth noting:

• Scala is a very flexible language. Use restraint. Magic cryptic one-liners do not impress us, readability impresses us.
• Use vals when possible.
• Use private when possible for member variables.
• Method and member variable names should be in camel case with an initial lower case character like aMethodName.
• Constants should be camel case with an initial capital LikeThis not LIKE_THIS.
• Prefer a single top-level class per file for ease of finding things.
• Do not use semi-colons unless required.
• Avoid getters and setters - stick to plain vals or vars instead. If (later on) you require a custom setter (or getter) for a var named myVar then add a shadow var myVar_underlying and override the setter (def myVar_=) and the getter (def myVar = myVar_underlying).
• Prefer Option to null in scala APIs.
• Use named arguments when passing in literal values if the meaning is at all unclear, for example instead of Utils.delete(true) prefer Utils.delete(recursive=true).
• Indentation is 2 spaces and never tabs. One could argue the right amount of indentation, but 2 seems to be standard for scala and consistency is best here since there is clearly no “right” way.
• Include the optional parenthesis on a no-arg method only if the method has a side-effect, otherwise omit them. For example fileChannel.force() and fileChannel.size. This helps emphasize that you are calling the method for the side effect, which is changing some state, not just getting the return value.
• Prefer case classes to tuples in important APIs to make it clear what the intended contents are.

Logging

• Logging is one third of our “UI” and it should be taken seriously. Please take the time to assess the logs when making a change to ensure that the important things are getting logged and there is no junk there.
• Logging statements should be complete sentences with proper capitalization that are written to be read by a person not necessarily familiar with the source code. It is fine to put in hacky little logging statements when debugging, but either clean them up or remove them before checking in. So logging something like “INFO: entering SyncProducer send()” is not appropriate.
• Logging should not mention class names or internal variables.
• There are six levels of logging TRACE, DEBUG, INFO, WARN, ERROR, and FATAL, they should be used as follows.
  • INFO is the level you should assume the software will be run in. INFO messages are things which are not bad but which the user will definitely want to know about every time they occur.
  • TRACE and DEBUG are both things you turn on when something is wrong and you want to figure out what is going on. DEBUG should not be so fine grained that it will seriously effect the performance of the server. TRACE can be anything. Both DEBUG and TRACE statements should be wrapped in an if(logger.isDebugEnabled) check to avoid pasting together big strings all the time.
  • WARN and ERROR indicate something that is bad. Use WARN if you aren’t totally sure it is bad, and ERROR if you are.
  • Use FATAL only right before calling System.exit().

Monitoring

• Monitoring is the second third of our “UI” and it should also be taken seriously.
• We use JMX for monitoring.
• Any new features should come with appropriate monitoring to know the feature is working correctly. This is at least as important as unit tests as it verifies production.

Unit Tests

• New patches should come with unit tests that verify the functionality being added.
• Unit tests are first rate code, and should be treated like it. They should not contain code duplication, cryptic hackery, or anything like that.
• Be aware of the methods in kafka.utils.TestUtils, they make a lot of the below things easier to get right.
• Unit tests should test the least amount of code possible, don’t start the whole server unless there is no other way to test a single class or small group of classes in isolation.
• Tests should not depend on any external resources, they need to set up and tear down their own stuff. This means if you want zookeeper it needs to be started and stopped, you can’t depend on it already being there. Likewise if you need a file with some data in it, you need to write it in the beginning of the test and delete it (pass or fail).
• It is okay to use the filesystem and network in tests since that is our business but you need to clean up after yourself. There are helpers for this in TestUtils.
• Do not use sleep or other timing assumptions in tests, it is always, always, always wrong and will fail intermittently on any test server with other things going on that causes delays. Write tests in such a way that they are not timing dependent. Seriously. One thing that will help this is to never directly use the system clock in code (i.e. System.currentTimeMillis) but instead to use the kafka.utils.Time. This is a trait that has a mock implementation allowing you to programmatically and deterministically cause the passage of time when you inject this mock clock instead of the system clock.
• It must be possible to run the tests in parallel, without having them collide. This is a practical thing to allow multiple branches to CI on a single CI server. This means you can’t hard code directories or ports or things like that in tests because two instances will step on each other. Again TestUtils has helpers for this stuff (e.g. TestUtils.choosePort will find a free port for you).

Configuration

• Configuration is the final third of our “UI”.
• Names should be thought through from the point of view of the person using the config, but often programmers choose configuration names that make sense for someone reading the code.
• Often the value that makes most sense in configuration is not the one most useful to program with. For example, let’s say you want to throttle I/O to avoid using up all the I/O bandwidth. The easiest thing to implement is to give a “sleep time” configuration that let’s the program sleep after doing I/O to throttle down its rate. But notice how hard it is to correctly use this configuration parameter, the user has to figure out the rate of I/O on the machine, and then do a bunch of arithmetic to calculate the right sleep time to give the desired rate of I/O on the system. It is much, much, much better to just have the user configure the maximum I/O rate they want to allow (say 5MB/sec) and then calculate the appropriate sleep time from that and the actual I/O rate. Another way to say this is that configuration should always be in terms of the quantity that the user knows, not the quantity you want to use.
• Configuration is the answer to problems we can’t solve up front for some reason–if there is a way to just choose a best value do that instead.
• Configuration should come from the instance-level properties file. No additional sources of config (environment variables, system properties, etc) should be added as these usually inhibit running multiple instances of a broker on one machine.

Concurrency

• Encapsulate synchronization. That is, locks should be private member variables within a class and only one class or method should need to be examined to verify the correctness of the synchronization strategy.
• Annotate things as @threadsafe when they are supposed to be and @notthreadsafe when they aren’t to help track this stuff.
• There are a number of gotchas with threads and threadpools: is the daemon flag set appropriately for your threads? are your threads being named in a way that will distinguish their purpose in a thread dump? What happens when the number of queued tasks hits the limit (do you drop stuff? do you block?).
• Prefer the java.util.concurrent packages to either low-level wait-notify, custom locking/synchronization, or higher level scala-specific primitives. The util.concurrent stuff is well thought out and actually works correctly. There is a generally feeling that threads and locking are not going to be the concurrency primitives of the future because of a variety of well-known weaknesses they have. This is probably true, but they have the advantage of actually being mature enough to use for high-performance software right now ; their well-known deficiencies are easily worked around by equally well known best-practices. So avoid actors, software transactional memory, tuple spaces, or anything else not written by Doug Lea and used by at least a million other productions systems. :-)

Backwards Compatibility

• Our policy is that the Kafka protocols and data formats should support backwards compatibility for as many releases to enable no-downtime upgrades (unless there is a very compelling counter-argument). This means the server MUST be able to support requests from both old and new clients simultaneously. This compatibility needs to be retained for at least one major release (e.g. 2.0 must accept requests from 1.0 clients). A typical upgrade sequence for binary format changes would be (1) upgrade server to handle the new message format, (2) upgrade clients to use the new message format.
• There are three things which require this binary compatibility: request objects, persistent data structure (messages and message sets), and zookeeper structures and protocols. The message binary structure has a “magic” byte to allow it to be evolved, this number should be incremented when the format is changed and the number can be checked to apply the right logic and fill in defaults appropriately. Network requests have a request id which serve a similar purpose, any change to a request object must be accompanied by a change in the request id. Any change here should be accompanied by compatibility tests that save requests or messages in the old format as a binary file which is tested for compatibility with the new code.

Client Code

There are a few things that need to be considered in client code that are not a major concern on the server side.

• Libraries needed by the client should be avoided whenever possible. Clients are run in someone else’s code and it is very possible that they may have the same library we have, but a different and incompatible version. This will mean they can’t use our client. For this reason the client should not use any libraries that are not strictly necessary.
• We should maintain API compatibility. Any incompatible changes should be ultimately settled in the KIP design process, where the usual strategy is to retain the old APIs, mark them as deprecated and potentially remove them in some next major release.

Streams API

Kafka’s Streams API (aka Kafka Streams) uses a few more additional coding guidelines. All contributors should follow these the get a high quality and uniform code base. Some rules help to simplify PR reviews and thus make the life of all contributors easier.

• Use final when possible. This holds for all class members, local variables, loop variables, and method parameters.
• Write modular and thus testable code. Refactor if necessary!
• Avoid large PRs (recommended is not more the 500 lines per PR). Many JIRAs requires larger code changes; thus, split the work in multiple PRs and create according sub-task on the JIRA to track the work.
• All public APIs must have JavaDocs.
• Verify if JavaDocs are still up to date or if they need to be updated.
• JavaDocs: Write grammatically correct sentences and use punctuation marks correctly.
• Use proper markup (e.g., {@code null}).
• Update the documentation on the Kafka webpage (i.e., within folder docs/. Doc changes are not additional work (i.e., no follow up PRs) but part of the actual PR (can also be a sub-task).
• Testing:
  • Use self-explaining method names (e.g., shouldNotAcceptNullAsTopicName()).
  • Each test should cover only a single case.
  • Keep tests as short as possible (i.e., write crisp code).
  • Write tests for all possible parameter values.
  • Don’t use reflections but rewrite your code (reflections indicate bad design in the first place).
  • Use annotations such as @Test(expected = SomeException.class) only for single line tests.
• Code formatting (those make Github diffs easier to read and thus simplify code reviews):
  • No line should be longer than 120 characters.
  • Use a “single parameter per line” formatting when defining methods (also for methods with only 2 parameters).
  • If a method call is longer than 120 characters, switch to a single parameter per line formatting (instead of just breaking it into two lines only).
  • For JavaDocs, start a new line for each new sentence.
  • Avoid unnecessary reformatting.
  • If reformatting is neccessary, do a minor PR (either upfront or as follow up).
• Run ./gradlew clean checkstyleMain checkstyleTest before opening/updating a PR.
• Help reviewing! No need to be shy; if you can contribute code, you know enough to comment on the work of others.

5 - Downloads

The project goal is to have 3 releases a year, which means a release every 4 months. Bugfix releases are made as needed for supported releases only. It is possible to verify every download by following these procedures and using these KEYS.

Supported releases

4.4.0

• Released October 22, 2026
• Release Notes
• Docker image: apache/kafka:4.4.0.
• Docker Native image: apache/kafka-native:4.4.0.
• Source download: kafka-4.4.0-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.4.0.tgz (asc, sha512)

Kafka 4.4.0 includes a significant number of new features and fixes. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

4.3.2

• Released October 23, 2026
• Release Notes
• Docker image: apache/kafka:4.3.2.
• Docker Native image: apache/kafka-native:4.3.2.
• Source download: kafka-4.3.2-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.3.2.tgz (asc, sha512)

Kafka 4.3.2 fixes around 60 issues since the 4.3.1 release, most notably two potential data loss issues in tiered storage size-retention (KAFKA-20732) and time index truncation (KAFKA-20979), along with dependency updates addressing published CVEs in jackson-databind, lz4-java, log4j and jetty. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

4.2.2

• Released September 29, 2026
• Release Notes
• Docker image: apache/kafka:4.2.2.
• Docker Native image: apache/kafka-native:4.2.2.
• Source download: kafka-4.2.2-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.2.2.tgz (asc, sha512)

Kafka 4.2.2 fixes around 33 issues since the 4.2.1 release. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

Archived Releases

4.3.1

• Released June 25, 2026
• Release Notes
• Docker image: apache/kafka:4.3.1.
• Docker Native image: apache/kafka-native:4.3.1.
• Source download: kafka-4.3.1-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.3.1.tgz (asc, sha512)

Kafka 4.3.1 fixes around 15 issues since the 4.3.0 release, most notably a critical Kafka Streams RocksDB native memory leak (KAFKA-20616). For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

4.3.0

• Released May 22, 2026
• Release Notes
• Docker image: apache/kafka:4.3.0.
• Docker Native image: apache/kafka-native:4.3.0.
• Source download: kafka-4.3.0-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.3.0.tgz (asc, sha512)

Kafka 4.3.0 includes a significant number of new features and fixes. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

4.2.1

• Released May 30, 2026
• Release Notes
• Docker image: apache/kafka:4.2.1.
• Docker Native image: apache/kafka-native:4.2.1.
• Source download: kafka-4.2.1-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.2.1.tgz (asc, sha512)

Kafka 4.2.1 fixes around 25 issues since the 4.2.0 release. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

4.2.0

• Released February 17, 2026
• Release Notes
• Docker image: apache/kafka:4.2.0.
• Docker Native image: apache/kafka-native:4.2.0.
• Source download: kafka-4.2.0-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.2.0.tgz (asc, sha512)

Kafka 4.2.0 includes a significant number of new features and fixes. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

4.1.2

• Released March 17, 2026
• Release Notes
• Docker image: apache/kafka:4.1.2.
• Docker Native image: apache/kafka-native:4.1.2.
• Source download: kafka-4.1.2-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.1.2.tgz (asc, sha512)

Kafka 4.1.2 fixes 30 issues since the 4.1.1 release. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

4.1.1

• Released November 12, 2025
• Release Notes
• Docker image: apache/kafka:4.1.1.
• Docker Native image: apache/kafka-native:4.1.1.
• Source download: kafka-4.1.1-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.1.1.tgz (asc, sha512)

Kafka 4.1.1 fixes 18 issues since the 4.1.0 release. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

4.1.0

• Released September 2, 2025
• Release Notes
• Docker image: apache/kafka:4.1.0.
• Docker Native image: apache/kafka-native:4.1.0.
• Source download: kafka-4.1.0-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.1.0.tgz (asc, sha512)

Kafka 4.1.0 includes a significant number of new features and fixes. For more information, please read our blog post and the detailed Release Notes.

4.0.2

• Released March 16, 2026
• Release Notes
• Docker image: apache/kafka:4.0.2.
• Docker Native image: apache/kafka-native:4.0.2.
• Source download: kafka-4.0.2-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.0.2.tgz (asc, sha512)

Kafka 4.0.2 fixes 42 issues since the 4.0.1 release. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

4.0.1

• Released October 13, 2025
• Release Notes
• Docker image: apache/kafka:4.0.1.
• Docker Native image: apache/kafka-native:4.0.1.
• Source download: kafka-4.0.1-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.0.1.tgz (asc, sha512)

Kafka 4.0.1 fixes 49 issues since the 4.0.0 release. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

4.0.0

• Released March 18, 2025
• Release Notes
• Docker image: apache/kafka:4.0.0.
• Docker Native image: apache/kafka-native:4.0.0.
• Source download: kafka-4.0.0-src.tgz (asc, sha512)
• Binary download: kafka_2.13-4.0.0.tgz (asc, sha512)

Kafka 4.0.0 includes a significant number of new features and fixes. For more information, please read our blog post and the detailed Release Notes.

3.9.2

• Released February 21, 2026
• Release Notes
• Docker image: apache/kafka:3.9.2.
• Docker Native image: apache/kafka-native:3.9.2.
• Source download: kafka-3.9.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.9.2.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.9.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise, any version should work (2.13 is recommended).

Kafka 3.9.2 fixes 35 issues since the 3.9.1 release. For more information, please read our blog post, the detailed Upgrade Notes and the Release Notes.

3.9.1

• Released May 21, 2025
• Release Notes
• Docker image: apache/kafka:3.9.1.
• Docker Native image: apache/kafka-native:3.9.1.
• Source download: kafka-3.9.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.9.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.9.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise, any version should work (2.13 is recommended).

Kafka 3.9.1 fixes 66 issues since the 3.9.0 release. For more information, please read our blog post and the detailed Release Notes.

3.9.0

• Released November 6, 2024
• Release Notes
• Docker image: apache/kafka:3.9.0.
• Docker Native image: apache/kafka-native:3.9.0.
• Source download: kafka-3.9.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.9.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.9.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise, any version should work (2.13 is recommended).

Kafka 3.9.0 includes a significant number of new features and fixes. For more information, please read our blog post and the detailed Release Notes.

3.8.1

• Released October 29, 2024
• Release Notes
• Docker image: apache/kafka:3.8.1.
• Docker Native image: apache/kafka-native:3.8.1.
• Source download: kafka-3.8.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.8.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.8.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise, any version should work (2.13 is recommended).

Kafka 3.8.1 includes a significant number of new features and fixes. For more information, please read our blog post and the detailed Release Notes.

3.8.0

• Released July 29, 2024
• Release Notes
• Docker image: apache/kafka:3.8.0.
• Docker Native image: apache/kafka-native:3.8.0.
• Source download: kafka-3.8.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.8.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.8.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.8.0 includes a significant number of new features and fixes. For more information, please read our blog post and the detailed Release Notes.

3.7.2

• Released Dec 13, 2024
• Release Notes
• Docker image: apache/kafka:3.7.2.
• Source download: kafka-3.7.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.7.2.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.7.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.7.2 fixes 21 issues since the 3.7.1 release. For more information, please read our blog post and the detailed Release Notes.

3.7.1

• Released Jun 28, 2024
• Release Notes
• Docker image: apache/kafka:3.7.1.
• Source download: kafka-3.7.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.7.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.7.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.7.1 includes a significant number of new features and fixes. For more information, please read our blog post and the detailed Release Notes.

3.7.0

• Released Feb 27, 2024
• Release Notes
• Docker image: apache/kafka:3.7.0.
• Source download: kafka-3.7.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.7.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.7.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.7.0 includes a significant number of new features and fixes. For more information, please read our blog post and the detailed Release Notes.

3.6.2

• Released Apr 4, 2024
• Release Notes
• Source download: kafka-3.6.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.6.2.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.6.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.6.2 fixes 28 issues since the 3.6.1 release. For more information, please read the detailed Release Notes.

3.6.1

• Released Dec 7, 2023
• Release Notes
• Source download: kafka-3.6.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.6.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.6.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.6.1 fixes 30 issues since the 3.6.0 release. For more information, please read the detailed Release Notes.

3.6.0

• Released Oct 10, 2023
• Release Notes
• Source download: kafka-3.6.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.6.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.6.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.6.0 includes a significant number of new features and fixes. For more information, please read our blog post and the detailed Release Notes.

3.5.2

• Released Dec 11, 2023
• Release Notes
• Source download: kafka-3.5.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.5.2.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.5.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.5.2 contains security fixes and bug fixes. For more information, please read our blog post and the detailed Release Notes.

3.5.1

• Released Jul 21, 2023
• Release Notes
• Source download: kafka-3.5.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.5.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.5.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.5.1 is a security patch release. It contains security fixes and regression fixes. For more information, please read our blog post and the detailed Release Notes.

3.5.0

• Released Jun 15, 2023
• Release Notes
• Source download: kafka-3.5.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.5.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.5.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.5.0 includes a significant number of new features and fixes. For more information, please read our blog post and the detailed Release Notes.

3.4.1

• Released Jun 6, 2023
• Release Notes
• Source download: kafka-3.4.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.4.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.4.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.4.1 fixes 58 issues since the 3.4.0 release. For more information, please read the detailed Release Notes

3.4.0

• Released Feb 7, 2023
• Release Notes
• Source download: kafka-3.4.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.4.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.4.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.4.0 includes a significant number of new features and fixes. For more information, please read our blog post and the detailed Release Notes.

3.3.2

• Released Jan 23, 2023
• Release Notes
• Source download: kafka-3.3.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.3.2.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.3.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.3.2 fixes 20 issues since the 3.3.1 release. For more information, please read the detailed Release Notes

3.3.1

• Released October 3, 2022
• 3.3.1 and 3.3.0 Release Notes
• Source download: kafka-3.3.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.3.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.3.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.3.1 includes a number of significant new features. Here is a summary of some notable changes:

• KIP-833: Mark KRaft as Production Ready
• KIP-778: KRaft to KRaft upgrades
• KIP-835: Monitor KRaft Controller Quorum health
• KIP-794: Strictly Uniform Sticky Partitioner
• KIP-834: Pause/resume KafkaStreams topologies
• KIP-618: Exactly-Once support for source connectors

For more information, please read the detailed 3.3.1 and 3.3.0 Release Notes.

3.3.0

A significant bug was found in the 3.3.0 release after artifacts were pushed to Apache and Maven central but prior to the release announcement. As a result, the decision was made to not announce 3.3.0 and instead release 3.3.1 with the fix. It is recommended that 3.3.0 not be used.

3.2.3

• Released Sept 19, 2022
• Release Notes
• Source download: kafka-3.2.3-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.2.3.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.2.3.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.2.3 fixes CVE-2022-34917 and 7 other issues since the 3.2.1 release. For more information, please read the detailed Release Notes.

3.2.2

A significant bug was found in the 3.2.2 release after artifacts were pushed to Maven central but prior to the release announcement. As a result the decision was taken to not announce 3.2.2 and release 3.2.3 with the fix. It is recommended that 3.2.2 not be used.

3.2.1

• Released Jul 29, 2022
• Release Notes
• Source download: kafka-3.2.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.2.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.2.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.2.1 fixes 13 issues since the 3.2.0 release. For more information, please read the detailed Release Notes.

3.2.0

• Released May 17, 2022
• Release Notes
• Source download: kafka-3.2.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.2.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.2.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.2.0 includes a number of significant new features. Here is a summary of some notable changes:

• log4j 1.x is replaced with reload4j
• StandardAuthorizer for KRaft (KIP-801)
• Send a hint to the partition leader to recover the partition (KIP-704)
• Top-level error code field in DescribeLogDirsResponse (KIP-784)
• kafka-console-producer writes headers and null values (KIP-798 and KIP-810)
• JoinGroupRequest and LeaveGroupRequest have a reason attached (KIP-800)
• Static membership protocol lets the leader skip assignment (KIP-814)
• Rack-aware standby task assignment in Kafka Streams (KIP-708)
• Interactive Query v2 (KIP-796, KIP-805, and KIP-806)
• Connect APIs list all connector plugins and retrieve their configuration (KIP-769)
• TimestampConverter SMT supports different unix time precisions (KIP-808)
• Connect source tasks handle producer exceptions (KIP-779)

For more information, please read the detailed Release Notes.

3.1.2

• Released Sept 19, 2022
• Release Notes
• Source download: kafka-3.1.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.1.2.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.1.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.1.2 fixes CVE-2022-34917 and 4 other issues since the 3.1.1 release. For more information, please read the detailed Release Notes.

3.1.1

• Released May 13, 2022
• Release Notes
• Source download: kafka-3.1.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.1.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.1.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.1.1 fixes 29 issues since the 3.1.0 release. For more information, please read the detailed Release Notes.

3.1.0

• Released January 24, 2022
• Release Notes
• Source download: kafka-3.1.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.1.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.1.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.1.0 includes a number of significant new features. Here is a summary of some notable changes:

• Apache Kafka supports Java 17
• The FetchRequest supports Topic IDs (KIP-516)
• Extend SASL/OAUTHBEARER with support for OIDC (KIP-768)
• Add broker count metrics (KIP-748)
• Differentiate consistently metric latency measured in millis and nanos (KIP-773)
• The eager rebalance protocol is deprecated (KAFKA-13439)
• Add TaskId field to StreamsException (KIP-783)
• Custom partitioners in foreign-key joins (KIP-775)
• Fetch/findSessions queries with open endpoints for SessionStore/WindowStore (KIP-766)
• Range queries with open endpoints (KIP-763)
• Add total blocked time metric to Streams (KIP-761)
• Add additional configuration to control MirrorMaker2 internal topics naming convention (KIP-690)

For more information, please read the detailed Release Notes.

3.0.2

• Released Sept 19, 2022
• Release Notes
• Source download: kafka-3.0.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.0.2.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.0.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.0.2 fixes CVE-2022-34917 and 10 other issues since the 3.0.1 release. For more information, please read the detailed Release Notes.

3.0.1

• Released March 11, 2022
• Release Notes
• Source download: kafka-3.0.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.0.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.0.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.0.1 fixes 29 issues since the 3.0.0 release. For more information, please read the detailed Release Notes.

3.0.0

• Released September 21, 2021
• Release Notes
• Source download: kafka-3.0.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-3.0.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-3.0.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 3.0.0 includes a number of significant new features. Here is a summary of some notable changes:

• The deprecation of support for Java 8 and Scala 2.12
• Kafka Raft support for snapshots of the metadata topic and other improvements in the self-managed quorum
• Stronger delivery guarantees for the Kafka producer enabled by default
• Deprecation of message formats v0 and v1
• Optimizations in OffsetFetch and FindCoordinator requests
• More flexible Mirror Maker 2 configuration and deprecation of Mirror Maker 1
• Ability to restart a connector’s tasks on a single call in Kafka Connect
• Connector log contexts and connector client overrides are now enabled by default
• Enhanced semantics for timestamp synchronization in Kafka Streams
• Revamped public API for Stream’s TaskId
• Default serde becomes null in Kafka

For more information, please read the detailed Release Notes.

2.8.2

• Released September 19, 2022
• Release Notes
• Source download: kafka-2.8.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.8.2.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.8.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 2.8.2 fixes CVE-2022-34917 and 11 other issues since the 2.8.1 release. For more information, please read the detailed Release Notes.

2.8.1

• Released September 17, 2021
• Release Notes
• Source download: kafka-2.8.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.8.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.8.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 2.8.1 fixes 49 issues since the 2.8.0 release. For more information, please read the detailed Release Notes.

2.8.0

• Released April 19, 2021
• Release Notes
• Source download: kafka-2.8.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.8.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.8.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 2.8.0 includes a number of significant new features. Here is a summary of some notable changes:

• Early access of replace ZooKeeper with a self-managed quorum
• Add Describe Cluster API
• Support mutual TLS authentication on SASL_SSL listeners
• JSON request/response debug logs
• Limit broker connection creation rate
• Topic identifiers
• Expose task configurations in Connect REST API
• Update Streams FSM to clarify ERROR state meaning
• Extend StreamJoined to allow more store configs
• More convenient TopologyTestDriver construtors
• Introduce Kafka-Streams-specific uncaught exception handler
• API to start and shut down Streams threads
• Improve TimeWindowedDeserializer and TimeWindowedSerde to handle window size
• Improve timeouts and retries in Kafka Streams

For more information, please read the detailed Release Notes.

2.7.2

• Released November 15, 2021
• Release Notes
• Source download: kafka-2.7.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.7.2.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.7.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 2.7.2 fixes 26 issues since the 2.7.1 release. For more information, please read the detailed Release Notes.

2.7.1

• Released May 10, 2021
• Release Notes
• Source download: kafka-2.7.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.7.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.7.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 2.7.1 fixes 45 issues since the 2.7.0 release. For more information, please read the detailed Release Notes.

2.7.0

• Released Dec 21, 2020
• Release Notes
• Source download: kafka-2.7.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.7.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.7.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 2.7.0 includes a number of significant new features. Here is a summary of some notable changes:

• Configurable TCP connection timeout and improve the initial metadata fetch
• Enforce broker-wide and per-listener connection creation rate (KIP-612, part 1)
• Throttle Create Topic, Create Partition and Delete Topic Operations
• Add TRACE-level end-to-end latency metrics to Streams
• Add Broker-side SCRAM Config API
• Support PEM format for SSL certificates and private key
• Add RocksDB Memory Consumption to RocksDB Metrics
• Add Sliding-Window support for Aggregations

For more information, please read the detailed Release Notes.

2.6.3

• Released November 15, 2021
• Release Notes
• Source download: kafka-2.6.3-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.6.3.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.6.3.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 2.6.3 fixes 11 issues since the 2.6.2 release. For more information, please read the detailed Release Notes.

2.6.2

• Released April 20, 2021
• Release Notes
• Source download: kafka-2.6.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.6.2.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.6.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 2.6.2 fixes 35 issues since the 2.6.1 release. For more information, please read the detailed Release Notes.

2.6.1

• Released January 07, 2021
• Release Notes
• Source download: kafka-2.6.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.6.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.6.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 2.6.1 fixes 41 issues since the 2.6.0 release. For more information, please read the detailed Release Notes.

2.6.0

• Released Aug 3, 2020
• Release Notes
• Source download: kafka-2.6.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.6.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.6.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.13 is recommended).

Kafka 2.6.0 includes a number of significant new features. Here is a summary of some notable changes:

• TLSv1.3 has been enabled by default for Java 11 or newer
• Significant performance improvements, especially when the broker has large numbers of partitions
• Smooth scaling out of Kafka Streams applications
• Kafka Streams support for emit on change
• New metrics for better operational insight
• Kafka Connect can automatically create topics for source connectors when configured to do so
• Improved error reporting options for sink connectors in Kafka Connect
• New Filter and conditional SMTs in Kafka Connect
• The default value for the client.dns.lookup configuration is now use_all_dns_ips
• Upgrade Zookeeper to 3.5.8

For more information, please read the detailed Release Notes.

2.5.1

• Released August 10, 2020
• Release Notes
• Source download: kafka-2.5.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.5.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.5.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

Kafka 2.5.1 fixes 72 issues since the 2.5.0 release. For more information, please read the detailed Release Notes.

2.5.0

• Released April 15, 2020
• Release Notes
• Source download: kafka-2.5.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.12 - kafka_2.12-2.5.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.5.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

Kafka 2.5.0 includes a number of significant new features. Here is a summary of some notable changes:

• TLS 1.3 support (1.2 is now the default)
• Co-groups for Kafka Streams
• Incremental rebalance for Kafka Consumer
• New metrics for better operational insight
• Upgrade Zookeeper to 3.5.7
• Deprecate support for Scala 2.11

For more information, please read the detailed Release Notes.

2.4.1

• Released March 12, 2020
• Release Notes
• Source download: kafka-2.4.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.4.1.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.4.1.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.4.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

For more information, please read the detailed Release Notes.

2.4.0

• Released December 16, 2019
• Release Notes
• Source download: kafka-2.4.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.4.0.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.4.0.tgz (asc, sha512)
  • Scala 2.13 - kafka_2.13-2.4.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

Kafka 2.4.0 includes a number of significant new features. Here is a summary of some notable changes:

• Allow consumers to fetch from closest replica.
• Support for incremental cooperative rebalancing to the consumer rebalance protocol.
• MirrorMaker 2.0 (MM2), a new multi-cluster, cross-datacenter replication engine.
• New Java authorizer Interface.
• Support for non-key joining in KTable.
• Administrative API for replica reassignment.

For more information, please read the detailed Release Notes.

2.3.1

• Released Oct 24, 2019
• Release Notes
• Source download: kafka-2.3.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.3.1.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.3.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

For more information, please read the detailed Release Notes.

2.3.0

• Released Jun 25, 2019
• Release Notes
• Source download: kafka-2.3.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.3.0.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.3.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

Kafka 2.3.0 includes a number of significant new features. Here is a summary of some notable changes:

• There have been several improvements to the Kafka Connect REST API.
• Kafka Connect now supports incremental cooperative rebalancing.
• Kafka Streams now supports an in-memory session store and window store.
• The AdminClient now allows users to determine what operations they are authorized to perform on topics.
• There is a new broker start time metric.
• JMXTool can now connect to secured RMI ports.
• An incremental AlterConfigs API has been added. The old AlterConfigs API has been deprecated.
• We now track partitions which are under their min ISR count.
• Consumers can now opt-out of automatic topic creation, even when it is enabled on the broker.
• Kafka components can now use external configuration stores (KIP-421).
• We have implemented improved replica fetcher behavior when errors are encountered.

For more information, please read the detailed Release Notes.

2.2.2

• Released Dec 1, 2019
• Release Notes
• Source download: kafka-2.2.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.2.2.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.2.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

2.2.1

• Released Jun 1, 2019
• Release Notes
• Source download: kafka-2.2.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.2.1.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.2.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

2.2.0

• Released Mar 22, 2019
• Release Notes
• Source download: kafka-2.2.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.2.0.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.2.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

Kafka 2.2.0 includes a number of significant new features. Here is a summary of some notable changes:

• Added SSL support for custom principal name
• Allow SASL connections to periodically re-authenticate
• Command line tool bin/kafka-topics.sh adds AdminClient support
• Improved consumer group management: default group.id is null instead of empty string
• API improvement:
  • Producer: introduce close(Duration)
  • AdminClient: introduce close(Duration)
  • Kafka Streams: new flatTransform() operator in Streams DSL
  • KafkaStreams (and other classed) now implement AutoClosable to support try-with-resource
  • New Serdes and default method implementations
• Kafka Streams exposed internal client.id via ThreadMetadata
• Metric improvements: All -min, -avg and -max metrics will now output NaN as default value

For more information, please read the detailed Release Notes.

2.1.1

• Released Feb 15, 2019
• Release Notes
• Source download: kafka-2.1.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.1.1.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.1.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

2.1.0

• Released Nov 20, 2018
• Release Notes
• Source download: kafka-2.1.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.1.0.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.1.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

Kafka 2.1.0 includes a number of significant new features. Here is a summary of some notable changes:

• Java 11 support
• Support for Zstandard, which achieves compression comparable to gzip with higher compression and especially decompression speeds (KIP-110)
• Avoid expiring committed offsets for active consumer group (KIP-211)
• Provide Intuitive User Timeouts in The Producer (KIP-91)
• Kafka’s replication protocol now supports improved fencing of zombies. Previously, under certain rare conditions, if a broker became partitioned from Zookeeper but not the rest of the cluster, then the logs of replicated partitions could diverge and cause data loss in the worst case (KIP-320).
• Streams API improvements (KIP-319, KIP-321, KIP-330, KIP-353, KIP-356)
• Admin script and admin client API improvements to simplify admin operation (KIP-231, KIP-308, KIP-322, KIP-324, KIP-338, KIP-340)
• DNS handling improvements (KIP-235, KIP-302)

For more information, please read the detailed Release Notes.

2.0.1

• Released November 9, 2018
• Release Notes
• Source download: kafka-2.0.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.0.1.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.0.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.12 is recommended).

2.0.0

• Released July 30, 2018
• Release Notes
• Source download: kafka-2.0.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-2.0.0.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-2.0.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

Kafka 2.0.0 includes a number of significant new features. Here is a summary of some notable changes:

• KIP-290 adds support for prefixed ACLs, simplifying access control management in large secure deployments. Bulk access to topics, consumer groups or transactional ids with a prefix can now be granted using a single rule. Access control for topic creation has also been improved to enable access to be granted to create specific topics or topics with a prefix.
• KIP-255 adds a framework for authenticating to Kafka brokers using OAuth2 bearer tokens. The SASL/OAUTHBEARER implementation is customizable using callbacks for token retrieval and validation.
• Host name verification is now enabled by default for SSL connections to ensure that the default SSL configuration is not susceptible to man-in-the-middle attacks. You can disable this verification if required.
• You can now dynamically update SSL truststores without broker restart. You can also configure security for broker listeners in ZooKeeper before starting brokers, including SSL keystore and truststore passwords and JAAS configuration for SASL. With this new feature, you can store sensitive password configs in encrypted form in ZooKeeper rather than in cleartext in the broker properties file.
• The replication protocol has been improved to avoid log divergence between leader and follower during fast leader failover. We have also improved resilience of brokers by reducing the memory footprint of message down-conversions. By using message chunking, both memory usage and memory reference time have been reduced to avoid OutOfMemory errors in brokers.
• Kafka clients are now notified of throttling before any throttling is applied when quotas are enabled. This enables clients to distinguish between network errors and large throttle times when quotas are exceeded.
• We have added a configuration option for Kafka consumer to avoid indefinite blocking in the consumer.
• We have dropped support for Java 7 and removed the previously deprecated Scala producer and consumer.
• Kafka Connect includes a number of improvements and features. KIP-298 enables you to control how errors in connectors, transformations and converters are handled by enabling automatic retries and controlling the number of errors that are tolerated before the connector is stopped. More contextual information can be included in the logs to help diagnose problems and problematic messages consumed by sink connectors can be sent to a dead letter queue rather than forcing the connector to stop.
• KIP-297 adds a new extension point to move secrets out of connector configurations and integrate with any external key management system. The placeholders in connector configurations are only resolved before sending the configuration to the connector, ensuring that secrets are stored and managed securely in your preferred key management system and not exposed over the REST APIs or in log files.
• We have added a thin Scala wrapper API for our Kafka Streams DSL, which provides better type inference and better type safety during compile time. Scala users can have less boilerplate in their code, notably regarding Serdes with new implicit Serdes.
• Message headers are now supported in the Kafka Streams Processor API, allowing users to add and manipulate headers read from the source topics and propagate them to the sink topics.
• Windowed aggregations performance in Kafka Streams has been largely improved (sometimes by an order of magnitude) thanks to the new single-key-fetch API.
• We have further improved unit testibility of Kafka Streams with the kafka-streams-testutil artifact.

For more information, please read the detailed Release Notes.

1.1.1

• Released July 19, 2018
• Release Notes
• Source download: kafka-1.1.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-1.1.1.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-1.1.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

1.1.0

• Released March 28, 2018
• Release Notes
• Source download: kafka-1.1.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-1.1.0.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-1.1.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

Kafka 1.1.0 includes a number of significant new features. Here is a summary of some notable changes:

• Kafka 1.1.0 includes significant improvements to the Kafka Controller that speed up controlled shutdown. ZooKeeper session expiration edge cases have also been fixed as part of this effort.
• Controller improvements also enable more partitions to be supported on a single cluster. KIP-227 introduced incremental fetch requests, providing more efficient replication when the number of partitions is large.
• KIP-113 added support for replica movement between log directories to enable data balancing with JBOD.
• Some of the broker configuration options like SSL keystores can now be updated dynamically without restarting the broker. See KIP-226 for details and the full list of dynamic configs.
• Delegation token based authentication (KIP-48) has been added to Kafka brokers to support large number of clients without overloading Kerberos KDCs or other authentication servers.
• Several new features have been added to Kafka Connect, including header support (KIP-145), SSL and Kafka cluster identifiers in the Connect REST interface (KIP-208 and KIP-238), validation of connector names (KIP-212) and support for topic regex in sink connectors (KIP-215). Additionally, the default maximum heap size for Connect workers was increased to 2GB.
• Several improvements have been added to the Kafka Streams API, including reducing repartition topic partitions footprint, customizable error handling for produce failures and enhanced resilience to broker unavailability. See KIPs 205, 210, 220, 224 and 239 for details.

For more information, please read the detailed Release Notes.

1.0.2

• Released July 8th, 2018
• Release Notes
• Source download: kafka-1.0.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-1.0.2.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-1.0.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

1.0.1

• Released March 5, 2018
• Release Notes
• Source download: kafka-1.0.1-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-1.0.1.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-1.0.1.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

1.0.0

• Released November 1, 2017
• Source download: kafka-1.0.0-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-1.0.0.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-1.0.0.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

Kafka 1.0.0 is no mere bump of the version number. The Apache Kafka Project Management Committee has packed a number of valuable enhancements into the release. Here is a summary of a few of them:

• Since its introduction in version 0.10, the Streams API has become hugely popular among Kafka users, including the likes of Pinterest, Rabobank, Zalando, and The New York Times. In 1.0, the the API continues to evolve at a healthy pace. To begin with, the builder API has been improved (KIP-120). A new API has been added to expose the state of active tasks at runtime (KIP-130). The new cogroup API makes it much easier to deal with partitioned aggregates with fewer StateStores and fewer moving parts in your code (KIP-150). Debuggability gets easier with enhancements to the print() and writeAsText() methods (KIP-160). And if that’s not enough, check out KIP-138 and KIP-161 too. For more on streams, check out the Apache Kafka Streams documentation, including some helpful new tutorial videos.
• Operating Kafka at scale requires that the system remain observable, and to make that easier, we’ve made a number of improvements to metrics. These are too many to summarize without becoming tedious, but Connect metrics have been significantly improved (KIP-196), a litany of new health check metrics are now exposed (KIP-188), and we now have a global topic and partition count (KIP-168). Check out KIP-164 and KIP-187 for even more.
• We now support Java 9, leading, among other things, to significantly faster TLS and CRC32C implementations. Over-the-wire encryption will be faster now, which will keep Kafka fast and compute costs low when encryption is enabled.
• In keeping with the security theme, KIP-152 cleans up the error handling on Simple Authentication Security Layer (SASL) authentication attempts. Previously, some authentication error conditions were indistinguishable from broker failures and were not logged in a clear way. This is cleaner now.
• Kafka can now tolerate disk failures better. Historically, JBOD storage configurations have not been recommended, but the architecture has nevertheless been tempting: after all, why not rely on Kafka’s own replication mechanism to protect against storage failure rather than using RAID? With KIP-112, Kafka now handles disk failure more gracefully. A single disk failure in a JBOD broker will not bring the entire broker down; rather, the broker will continue serving any log files that remain on functioning disks.
• Since release 0.11.0, the idempotent producer (which is the producer used in the presence of a transaction, which of course is the producer we use for exactly-once processing) required max.in.flight.requests.per.connection to be equal to one. As anyone who has written or tested a wire protocol can attest, this put an upper bound on throughput. Thanks to KAFKA-5949, this can now be as large as five, relaxing the throughput constraint quite a bit.

For more information, please read the detailed Release Notes.

0.11.0.3

• Released July 2ed, 2018
• Release Notes
• Source download: kafka-0.11.0.3-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-0.11.0.3.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-0.11.0.3.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.11.0.2

• Released November 17, 2017
• Release Notes
• Source download: kafka-0.11.0.2-src.tgz (asc, sha512)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-0.11.0.2.tgz (asc, sha512)
  • Scala 2.12 - kafka_2.12-0.11.0.2.tgz (asc, sha512) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.11.0.1

• Released September 13, 2017
• Release Notes
• Source download: kafka-0.11.0.1-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-0.11.0.1.tgz (asc, md5)
  • Scala 2.12 - kafka_2.12-0.11.0.1.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.11.0.0

• Released June 28, 2017
• Release Notes
• Source download: kafka-0.11.0.0-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.11 - kafka_2.11-0.11.0.0.tgz (asc, md5)
  • Scala 2.12 - kafka_2.12-0.11.0.0.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.10.2.2

• Released July 2nd, 2018
• Release Notes
• Source download: kafka-0.10.2.2-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.10 - kafka_2.10-0.10.2.2.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.10.2.2.tgz (asc, md5)
  • Scala 2.12 - kafka_2.12-0.10.2.2.tgz (asc, md5) We add 2.12 to the supported Scala version. These different versions only matter if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.10.2.1

• Released April 26, 2017
• Release Notes
• Source download: kafka-0.10.2.1-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.10 - kafka_2.10-0.10.2.1.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.10.2.1.tgz (asc, md5)
  • Scala 2.12 - kafka_2.12-0.10.2.1.tgz (asc, md5) We add 2.12 to the supported Scala version. These different versions only matter if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.10.2.0

• Released February 21, 2017
• Release Notes
• Source download: kafka-0.10.2.0-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.10 - kafka_2.10-0.10.2.0.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.10.2.0.tgz (asc, md5)
  • Scala 2.12 - kafka_2.12-0.10.2.0.tgz (asc, md5) We add 2.12 to the supported Scala version. These different versions only matter if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.10.1.1

• Released December 20, 2016
• Release Notes
• Source download: kafka-0.10.1.1-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.10 - kafka_2.10-0.10.1.1.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.10.1.1.tgz (asc, md5)
  • Scala 2.12 (pre-alpha) - kafka_2.12-0.10.1.1.tgz (asc, md5) We build for multiple versions of Scala, and include 2.12 as a pre-alpha before the next major release. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.10.1.0

• Released October 20, 2016
• Release Notes
• Source download: kafka-0.10.1.0-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.10 - kafka_2.10-0.10.1.0.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.10.1.0.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.10.0.1

• Released August 10, 2016
• Release Notes
• Source download: kafka-0.10.0.1-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.10 - kafka_2.10-0.10.0.1.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.10.0.1.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.10.0.0

• Released May 22, 2016
• Release Notes
• Source download: kafka-0.10.0.0-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.10 - kafka_2.10-0.10.0.0.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.10.0.0.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.9.0.1

• Released February 19, 2016
• Release Notes
• Source download: kafka-0.9.0.1-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.10 - kafka_2.10-0.9.0.1.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.9.0.1.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.9.0.0

• Released November 23, 2015
• Release Notes
• Source download: kafka-0.9.0.0-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.10 - kafka_2.10-0.9.0.0.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.9.0.0.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.11 is recommended).

0.8.2.2

• Released October 2, 2015
• Release Notes
• Source download: kafka-0.8.2.2-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.9.1 - kafka_2.9.1-0.8.2.2.tgz (asc, md5)
  • Scala 2.9.2 - kafka_2.9.2-0.8.2.2.tgz (asc, md5)
  • Scala 2.10 - kafka_2.10-0.8.2.2.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.8.2.2.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.10 is recommended).

0.8.2.1

• Released March 11, 2015
• Release Notes
• Source download: kafka-0.8.2.1-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.9.1 - kafka_2.9.1-0.8.2.1.tgz (asc, md5)
  • Scala 2.9.2 - kafka_2.9.2-0.8.2.1.tgz (asc, md5)
  • Scala 2.10 - kafka_2.10-0.8.2.1.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.8.2.1.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.10 is recommended).

0.8.2.0

• Released February 2, 2015
• Release Notes
• Source download: kafka-0.8.2.0-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.9.1 - kafka_2.9.1-0.8.2.0.tgz (asc, md5)
  • Scala 2.9.2 - kafka_2.9.2-0.8.2.0.tgz (asc, md5)
  • Scala 2.10 - kafka_2.10-0.8.2.0.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.8.2.0.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.10 is recommended).

0.8.2-beta

• Released October 28, 2014
• Release Notes
• Source download: kafka-0.8.2-beta-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.9.1 - kafka_2.9.1-0.8.2-beta.tgz (asc, md5)
  • Scala 2.9.2 - kafka_2.9.2-0.8.2-beta.tgz (asc, md5)
  • Scala 2.10 - kafka_2.10-0.8.2-beta.tgz (asc, md5)
  • Scala 2.11 - kafka_2.11-0.8.2-beta.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.10 is recommended).

0.8.1.1 Release

• Released April 29, 2014
• Release Notes
• Source download: kafka-0.8.1.1-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.8.0 - kafka_2.8.0-0.8.1.1.tgz (asc, md5)
  • Scala 2.9.1 - kafka_2.9.1-0.8.1.1.tgz (asc, md5)
  • Scala 2.9.2 - kafka_2.9.2-0.8.1.1.tgz (asc, md5)
  • Scala 2.10 - kafka_2.10-0.8.1.1.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.9.2 is recommended).

0.8.1 Release

• Released March 12, 2014
• Release Notes
• Source download: kafka-0.8.1-src.tgz (asc, md5)
• Binary downloads:
  • Scala 2.8.0 - kafka_2.8.0-0.8.1.tgz (asc, md5)
  • Scala 2.8.2 - kafka_2.8.2-0.8.1.tgz (asc, md5)
  • Scala 2.9.1 - kafka_2.9.1-0.8.1.tgz (asc, md5)
  • Scala 2.9.2 - kafka_2.9.2-0.8.1.tgz (asc, md5)
  • Scala 2.10 - kafka_2.10-0.8.1.tgz (asc, md5) We build for multiple versions of Scala. This only matters if you are using Scala and you want a version built for the same Scala version you use. Otherwise any version should work (2.9.2 is recommended).

0.8.0 Release

• Released December 3, 2013
• Release Notes
• Source download: kafka-0.8.0-src.tgz (asc, md5)
• Binary download: kafka_2.8.0-0.8.0.tar.gz (asc, md5)

0.8.0 Beta1 Release

• Released June 28, 2013
• Release Notes
• Source download: kafka-0.8.0-beta1-src.tgz (asc, md5)
• Binary download: kafka_2.8.0-0.8.0-beta1.tgz (asc, md5)

0.7.2 Release

• Released October 10, 2012
• Release Notes
• Download: kafka-0.7.2-incubating-src.tgz (asc, md5)

0.7.1 Release

• Released June 27, 2012
• Release Notes
• Download: kafka-0.7.1-incubating-src.tgz (asc, md5)

0.7.0 Release

• Released January 4, 2012
• Release Notes
• Download: kafka-0.7.0-incubating-src.tar.gz (asc, md5)

6 - Events

Meetups

Meetups focused on Kafka and the Kafka ecosystem are currently running virtually, online as well as live in the following locations:

North America

• Phoenix, AZ
• Fayetteville­, AR
• Little Rock, AR
• San Francisco Bay Area, CA
• East Bay, California
• Los Angeles, CA
• Mountain View, CA
• Orange, CA
• San Diego, CA
• San Francisco, CA
• Sunnyvale, CA
• Denver, CO
• Hartford, CT
• Stamford, CT
• Washington, DC
• Jacksonville, FL
• Miami, FL
• Orlando, FL
• Tampa, FL
• Atlanta, GA
• Boise, ID
• Chicago, IL
• Indianapolis, IN
• Fort Wayne, IN
• Des Moines, IA
• Kansas City, KS
• Louisville, KY
• New Orleans, LA
• Shreveport, LA
• Columbia, MD
• Boston, MA
• Detroit, MI
• Minneapolis, MN
• Saint Paul, MN
• Jackson, MS
• St. Louis, MO
• Bozeman, MT
• Lincoln, NE
• Omaha, NE
• Las Vegas, NV
• Albuquerque, NM
• Santa Fe, NM
• New York, NY
• Western New York, NY
• Charlotte, NC
• Raleigh, NC
• Cincinnati, OH
• Cleveland, OH
• Columbus, OH
• Oklahoma City, Oklahoma
• Portland, OR
• Philadelphia, PA
• Pittsburgh, PA
• Providence, RI
• Charleston, SC
• Sioux Falls, SD
• Memphis, TN
• Nashville, TN
• Austin, TX
• Dallas, TX
• El Paso, TX
• Houston, TX
• Lubbock, TX
• San Antonio, TX
• Salt Lake City, UT
• Salt Lake City, UT
• Richmond, VA
• Norfolk, VA
• Seattle, WA
• Madison, WI
• Milwaukee, WI
• Calgary, Canada
• Montréal, Canada
• Ottowa, Canada
• Quebec, Canada
• Toronto, Canada
• Vancouver, Canada
• Waterloo, Canada

Europe

• Graz, Austria
• Vienna, Austria
• Brussels, Belgium
• Zagreb, Croatia
• Prague, Czech Republic
• Copenhagen, Denmark
• Tallinn, Estonia
• Helsinki, Finland
• Bordeaux, France
• Lille, France
• Lyon, France
• Nice, France
• Paris, France
• Toulouse, France
• Berlin, Germany
• Dresden, Germany
• Dortmund, Germany
• Düsseldorf, Germany
• Frankfurt, Germany
• Hamburg, Germany
• Hannover, Germany
• Kiel, Germany
• Köln, Germany
• Leipzig/Halle, Saxony, Germany
• Munich, Germany
• Nürnberg, Germany
• Stuttgart, Germany
• Athens, Greece
• Dublin, Ireland
• Milan, Italy
• Rome, Italy
• Riga, Latvia
• Luxembourg, Luxembourg
• Oslo, Norway
• Gdansk, Poland
• Kraków, Poland
• Poznań, Poland
• Warsaw, Poland
• Lisbon, Portugal
• Porto, Portugal
• Napoca, Romania
• Moscow, Russia
• Samara, Russia
• St. Petersburg, Russia
• Bratislava, Slovakia
• Barcelona, Spain
• Granada, Spain
• Madrid, Spain
• Madrid, Spain
• Palma, Spain
• Valencia, Spain
• Göteborg, Sweden
• Stockholm, Sweden
• Bern, Switzerland
• Geneva, Switzerland
• Lausanne, Switzerland
• Lausanne, Switzerland
• Zürich, Switzerland
• Amsterdam, Netherlands
• Rotterdam, Netherlands
• Utrecht, Netherlands
• Istanbul, Turkey
• Belfast, UK
• Edinburgh, UK
• Glasgow, UK
• Leeds, UK
• London, UK
• Manchester, UK
• Reading, UK
• Swindon, UK

Asia Pacific

• Adelaide, Australia
• Brisbane, Australia
• Canberra, Australia
• Melbourne, Australia
• Perth, Australia
• Sydney, Australia
• Sylhet, Bangladesh
• Beijing, China
• Shenzhen, China
• Hong Kong, Hong Kong
• Bangalore, India
• Chennai, India
• Delhi, India
• Gujarat, India
• Hyderabad, India
• Jaipur, India
• Jalandhar, India
• Mumbai, India
• Pune, India
• Bali, Indonesia
• Jakarta, Indonesia
• Tokyo, Japan
• Kuala Lumpur, Malaysia
• Auckland, New Zealand
• Wellington, New Zealand
• Manila, Phillipines
• Singapore, Singapore
• Seoul, South Korea
• Colombo, Sri Lanka
• Taipei, Taiwan
• Bangkok, Thailand
• Ha Noi, Vietnam
• Ho Chi Minh City, Vietnam

Latin & South America

• Buenos Aires, Argentina
• La Paz, Bolivia
• Belo Horizonte, Brazil
• Brasilia, Brazil
• Rio De Janiero, Brazil
• São Paulo, Brazil
• Santiago, Chile
• Bogota, Colombia
• Medellin, Colombia
• San José, Costa Rica
• Guatemala, Guatemala
• Guadalajara, Mexico
• Mexico City, Mexico
• Panama City, Panama
• Lima District, Peru

Middle East / Africa

• Tel Aviv-Yafo, Israel
• Nairobi, Kenya
• Casablanca, Morocco
• Lagos, Nigeria
• Karachi, Pakistan
• Riyadh, Saudi Arabia
• Cape Town, South Africa
• Durban, South Africa
• Johannesburg, South Africa
• Abu Dhabi, United Arab Emirates
• Dubai, United Arab Emirates

Kafka Summit

Conference for anyone currently using or excited to learn about Kafka and real time data streaming.

View times & locations

7 - Podcasts

The following podcasts cover Apache Kafka and event streaming topics.

8 - Project Security

Kafka security

The Apache Software Foundation takes security issues very seriously. Apache Kafka® specifically offers security features and is responsive to issues around its features. If you have any concern around Kafka Security or believe you have uncovered a vulnerability, we suggest that you get in touch via the e-mail address security@kafka.apache.org. In the message, try to provide a description of the issue and ideally a way of reproducing it. The security team will get back to you after assessing the description.

Note that this security address should be used only for undisclosed vulnerabilities. Dealing with fixed issues or general questions on how to use the security features should be handled regularly via the user and the dev lists. Please report any security problems to the project security address before disclosing it publicly.

The ASF Security team maintains a page with a description of how vulnerabilities are handled, check their Web page for more information.

For a list of security issues fixed in released versions of Apache Kafka, see CVE list.

Advisories for dependencies

Many organizations use ‘security scanning’ tools to detect components for which advisories exist. While we generally encourage using such tools, since they are an important way users are notified of risks, our experience is that they produce a lot of false positives: when a dependency of Kafka contains a vulnerability, it is likely Kafka is using it in a way that is not affected. As such, we do not consider the fact that an advisory has been published for a Kafka dependency sensitive. Only when additional analysis suggests Kafka may be affected by the problem, we ask you to report this finding privately through security@kafka.apache.org.

When handling such warnings, you can:

• Check if our DependencyCheck suppressions contain any information on this advisory.
• See if there is any discussion on this advisory in the issue tracker
• Do your own analysis on whether this advisory affects Kafka.
  • If it seems it might, report this finding privately through security@kafka.apache.org.
  • If it seems not to, contribute a section to our DependencyCheck suppressions explaining why it is not affected.

9 - The Committers

Jun Rao

Committer, PMC member

Neha Narkhede

Committer, and PMC member

Joe Stein

Committer, and PMC member

Jay Kreps

Committer, and PMC member

Joel Koshy

Committer, and PMC member

Prashanth Menon

Committer, and PMC member

Jakob Homan

Apache Member, Committer, and PMC member

David Arthur

Committer, and PMC member

Sriram Subramanian

Committer

Guozhang Wang

Committer, and PMC member

Gwen Shapira

Committer, and PMC member

Sriharsha Chintalapani

Committer, and PMC member

Ewen Cheslack-Postava

Committer

Ismael Juma

Committer, and PMC member

Jason Gustafson

Committer, and PMC member

Jiangjie (Becket) Qin

Committer, and PMC member

Grant Henke

Committer

Rajini Sivaram

Committer, and PMC member

Damian Guy

Committer

Onur Karaman

Committer

Matthias J. Sax

Committer, and PMC member

Dong Lin

Committer, and PMC member

Colin P. McCabe

Committer, and PMC member

Manikumar Reddy

Committer, and PMC member

Vahid Hashemian

Committer, and PMC member

Bill Bejeck

Committer, and PMC member

Randall Hauch

Committer, and PMC member

Mickael Maison

Committer, and PMC member, and VP of Kafka

John Roesler

Committer, and PMC member

Konstantine Karantasis

Committer, and PMC member

Boyang Chen

Committer

Xi Hu

Committer

David Jacot

Committer, and PMC member

Chia-Ping Tsai

Committer, and PMC member

Anna Sophie Blee-Goldman

Committer, and PMC member

Tom Bentley

Committer, and PMC member

Bruno Cadonna

Committer, and PMC member

Luke Chen

Committer, and PMC member

José Armando García Sancio

Committer, and PMC member

Chris Egerton

Committer, and PMC member

Ziming Deng

Committer

Viktor Somogyi-Vass

Committer, and PMC member

Josep Prat

Committer, and PMC member

Satish Duggana

Committer, and PMC member

Ron Dagostino

Committer

Justine Olshan

Committer, and PMC member

Edoardo Comar

Committer

Walker Carlson

Committer

Stanislav Kozlovski

Committer

Divij Vaidya

Committer, and PMC member

Greg Harris

Committer

Lucas Bradstreet

Committer

Yash Mayya

Committer

Lucas Brutschy

Committer, and PMC member

Igor Soarez

Committer

Christo Lolov

Committer, and PMC member

Lianet Magrans

Committer, and PMC member

Kamal Chandraprakash

Committer, and PMC member

Jeff Kim

Committer

Andrew Schofield

Committer, and PMC member

TengYao Chi

Committer

Apoorv Mittal

Committer

Omnia Ibrahim

Committer

PoAn Yang

Committer

Kirk True

Committer

Sean Quah

Committer

Jiunn-Yang Huang

Committer

Sushant Mahajan

Committer

10 - Trademark

Kafka Trademark Disclaimer

The name of a 3rd party non-Java client or connector may include the Kafka trademark, as long as it doesn’t cause confusion with product names from Apache Kafka and it doesn’t imply that it’s endorsed by Apache. Third parties may not use the trademark MirrorMaker without written consent from Apache. All use of Kafka and other Apache trademarks must comply with Apache’s trademark guidelines.

Third parties who use the Kafka mark in this way must include following disclaimer:

KAFKA is a registered trademark of The Apache Software Foundation and
has been licensed for use by [3rd party name]. [3rd party name] has no
affiliation with and is not endorsed by The Apache Software Foundation.

Logos

• High resolution logo

11 - Videos

Best Kafka Summit Videos

The following talks, with video recordings and slides available, achieved the best ratings by the community at the Kafka Summit conferences from 2018 onwards. Thanks to all the speakers for their hard work!

Kafka Internals and Fundamentals

• Making Kafka Cloud Native, Jay Kreps (Confluent), KS EU 2021
• How ksqlDB works, Michael Drogalis (Confluent), KS EU 2021
• Understanding Kafka Produce and Fetch API Calls for High Throughput Applications, Jason Gustafson (Confluent), KS EU 2021
• A Kafkaesque Raft Protocol, Mik Kocikowski (Cloudflare), KS EU 2021
• Kafka ♥ Cloud (Keynote), Jay Kreps (Confluent), KS 2020
• Trade-offs in Distributed Systems Design: Is Kafka The Best?, Ben Stopford & Michael G. Noll (Confluent), KS 2020
• The Flux Capacitor of Kafka Streams and ksqlDB, Matthias J. Sax (Confluent), KS 2020
• Crossing the Streams: the New Streaming Foreign-Key Join Feature in Kafka Streams, John Roesler (Confluent), KS 2020
• Welcome to Kafka; We’re Glad You’re Here, Dave Klein (Centene), KS 2020
• Kafka’s New Architecture (Keynote), Gwen Shapira (Confluent), KS 2020
• Getting Started with Apache Kafka – a Contributor’s Journey, Israel Ekpo (Microsoft) & Matthias J. Sax (Confluent) & Nikolay Izhikov (Sberbank), KS 2020
• Kafka Needs no (Zoo)Keeper (abstract), Jason Gustafson & Colin McCabe (Confluent), SFO 2019
• Why Stop the World When you Can Change it? Design and Implementation of Incremental Cooperative Rebalancing (abstract), Konstantine Karantasis (Confluent), SFO 2019
• Kafka 102: Streams and Tables All the Way Down (abstract), Michael G. Noll (Confluent), SFO 2019
• What’s the time? …and why? (abstract), Matthias J. Sax (Confluent), SFO 2019
• Zen and the Art of Streaming Joins: The What, When and Why (abstract), Nick Dearden (Confluent), NYC 2019
• Exactly Once Semantics Revisited (abstract), Jason Gustafson (Confluent), NYC 2019
• Performance Analysis and Optimizations for Kafka Streams Applications (abstract), Guozhang Wang (Confluent), LON 2019
• Everything You Always Wanted to Know About Kafka’s Rebalance Protocol but Were Afraid to Ask (abstract), Matthias J. Sax (Confluent), LON 2019
• Reliable Message Delivery with Apache Kafka (abstract), Ying Zheng & Xiaobing Li (Uber), SFO 2018
• Hardening Kafka Replication (abstract), Jason Gustafson (Confluent), SFO 2018
• Don’t Repeat Yourself: Introducing Exactly-Once Semantics in Apache Kafka (abstract), Matthias J. Sax (Confluent), LON 2018

Applications and Use Cases

• Should You Read Kafka as a Stream or in Batch? Should You Even Care?, Ido Nadler (Nielsen) & Opher Dubrovsky (Nielsen)
• Scaling a Core Banking Engine Using Apache Kafka, Peter Dudbridge (Thought Machine), KS APAC 2021
• Scaling an Event-Driven Architecture with IBM and Confluent, Antony Amanse (IBM) & Anton McConville (IBM), KS EU 2021
• Development of Dynamic Pricing for Tours Using Real-time Data Feeds, Mourad Benabdelkerim (FREE NOW), KS EU 2021
• Building Event Streaming Applications with Pac-Man, Ricardo Ferreira (Confluent), KS 2020
• Apache Kafka, Tiered Storage and TensorFlow for Streaming Machine Learning without a Data Lake, Kai Waehner (Confluent), KS 2020
• KSQL-ops! Running ksqlDB in the Wild, Simon Aubury (ThoughtWorks), KS 2020
• Streaming Towards Our Quantum Future, David Elbert & Tyrel McQueen (Johns Hopkins University), KS 2020
• KafkaConsumer – Decoupling Consumption and Processing for Better Resource Utilization, Igor Buzatović (Inovativni trendovi d.o.o), KS 2020
• Can Kafka Handle a Lyft Ride?, Andrey Falko & Can Cecen (Lyft), KS 2020
• Flattening the Curve with Kafka, Rishi Tarar (Northrop Grumman Corp.), KS 2020
• Risk Management in Retail with Stream Processing, Daniel Jagielski (Virtuslab/Tesco), KS 2020
• 0-60: Tesla’s Streaming Data Platform (abstract), Jesse Yates (Tesla), SFO 2019
• Eventing Things - A Netflix Original! (abstract), Nitin Sharma (Netflix), SFO 2019
• Mission-Critical, Real-Time Fault-Detection for NASA’s Deep Space Network using Apache Kafka (abstract), Rishi Verma (NASA Jet Propulsion Laboratory), SFO 2019
• Using Kafka to Discover Events Hidden in your Database (abstract), Anna McDonald (SAS Institute), SFO 2019
• Building an Enterprise Eventing Framework (abstract), Bryan Zelle (Centene) & Neil Buesing (Object Partners, Inc), SFO 2019
• ksqlDB Performance Tuning for Fun and Profit (abstract), Nick Dearden (Confluent), SFO 2019
• Discovering Drugs with Kafka Streams (abstract), Ben Mabey & Scott Nielsen (Recursion Pharmaceutical), SFO 2019
• Being an Apache Kafka Developer Hero in the World of Cloud (abstract), Ricardo Ferreira (Confluent), SFO 2019
• Streaming Apps and Poison Pills: handle the unexpected with Kafka Streams (abstract), Loic Divad (Xebia France), SFO 2019
• Scaling for India’s Cricket Hungry Population (abstract), Bhavesh Raheja & Namit Mahuvakar (Hotstar), SFO 2019
• Leveraging Services in Stream Processor Apps at Ticketmaster (abstract), Derek Cline (Ticketmaster), SFO 2019
• Stream Processing with the Spring Framework (Like You’ve Never Seen It Before) (abstract), Josh Long (Pivotal), Tim Berglund (Confluent), NYC 2019
• How To Use Apache Kafka and Druid to Tame Your Router Data (abstract), Rachel Pedreschi (Imply Data), NYC 2019
• Kafka Connect and ksqlDB: Useful Tools in Migrating from a Legacy System to Kafka Streams (abstract), Alex Leung & Danica Fine (Bloomberg L.P.), NYC 2019
• Building Serverless Apps with Kafka (abstract), Dale Lane (IBM), LON 2019
• Introducing Events and Stream Processing into Nationwide Building Society (abstract), Robert Jackson & Pete Cracknell (Nationwide Building Society), LON 2019
• The Exciting Frontier of Custom ksqlDB Functions (abstract), Mitch Seymour (Mailchimp), LON 2019
• Using Location Data to Showcase Keys, Windows, and Joins in Kafka Streams DSL and ksqlDB (abstract), Neil Buesing (Object Partners, Inc), LON 2019
• ksqlDB in Practice (abstract), Almog Gavra (Confluent), LON 2019
• Industry-ready NLP Service Framework Based on Kafka (abstract), Bernhard Waltl & Georg Bonczek (BMW Group), LON 2019
• Data Streaming Ecosystem Management at Booking.com (abstract), Alex Mironov (Booking.com), SFO 2018
• Kafka in the Enterprise–A Two-Year Journey to Build a Data Streaming Platform from Scratch (abstract), Benny Lee & Christopher Arthur (Commonwealth Bank of Australia), SFO 2018
• Life is a Stream of Events (abstract), Bjørn Kvernstuen & Tommy Jocumsen (Norwegian Directorate for Work and Welfare), SFO 2018
• Kafka Multi-Tenancy–160 Billion Daily Messages on One Shared Cluster at LINE (abstract), Yuto Kawamura (LINE Corporation), SFO 2018
• Matching the Scale at Tinder with Kafka (abstract), Krunal Vora (Tinder), SFO 2018
• Building an Enterprise Streaming Platform at Capital One, Chris D’Agostino (Capital One), SFO 2018
• More Data, More Problems: Scaling Kafka-Mirroring Pipelines at LinkedIn (abstract), Celia Kung (LinkedIn), SFO 2018
• From Propeller to Jet: Upgrading Your Engines Mid-Flight (abstract), Christopher Morris (PagerDuty), SFO 2018
• A Visual Approach to Understanding Streaming SQL (abstract), Shant Hovespian (Arcadia Data), SFO 2018
• Digital Transformation in Healthcare with Kafka–Building a Low Latency Data Pipeline (abstract), Dmitry Milman & Ankur Kaneria (Express Scripts), SFO 2018
• Building Pinterest Real-Time Ads Platform Using Kafka Streams (abstract), Liquan Pei & Boyang Chen (Pinterest), SFO 2018
• Taking Stateful Stream Processing to the Next Level with Kafka and Flink (abstract), Stephan Ewen (Ververica), LON 2018
• Taming Billions of Metrics and Logs at Scale: Two Years with Kafka as a Central Data Hub for Monitoring at CERN (abstract), Luca Magnoni (CERN), LON 2018
• ksqlDB 201: A Deep Dive into Query Processing (abstract), Hojjat Jafarpour (Confluent), LON 2018
• The Evolution of Kafka at ING Bank (abstract), Timor Timuri & Richard Bras (ING), LON 2018

Architecture and Patterns

• Mistakes - I’ve Made a Few. Blunders in Event-driven Architecture, Simon Aubury (ThoughtWorks Australia), KS APAC 2021
• Better CQRS with ksqlDB, Anshuman Mukherjee (Airwallex), KS APAC 2021
• Sharing Data Among Microservices: How Change Data Capture with Kafka Connect Came to Our Rescue, Ali Nazemian (Brolly) & Milad Vahood (Brolly), KS APAC 2021
• Apache Kafka and the Data Mesh, Ben Stopford (Confluent) & Michael Noll (Confluent), KS EU 2021
• How to Build the Data Mesh Foundation: A Principled Approach, Zhamak Dehghani (ThoughtWorks), KS EU 2021
• Getting up to Speed with MirrorMaker 2, Mickael Maison (IBM) & Ryanne Dolan (Twitter), KS EU 2021
• Reacting to an Event-Driven World, Kate Stanley & Grace Jansen (IBM), KS 2020
• A Tale of Two Data Centers: Kafka Streams Resiliency, Anna McDonald (Confluent), KS 2020
• Kafka as your Data Lake – is it Feasible?, Guido Schmutz (Trivadis), KS 2020
• GDPR Compliance: Transparent Handing of Personally Identifiable Information in Event-Driven Systems, Masih Derkani (SolarWinds), KS 2020
• Synchronous Commands over Apache Kafka, Neil Buesing (Object Partners, Inc), KS 2020
• Hybrid Kafka, Taking Real-time Analytics to the Business, Cody Irwin (Google Cloud) & Josh Treichel (Confluent) & Jeff Ferguson (Confluent), KS 2020
• I Don’t Always Test My Streams, But When I Do, I Do it in Production, Viktor Gamov (Confluent), KS 2020
• Building Information Systems using Event Modeling, Bobby Calderwood (Evident Systems), KS 2020
• Building Event Driven Architectures with Kafka and Cloud Events (abstract), Dan Rosanova (Microsoft), SFO 2019
• Event Sourcing, Stream Processing, and Serverless, Ben Stopford (Confluent), SFO 2019
• Shattering The Monolith(s) (abstract), Martin Kess (Namely), SFO 2019
• Hard Truths About Streaming and Eventing (abstract), Dan Rosanova (Microsoft), NYC 2019
• Complex Event Flows in Distributed Systems (abstract), Bernd Ruecker (Camunda), NYC 2019
• Cost Effectively and Reliably Aggregating Billions of Messages Per Day Using Apache Kafka (abstract), Chunky Gupta & Osman Sarood (Mist Systems), NYC 2019
• Tracing for Kafka-Based Applications: Making Sense of Your Event-Driven Dataflows (abstract), Jorge Esteban Quilcate Otoya (SYSCO AS), NYC 2019
• From a Million to a Trillion Events Per Day: Stream Processing in Ludicrous Mode (abstract), Shrijeet Paliwal (Tesla) NYC 2019
• The Migration to Event-Driven Microservices (abstract), Adam Bellemare (Flipp), NYC 2019
• Talking Traffic: Data in the Driver’s Seat (abstract), Dominique Chanet (Klarrio), LON 2019
• Privacy Engineering for the World of Kafka (abstract), Alexander Cook (Privitar), LON 2019
• Riddles of Streaming - Code Puzzlers for Fun & Profit (abstract), Nick Dearden (Confluent), LON 2019
• Is Kafka a Database?, Martin Kleppmann (University of Cambridge), LON 2019
• Event-Driven Workflow: Monitoring and Orchestrating Your Microservices Landscape with Kafka and Zeebe (abstract), Mike Winters & Sebastian Menski (Camunda), LON 2019
• Handling GDPR with Apache Kafka: How to Comply Without Freaking Out? (abstract), David Jacot (Independent, formally Swisscom), LON 2019
• One Key to Rule them All (abstract), Richard Noble & Francesco Nobilia (Babylon Health), LON 2019
• How To Use Kafka and Druid to Tame Your Router Data (abstract), Rachel Pedreschi And Eric Graham (Imply Data), LON 2019
• Apache Kafka and Event-Oriented Architecture, Jay Kreps (Confluent), SFO 2018
• Bringing Streaming Data To The Masses: Lowering The “Cost Of Admission” For Your Streaming Data Platform (abstract), Bob Lehmann (Bayer), SFO 2018
• Breaking Down a SQL Monolith with Change Tracking, Kafka and KStreams/ksqlDB (abstract Wanny Morellato (SAP Concur), SFO 2018
• Kafka as an Eventing System to Replatform a Monolith into Microservices (abstract), Madhulika Tripathi (Intuit), SFO 2018
• Experimentation Using Event-based Systems, Martin Fowler & Toby Clemson (ThoughtWorks), LON 2018

Data Pipelines

• On Track with Apache Kafka: Building a Streaming ETL Solution with Rail Data, Robin Moffatt (Confluent), KS APAC 2021
• Apache Kafka and ksqlDB in Action: Let’s Build a Streaming Data Pipeline!, Robin Moffat (Confluent), KS 2020
• Change Data Capture Pipelines with Debezium and Kafka Streams, Gunnar Morling (Red Hat), KS 2020
• Bravo Six, Going Realtime. Transitioning Activision Data Pipeline to Streaming, Yaroslav Tkachenko (Activision), KS 2020
• How Kroger Embraced a “Schema First” Philosophy in Building Real-time Data Pipelines, Rob Hoeting, Rob Hammonds & Lauren McDonald (Kroger), SFO 2019
• Building Stream Processing Applications with Apache Kafka Using ksqlDB Robin Moffat (Confluent), SFO 2019
• Kafka Connect: Operational Lessons Learned from the Trenches (abstract), Elizabeth Bennett (Confluent), SFO 2019
• Solutions for bi-directional integration between Oracle RDBMS and Apache Kafka (abstract), Guido Schmutz (Trivadis), SFO 2019
• Streaming Ingestion of Logging Events at Airbnb (abstract), Hao Wang (Airbnb), NYC 2019
• No More Silos: Integrating Databases into Apache Kafka (abstract), Robin Moffatt (Confluent), NYC 2019
• Lessons Learned Building a Connector Using Kafka Connect (abstract), Katherine Stanley & Andrew Schofield (IBM UK), NYC 2019
• Building Scalable and Extendable Data Pipeline for Call of Duty Games (abstract), Yaroslav Tkachenko (Activision), NYC 2019
• From Zero to Hero with Kafka Connect (abstract), Robin Moffatt (Confluent), LON 2019
• Change Data Streaming Patterns For Microservices With Debezium (abstract), Gunnar Morling (Red Hat), LON 2019
• Beyond Messaging: Enterprise-Scale, Multi-Cloud Intelligent Routing (abstract), Anand Phatak (Adobe), SFO 2018
• You Must Construct Additional Pipelines: Pub-Sub on Kafka at Blizzard (abstract), Stephen Parente & Jeff Field (Blizzard), SFO 2018
• So You Want to Write a Connector? (abstract), Randall Hauch (Confluent), SFO 2018

Kafka Operations

• Mind the App: How to Monitor Your Kafka Streams Applications, Simon Aubury (ThoughtWorks), KS EU 2021
• Encrypting Kafka Messages at Rest to Secure Applications, Robert Barnes (HashiCorp), KS EU 2021
• Everything You Ever Needed to Know About Kafka on Kubernetes but Were Afraid to Ask, Jakob Scholz (Red Hat), KS EU 2021
• Fully-Managed, Multi-Tenant Kafka Clusters: Tips, Tricks, and Tools, Christopher Beard (Bloomberg), KS 2020
• Overcoming the Perils of Kafka Secret Sprawl, Tejal Adsul (Confluent), KS 2020
• Kafka Lag Monitoring For Human Beings, Elad Leev (AppsFlyer), KS 2020
• Sharing is Caring: Toward Creating Self-tuning Multi-tenant Kafka, Anna Povzner (Confluent), KS 2020
• Kafka on Kubernetes: Keeping It Simple, Nikki Thean (Etsy), SFO 2019
• Please Upgrade Apache Kafka. Now! Gwen Shapira (Confluent), SFO 2019
• Tackling Kafka, with a Small Team, Jaren Glover (Robinhood), SFO 2019
• Secure Kafka at scale in true multi-tenant environment (abstract), Vishnu Balusu & Ashok Kadambala (JP Morgan Chase), SFO 2019
• Running large scale Kafka upgrades at Yelp (abstract), Manpreet Singh (Yelp), SFO 2019
• Production Ready Kafka on Kubernetes (abstract), Devandra Tagare (Lyft), SFO 2019
• Kafka Cluster Federation at Uber (abstract), Yupeng Fui & Xiaoman Dong (Uber), SFO 2019
• Experiences Operating Apache Kafka® at Scale (abstract), Noa Resare (Apple), NYC 2019
• Kafka Pluggable Authorization for Enterprise Security (abstract), Anna Kepler (Viasat), NYC 2019
• Kafka on Kubernetes: Does it really have to be “The Hard Way”? (abstract), Viktor Gamov and Michael Ng (Confluent), NYC 2019
• Flexible Authentication Strategies with SASL/OAUTHBEARER (abstract), Michael Kaminski (The New York Times) & Ron Dagostino (State Street Corp), NYC 2019
• Bulletproof Apache Kafka with Fault Tree Analysis (abstract), Andrey Falko (Lyft), NYC 2019
• The Foundations of Multi-DC Kafka (abstract), Jakub Korab (Confluent), LON 2019
• Show Me Kafka Tools That Will Increase My Productivity (abstract), Stephane Maarek (DataCumulus)
• Running Kafka in Kubernetes: A Practical Guide (abstract), Katherine Stanley (IBM UK), LON 2019
• Running Production Kafka Clusters in Kubernetes (abstract), Balthazar Rouberol (Datadog), LON 2019
• Don’t Be Scared: Multi-Tenant Cluster Support at Scale (abstract), Kelly Attaway & Cabe Waldrop (Pandora Media), LON 2019
• Kafka on ZFS: Better Living Through Filesystems (abstract), Hugh O’Brien (Jet.com), SFO 2018
• Kafka Security 101 and Real-World Tips (abstract), Stephane Maarek (DataCumulus), SFO 2018
• End-to-End Security with Confluent Platform (abstract), Vahid Fereydouny (Confluent), SFO 2018
• Robust Operations of Kafka Streams (abstract), Bill Bejeck (Confluent), SFO 2018
• Deploying Kafka Streams Applications with Docker and Kubernetes (abstract), Gwen Shapira & Matthias J. Sax (Confluent), SFO 2018
• URP? Excuse You! The Three Metrics You Have to Know (abstract), Todd Palino (LinkedIn), SFO 2018
• Monitor Kafka Like a Pro (abstract), Gwen Shapira & Xavier Leaute (Confluent), LON 2018