JFrog Artifactory CVE-2026-66016

Three specific concurrent conditions must be present: Artifactory must be self-hosted rather than on JFrog Cloud; it must be deployed via Helm under one of the specific configurations that triggers TLS private key retention in rendered manifests (JFrog has not publicly disclosed which configuration parameters are triggering - the description's phrase 'specific self-hosted Helm configurations' confirms this is not universal); and the attacker must hold highly privileged local access to the Kubernetes cluster sufficient to read Helm release secrets or the rendered manifest files, as reflected by PR:H in the CVSS vector. The AV:L metric confirms that network-only access is insufficient. The non-universal configuration trigger further limits the vulnerable population within the already-narrow self-hosted Helm deployment base. Exploitation is bounded by: the requirement for high-privilege cluster credentials; the self-hosted deployment constraint; and the configuration-dependent trigger condition that not all Helm deployments exhibit.

The CVSS 6.7 score with vector AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H reflects a locally-exploitable flaw that requires high privilege, which materially constrains real-world risk - the threat model is an insider, a compromised admin credential, or a misconfigured Kubernetes RBAC policy, not an external attacker. There is no CISA KEV listing and no known public exploit code, and no EPSS data was provided in the available intelligence. Despite these limiting factors, even a mid-sized municipal IT team in tczew operating a self-hosted Artifactory instance should treat this as urgent key rotation work, because exposure of a TLS private key enables impersonation and decryption attacks against every client trusting that certificate, extending the blast radius well beyond the privileged user who initially accessed the manifest. The A:H component of the vendor-supplied CVSS vector is not independently supported by the description - no mechanism by which key disclosure alone causes an availability impact is apparent, suggesting that metric may be overstated.

A Kubernetes cluster administrator with routine access to Helm release state inspects the stored release secret for the Artifactory deployment during troubleshooting and discovers that the rendered manifest contains a plaintext TLS private key. Using this key alongside the corresponding certificate - obtainable from the running Artifactory service - the administrator or a threat actor who has subsequently compromised their credentials configures a rogue endpoint presenting the same certificate, enabling man-in-the-middle interception of artifact pull and push traffic from clients that trust the Artifactory TLS identity. No exploit code beyond standard Kubernetes CLI tooling is required.