Skip to content

Conversation

@erikanderson
Copy link

@erikanderson erikanderson commented Dec 2, 2025

Updated lz4 dependency version from 1.8.0 to 1.8.1. For https://nvd.nist.gov/vuln/detail/CVE-2025-12183
@github-actions github-actions bot added triage PRs from the community build Gradle build or GitHub Actions small Small PRs labels Dec 2, 2025
@DL1231
Copy link
Collaborator

DL1231 commented Dec 2, 2025

Thanks for the patch. Could you also update LICENSE-binary and ensure the compression levels in org.apache.kafka.common.record.CompressionType are still valid?

@chia7712 chia7712 changed the title Update lz4 dependency version for CVE-2025-12183 MINOR: Update lz4 dependency version for CVE-2025-12183 Dec 2, 2025
@github-actions github-actions bot added the dependencies Pull requests that update a dependency file label Dec 2, 2025
@erikanderson
Copy link
Author

@DL1231 thank you, updated license binary, do you know how org.apache.kafka.common.record.CompressionType has been confirmed in the past?

@mimaison mimaison changed the title MINOR: Update lz4 dependency version for CVE-2025-12183 KAFKA-19951: Update lz4 dependency version for CVE-2025-12183 Dec 2, 2025
@mimaison
Copy link
Member

mimaison commented Dec 2, 2025

I linked the PR to KAFKA-19951.

Regarding the compression level, it's explained in CompressionType: https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/record/CompressionType.java#L73-L74

@mimaison
Copy link
Member

mimaison commented Dec 2, 2025

Also there's still a build issue:

Could not determine the dependencies of task ':clients:shadowJar'.
> Could not resolve all dependencies for configuration ':clients:runtimeClasspath'.
   > Could not resolve org.lz4:lz4-java:1.8.1.
     Required by:
         project ':clients'
      > Module 'org.lz4:lz4-java' has been rejected:
           Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by ['at.yawk.lz4:lz4-java:1.8.1' (runtimeElements)]
   > Could not resolve at.yawk.lz4:lz4-java:1.8.1.
     Required by:
         project ':clients' > org.lz4:lz4-java:1.8.1
      > Module 'at.yawk.lz4:lz4-java' has been rejected:
           Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by ['org.lz4:lz4-java:1.8.1' (runtime)]

@erikanderson
Copy link
Author

Also there's still a build issue:

Could not determine the dependencies of task ':clients:shadowJar'.
> Could not resolve all dependencies for configuration ':clients:runtimeClasspath'.
   > Could not resolve org.lz4:lz4-java:1.8.1.
     Required by:
         project ':clients'
      > Module 'org.lz4:lz4-java' has been rejected:
           Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by ['at.yawk.lz4:lz4-java:1.8.1' (runtimeElements)]
   > Could not resolve at.yawk.lz4:lz4-java:1.8.1.
     Required by:
         project ':clients' > org.lz4:lz4-java:1.8.1
      > Module 'at.yawk.lz4:lz4-java' has been rejected:
           Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by ['org.lz4:lz4-java:1.8.1' (runtime)]

It looks like there was a recent change to discontinue https://github.com/lz4/lz4-java, in favor of community fork https://github.com/yawkat/lz4-java . I'll try updating to new GAV

@yawkat
Copy link

yawkat commented Dec 2, 2025

Maintainer here. Interesting, did you see that error when depending on org.lz4:lz4-java:1.8.1 directly, without any reference to at.yawk.lz4? Maybe there's something wrong with the gradle capability metadata

@erikanderson
Copy link
Author

Maintainer here. Interesting, did you see that error when depending on org.lz4:lz4-java:1.8.1 directly, without any reference to at.yawk.lz4? Maybe there's something wrong with the gradle capability metadata

Yeah, had to switch to your gav for it to work (I'm just a random person not affil with apache): 51c520e

@github-actions github-actions bot removed the triage PRs from the community label Dec 3, 2025
@mjschwaiger
Copy link

'org.lz4:lz4-java:1.8.1

Simple example demonstrating the issue mentioned by @mimaison:

plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    // (1) only -> success
    // (2) only -> error, but: capability conflict not expected
    // (3) only -> success
    // (1) + (2) -> error (expected?)
    // (1) + (3) -> error (capability conflict as expected)
    // (2) + (3) -> error (capability conflict as expected)

    // implementation 'org.lz4:lz4-java:1.8.0' // (1)
    implementation 'org.lz4:lz4-java:1.8.1' // (2)
    // implementation 'at.yawk.lz4:lz4-java:1.8.1' // (3)
}

