While xerial/snappy-java seems to be maintained, lz4-java is indeed a problem.
On Tue, 29 Sept 2026 at 11:16, Luke Chen <[email protected]> wrote: > > Hi, > > We've seen the snappy-java CVEs > > - CVE-2026-93452 (snappy issue > <https://github.com/xerial/snappy-java/issues/732>) > - CVE-2026-90559 (snappy issue > <https://github.com/xerial/snappy-java/issues/728>) > > Unfortunately, the snappy-java community seems to be not maintained > anymore. So we can't just bump the version to resolve them. I have an > investigation (collaborate with AI), I think Kafka is not affected by these > 2 CVEs, but not 100% sure about it. (I've also asked in the snappy-java > community, but no response). If anyone is available, please help review and > confirm my findings. > > > Moreover, the official lz4-jave community <https://github.com/lz4/lz4-java> > is not maintained, either. Currently, we depend on the third-party forked > repo <https://github.com/yawkat/lz4-java> created by a user (yawkat). The > single user repository presents a long-term sustainability risk if that > repository goes unmaintained as well. > > I think we need to decide how the community should manage unmaintained > legacy compression libraries and move forward. We cannot just find other > compression methods and replace them because that means the historical log > in kafka will not be decompressed anymore. I've created the KAFKA-21178 > <https://issues.apache.org/jira/browse/KAFKA-21178> for further discussion. > Any thoughts or suggestions are appreciated. > > Thank you, > Luke
