Database/Container, Kubernetes & orchestration

JFrog Artifactory Helm chart: generated TLS private keys retained in rendered manifests

CVE-2026-66016Container, Kubernetes & orchestrationcurated

Impact

Under specific self-hosted Helm configurations, TLS private keys generated during install are left behind in the rendered manifests, where highly privileged local users can read them. Artifactory is commonly the image and artifact registry a GPU fleet pulls container images and model artifacts from, so a leaked serving key undermines the trust in that endpoint - anyone holding it can present a valid certificate for the registry to nodes that pull from it. The advisory is thin: it names neither the exact chart values that trigger retention nor a fixed chart version, and access is limited to already-privileged local users.

Who can reach it

A local user with high privileges on the host or cluster context where the Helm release was rendered and stored. No network access to Artifactory itself is required.

What to do

JFrog publishes the fix through its self-managed release and security advisory pages; the record does not name a fixed chart or Artifactory version, so check those pages for the version applicable to your deployment before planning the change. Independently of the upgrade, treat the generated TLS keys as exposed: regenerate them, replace the TLS secret and roll the Artifactory pods so the new certificate is served. Restrict who can read rendered Helm manifests and release state in that namespace.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-66016 https://docs.jfrog.com/releases/docs/jfrog-security-advisories https://docs.jfrog.com/releases/docs/artifactory-self-managed-releases

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.