If only org.lz4:lz4-java:1.8.1 (2) is used, this unexpected build error will occur:

Could not determine the dependencies of task ':testlz4:compileJava'.
> Could not resolve all dependencies for configuration ':testlz4:compileClasspath'.
   > Could not resolve org.lz4:lz4-java:1.8.1.
     Required by:
         project :testlz4
      > Module 'org.lz4:lz4-java' has been rejected:
           Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by [at.yawk.lz4:lz4-java:1.8.1(apiElements)]
   > Could not resolve at.yawk.lz4:lz4-java:1.8.1.
     Required by:
         project :testlz4 > org.lz4:lz4-java:1.8.1
      > Module 'at.yawk.lz4:lz4-java' has been rejected:
           Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by [org.lz4:lz4-java:1.8.1(compile)]

There might be an issue with the capability configuration together with the relocation settings, which could be the reason for the problem.

@yawkat
Copy link

yawkat commented Dec 3, 2025

@mjschwaiger I made a test case here: https://github.com/yawkat/test-case-gradle-rename-capability

I think it's a gradle bug, I've asked on the gradle community slack about it.

Copy link
Member

@chia7712 chia7712 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@chia7712
Copy link
Member

chia7712 commented Dec 4, 2025

@mimaison do you have time to take a look at this?

@ccudennec-otto
Copy link

BTW: If the Java project is discontinued, I think it would be a good idea to get rid of the library. Not sure where I could raise this question as an issue.

@chia7712
Copy link
Member

chia7712 commented Dec 4, 2025

Not sure where I could raise this question as an issue.

I recommend KAFKA-17301 for raising this issue 😄

lz4: "1.8.0",
// https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/record/CompressionType.java#L73-L74
// https://github.com/yawkat/lz4-java/blob/main/src/java/net/jpountz/lz4/LZ4Constants.java#L23-L24
lz4: "1.8.1",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we directly bump to 1.10.0?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done (cd8be9e)

@mimaison
Copy link
Member

mimaison commented Dec 4, 2025

BTW: If the Java project is discontinued, I think it would be a good idea to get rid of the library. Not sure where I could raise this question as an issue.

org.lz4:lz4-java is not maintained but at.yawk.lz4:lz4-java is a new fork that is maintained.

Copy link
Collaborator

@DL1231 DL1231 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for the patch.

@marcosflobo
Copy link

Really looking forward to this team!. We have many services using this library and the "CVE alerts" already raised.

Thanks for the great job!

@chia7712
Copy link
Member

chia7712 commented Dec 5, 2025

@erikanderson sorry for intervening on your PR, but we have two planned releases waiting for this patch 😃

Copy link
Member

@FrankYang0529 FrankYang0529 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for the patch.

@yawkat
Copy link

yawkat commented Dec 5, 2025

I recommend you wait a few hours before merging this. Another (smaller, unrelated) CVE was found in lz4-java.

@ccudennec-otto
Copy link

If someone else runs into this coming from Spring Boot / Spring Kafka + Gradle.
I had to update doing this because Gradle gave me this warning: Cannot select module with conflict on capability 'org.lz4:lz4-java:1.8.1' also provided by ['org.lz4:lz4-java:1.8.1' (compile)]

    implementation 'org.lz4:lz4-java:1.8.1' // Fixes CVE-2025-12183
    modules {
        module("org.lz4:lz4-java") {
            replacedBy("at.yawk.lz4:lz4-java", "Fork of the original unmaintained lz4-java library that fixes a CVE")
        }
    }

@yawkat
Copy link

yawkat commented Dec 5, 2025

@ccudennec-otto please see this page: https://github.com/yawkat/lz4-java/wiki/Gradle-and-org.lz4:lz4%E2%80%90java:1.8.1

@apokralipsa
Copy link

apokralipsa commented Dec 5, 2025

The readme of the new repository and the old repository contains a message saying that this has been forked to fix a specific CVE. At the same time - the link to that CVE seems quite fishy (it's a page that kinda looks like the Sonatype page, but is hosted on sites.google.com). Are we really sure that this fork is authorized by the original authors?

Supply chain attacks like sha1-hulud are happening quite often right now.

Just asking.

@yawkat
Copy link

yawkat commented Dec 5, 2025

@apokralipsa That's only prudent. You can see that the CVE was published by sonatype if you look at the CVE feed: https://www.cvedetails.com/vulnerability-list/assigner-366/Sonatype.html

There is also a comment describing the move in the relocation pom: https://repo.maven.apache.org/maven2/org/lz4/lz4-java/1.8.1/lz4-java-1.8.1.pom

If I was malicious and had access to publish org.lz4 to maven central, I wouldn't need to move the group id in the first place, I could just continue with the old namespace. Because I do not have permission to publish org.lz4, I had to secure support from sonatype and the lz4 project to do the move.

@potorowski
Copy link

@yawkat @apokralipsa doesn't say this CVE isn't real. He has (IMO valid) concerns about the url you provided (https://sites.google.com/sonatype.com/vulnerabilities/cve-2025-12183) instead of the valid one (like this: https://www.cve.org/CVERecord?id=CVE-2025-12183).

@yawkat
Copy link

yawkat commented Dec 5, 2025

Yes, I understand that, and I find it prudent that you pay attention to this. This vulnerability and fix is definitely suspicious due to the project governance changes, compared to e.g. the xz backdoor. However https://sites.google.com/sonatype.com/vulnerabilities/cve-2025-12183 is a real Sonatype site, and you can see the CVE metadata is published by Sonatype in the CVE feed. I'm just providing evidence that I am honest :)

@yawkat
Copy link

yawkat commented Dec 5, 2025

CVE-2025-66566 has been published and fixed in 1.10.1. I suggest you move to that version. Though cloudflare seems to be having some trouble that breaks maven central at the moment.

@erikanderson erikanderson changed the title KAFKA-19951: Update lz4 dependency version for CVE-2025-12183 KAFKA-19951: Update lz4 dependency version for CVE-2025-12183 & CVE-2025-66566 Dec 5, 2025
@erikanderson
Copy link
Author

CVE-2025-66566 has been published and fixed in 1.10.1. I suggest you move to that version. Though cloudflare seems to be having some trouble that breaks maven central at the moment.

@yawkat I'm not sure that is the right CVE, that one is for oat++ https://nvd.nist.gov/vuln/detail/CVE-2025-6566 . Can you link to the right CVE?

@yawkat
Copy link

yawkat commented Dec 5, 2025

66566, not 6566. It's not on nvd yet i guess

@erikanderson
Copy link
Author

erikanderson commented Dec 5, 2025

My mistake, misread the number, and when I did search for the new value it gave me the oat one.

Looks like second CVE has been published: https://nvd.nist.gov/vuln/detail/CVE-2025-66566

@apokralipsa
Copy link

In the mean time I have contacted Sonatype over email and they have confirmed that they are aware of the relocation and they have been in touch with the previous owners of lz4-java.

@ccudennec-otto
Copy link

@yawkat : Does Sonatype also need to configure relocation for 1.10.1?

I still get this error when trying to update my local (Maven) project:

Could not find artifact org.lz4:lz4-java:pom:v1.10.1 in central (https://repo1.maven.org/maven2)

In my Gradle projects I can still use the replacedBy approach described above - but this time I need to declare the dependency to at.yawk.lz4:lz4-java:1.10.1 myself.

So either Sonatype needs to support relocation or everyone needs to replace the dependency, I suppose?

(Thanks for your great work so far, by the way! 🌻 🚀 )

@yawkat
Copy link

yawkat commented Dec 8, 2025

There will be no relocation for versions past 1.8.1

@chia7712
Copy link
Member

chia7712 commented Dec 8, 2025

Dear all, is it good to go for merging? it would be cool to have your approval 😄

@mimaison
Copy link
Member

mimaison commented Dec 8, 2025

There's still a mention of https://github.com/jpountz/lz4-java in NOTICE-binary: https://github.com/apache/kafka/blob/trunk/NOTICE-binary#L690

Copy link
Member

@mimaison mimaison left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build Gradle build or GitHub Actions ci-approved dependencies Pull requests that update a dependency file small Small PRs

Projects

None yet

Development

Successfully merging this pull request may close these issues.