Strimzi
Replies: 5 comments 7 replies
-
|
We did the CVE re-spin on Tuesday. So please make sure you use the latest images. If you still have any CVE questions, please make sure to share the CVEs you want to ask about with a clear information about:
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the quick response! We’ll re-run our scans against the latest images that were re-spun. If any CVEs are still flagged, we’ll follow up with:
At the moment, the flagged CVEs were found in:
We’ll verify against the updated images and report back with specifics if the issues persist. Thanks again for clarifying the process! |
Beta Was this translation helpful? Give feedback.
-
|
TBH, there will be always CVEs. You should not expect there to be zero CVEs and it is not something we aim for. But we are always happy to discuss and see what can be done about the more important or critical ones. |
Beta Was this translation helpful? Give feedback.
-
|
I understand that there will always be CVEs and that achieving zero CVEs is not the goal. My question was more about whether there are plans to update the base components, as it seems that the CVEs we observed are not associated with the Strimzi operator itself but with the underlying Linux and Java versions used to build the images making them sort of false positives. From our analysis, most of these issues could be resolved with an update of OpenJDK and the RHEL base image. I assumed that these updates would be included when operator 0.49 is released, which will support Kafka image 4.1.0. Of course, I will provide the requested data for the images and CVEs so that you have clear visibility on which ones we are referring to. I appreciate any guidance on whether these updates are planned in the near term. Here are the details you requested for the CVEs still being flagged as HIGH/CRITICAL on our side for the operator as we can somehow deal with other packages. CVE-2025-5914 (libarchive)
CVE-2025-6965 (sqlite-libs)
CVE-2025-7425 (libxml2)
CVE-2025-8194 (python3)
CVE-2025-30749, CVE-2025-50059, CVE-2025-50106 (OpenJDK)
CVE-2025-32988, CVE-2025-32990 (gnutls)
|
Beta Was this translation helpful? Give feedback.
-
|
So, as I said, we did a CVE respin on Tuesday. So if these are still in the latest images, that means the fixes were not available in the base image nor in the RPM repositories and we could not address them. The next release - 0.48.0 - will likely GA next week. That was build yesterday, so it might have some additional fixes if they were made available in the meantime. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the clarification! I understand that if the fixes aren’t in the base image or RPM repos yet, they can’t be picked up by Strimzi directly. I’ll re-check the latest respun images and test 0.48.0 once it’s out. |
Beta Was this translation helpful? Give feedback.
-
|
@smazsta the 0.48.0 RC1 is out for testing and you could already get an idea of which CVEs are fixed or present on the images https://github.com/strimzi/strimzi-kafka-operator/releases/tag/0.48.0-rc1 . Of course, between now and the GA base images could change again and the rebuild will take new fixes (or new CVEs). |
Beta Was this translation helpful? Give feedback.
-
|
Is there an easy way to determine when the latest CVE re-spin was performed? We are in a similar position where the containers hosted on Quay.io are reporting several High vulns which all appear to be fixed in their latest respective packages. Cheers. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe from some metadata of the images? You should start by sharing what images are you talking about, what CVEs, in what exact path etc., and we can have a look if a CVE re-spin might help or not. |
Beta Was this translation helpful? Give feedback.
-
|
But just to be clear, we can do a respin for 0.48 if needed. I do not think we have any plans for any CVE respins for 0.47. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, that's my bad; sincere apologies for the poor form/etiquette. I'm looking at the strimzi/kafka container images ( https://quay.io/repository/strimzi/kafka ) for the latest-kafka-4.1.0 tag > amd64 manifest: cheers |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, but as I said, you have to share the actual path where the CVE is. Without that, there is not much I can tell. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello Strimzi team,
We are in the process of upgrading from Strimzi Operator 0.45 to 0.47, but the rollout had to be paused due to several HIGH and CRITICAL CVEs flagged by our security scanning tools.
From our assessment, most of these vulnerabilities appear to stem from the RHEL UBI base image and the JDK 17 version used to build the operator and related Strimzi images. While these CVEs do not seem to directly impact the operator’s security model, they can be resolved by updating to newer, patched versions of RHEL UBI and JDK during image builds.
I would like to ask if there is a plan to update the RHEL UBI base image and JDK version used in the Strimzi operator image? Will related images such as kaniko-executor and kafka-bridge also be updated to address these CVEs?
For reference, these are the CVEs detected in our scans:
Any guidance on whether a patch release or future version will address these would be greatly appreciated.
Thank you for your work on Strimzi!
Beta Was this translation helpful? Give feedback.
All reactions