GPU VulnDB

Database/Container, Kubernetes & orchestration

JFrog Artifactory: unauthenticated network attacker can obtain administrative privileges

CVE-2026-82329Container, Kubernetes & orchestrationKnown exploitedcurated

Impact

Under the default configuration, an attacker with network access and no credentials may gain administrative privileges on Artifactory. For a GPU fleet Artifactory is usually the single source of every container image, CUDA and pip/conda package, and model artifact that lands on the nodes, so registry admin means being able to push or replace the images nodes pull on their next scheduling event - a fleet-wide supply-chain compromise that rebooting a node does not undo. Admin access also exposes stored deploy credentials, access tokens and repository replication settings. CISA lists this as known exploited. The JFrog advisory is terse and does not describe the mechanism, so the entry stays at what the vendor states.

Who can reach it

Anyone who can reach the Artifactory HTTP endpoint. No authentication and no user interaction. Instances published beyond the build network, or reachable directly from tenant pods that pull images, are the exposed cases.

What to do

Upgrade to a fixed Artifactory release - the record points at the JFrog self-managed release notes and security advisories pages rather than naming a version, so read those for the exact fixed build for your line. Cost is a rolling restart of the Artifactory service; image and package pulls fail during the switch, so stage it in a low-build window rather than mid-training-job. Given KEV status, also audit administrator accounts and access tokens, review recently pushed or overwritten artifacts, and rotate registry credentials afterwards.

References

Related entries

All Container, Kubernetes & orchestration entries

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.