CVE-2026-71845 is a medium severity (CVSS 6.3) flaw in Red Hat insights-client, used in Advanced Cluster Management for Kubernetes. Its setDefault() function logs every environment variable it processes, including the CCX_TOKEN bearer credential. At glog verbosity 2 or higher, the token reaches the pod log in clear text. Apply the Red Hat errata and rotate the token.
What's affected
Red Hat insights-client as shipped with Red Hat Advanced Cluster Management for Kubernetes, according to the record. The record references several Red Hat errata, RHSA-2026:60386 through 60391, but the pages I fetched list many CVEs and I could not confirm which erratum fixes this one for your version. Check the Red Hat CVE page for your ACM release.
The weakness is CWE-532, insertion of sensitive information into a log file. The token is written to the pod log on every startup when glog verbosity is at level 2 or higher. CCX_TOKEN is a bearer credential used in disconnected cluster deployments, and anyone who can read pod logs or the central logging system can obtain it and use it against the CCX API.
The vector is AV:N/AC:H/PR:L/UI:N/S:C with high confidentiality impact and none for integrity and availability.
How to check if you're exposed
First check the log level. Look at how insights-client is started in your cluster, and whether the glog verbosity flag is set to 2 or higher. The default level may not write the token, but any debugging change that raised verbosity would.
Then search your logs for the token being present. If your central logging system keeps old pod logs, search it for the variable name CCX_TOKEN near insights-client startup lines. Treat every match as exposure of the credential itself, and note who has read access to those logs.
oc logs deployment/<insights-client-deployment> | grep -c CCX_TOKEN
Adjust the deployment name and namespace for your cluster. Do not paste log contents into tickets. free in-browser dependency scan checks application dependencies and does not look at runtime logs.
What to do now
- Check the Red Hat CVE page and errata for your ACM version and apply the fixed insights-client.
- Confirm the glog verbosity of insights-client and keep it below 2 until patched.
- Search pod logs and central logging for CCX_TOKEN and note who can read them.
- Rotate the CCX_TOKEN credential, since a token that has been logged should be treated as exposed.
- Shorten retention for old pod logs that may contain the token, where your policy allows.
Why it matters
CWE-532 is one of the most common ways secrets leak, and the cause is almost always a helpful debug statement that logs everything it handles. Logs travel: they are copied to central systems, retained for months, and readable by many more people than the original secret ever was.
Patching stops new writes. It does not remove the token from logs that already exist, which is why rotation is part of the fix. A bearer token works for whoever holds it.
Quick check
Is patching enough?
No. Patching stops the token being written, but copies already in pod logs and central logging remain. Rotate the CCX_TOKEN and review access to those logs.
Sources
Last reviewed: 18 October 2026.
