Skip to content

[GHSA-x5m7-63c6-fx79] Cluster Monitoring Operator contains a credentials leak #5467

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

rexagod
Copy link

@rexagod rexagod commented Apr 16, 2025

Updates

  • Affected products

Comments
👋 Hello, I'm one of the engineers who work on this downstream. I want to mention a couple of points that invalidate this CVE,

(a) CMO is not meant to be used as a module, but rather as an operator within OCP (for e.g., 1, as referenced in the advisory, does not serve any purpose, since we follow OCP versioning for CMO), and
(b) this was fixed in 2, in addition to a back-port (3) for clusters running the affected version.

As such, we are certain that this is a false alarm, and we'd be happy to engage in any follow-ups that could help close this out.

Thank you!

@Copilot Copilot AI review requested due to automatic review settings April 16, 2025 13:23
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Copilot wasn't able to review any files in this pull request.

@JonathanLEvans
Copy link

Hi @rexagod, while I can update the GitHub advisory, I am unable to invalidate the CVE record because GitHub was not the one to assign the CVE ID. If you want the CVE invalidated, you need to contact Red Hat (the assigning CNA) via email at [email protected].

Before I address your comments, when I was reviewing the advisory, I noticed that Red Hat says the issue was introduce in OCP 4.12 with openshift/cluster-monitoring-operator#1747. If that is the case, then none of the versions in the Go registry are affected and I can withdraw advisory on that basis. Is this correct?

(a) While it might not have been meant to be used as a module, the Go registry has it as a module and someone might be using it that way. This advisory is to alert anyone using the module from the Go registry that they are affected. Also, GitHub Security Advisories use the versions in the supported registry regardless of what versions are used elsewhere because that is what Dependabot is looking for.

(b) Thank you for the updates. If I don't withdraw the advisory, I will update the advisory accordingly.

@rexagod
Copy link
Author

rexagod commented Apr 17, 2025

Hello, @JonathanLEvans.

If that is the case, then none of the versions in the Go registry are affected and I can withdraw advisory on that basis. Is this correct?

I can confirm that is correct (the latest version on the registry is a 2018 release, whereas this was introduced in 2022).

@JonathanLEvans
Copy link

Hi @rexagod, the advisory has been withdrawn.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants