Introduction
The Helm Security Team has issued a security notice regarding the legacy community-maintained Debian/Ubuntu APT mirror domain, baltocdn.com. This domain was officially decommissioned in September 2025, and all legitimate Helm serving infrastructure behind it was shut down. However, the domain registration later expired and was re-registered by an unrelated third party on May 19, 2026. Third-party security reports indicate that the newly re-registered domain has been repurposed and may now be serving malicious content.
For JFrog Artifactory customers, if your instance hosts a Remote Repository (or a Virtual Repository aggregating a Remote) that proxies https://baltocdn.com, downstream build systems and CI/CD pipelines pulling Helm packages may be exposed to malicious payloads.
The goal of this article is to outline actions to implement a workaround and transition to the officially recommended permanent solution.
Resolution
To restore secure and continuous package access for your Debian/Ubuntu-based Helm installations, update your remote proxy configuration to point to the official, verified community repository endpoint.
- Update the Remote URL Path:
- You can update your Remote repository configuration using either the Artifactory UI (detailed below) or the REST API.
- Via Artifactory UI:
- Navigate to your Artifactory UI and open the settings for the Remote repository proxying baltocdn.com.
- Modify the URL field to point to the current official community repository: https://packages.buildkite.com/helm-linux/helm-debian
- Click Save to apply the changes.
- Align Client and Environment Configurations:
- Ensure that your deployment templates reference the safe, updated virtual/remote Artifactory repository path rather than targeting the old mirror.
- Review direct client configurations against the current official Helm APT installation instructions (https://helm.sh/docs/intro/install/#from-apt-debianubuntu).
Conclusion
By updating your Artifactory configurations, you can mitigate this third-party supply chain threat centrally across your entire enterprise. Migrating your remote paths to the trusted Buildkite endpoints ensures your Kubernetes build tooling stays stable, updated, and completely safe. For more information, please review the official Helm Security Announcement.