Harbor Arbitrary File Overwrite via Chart Upload Path Tra...

Harbor, the CNCF-graduated open source container registry that thousands of organizations rely on to store, sign, and distribute container images and Helm charts, was found in 2020 to contain a serious path traversal flaw tracked as CVE-2020-13788. The vulnerability lived in Harbor's chart upload functionality: a user with permission to push Helm charts to a project could craft a chart package whose internal file paths contained directory traversal sequences (../). When Harbor processed and unpacked that chart, those sequences let the attacker write files outside the directory the chart was supposed to land in — resulting in an arbitrary file overwrite on the host or container running Harbor's core services. For a platform that sits at the center of the software supply chain, brokering every image and chart that flows into production, a bug that lets an authenticated user overwrite arbitrary files is a significant integrity risk, not just a niche edge case.

This post breaks down what CVE-2020-13788 actually does, who it affects, what's known about its severity, how the disclosure and fix played out, and what teams running Harbor should do about it today — including how Safeguard helps close the gap between "a CVE exists" and "our fleet is actually patched."

CVE-2020-13788: What the Vulnerability Actually Does

Harbor's Helm chart support (historically backed by the ChartMuseum-based chart repository component) accepts chart packages — .tgz archives — via an API upload endpoint. Each chart archive contains a set of files (templates, values, metadata) at relative paths inside the tarball. The expectation is that all of those relative paths resolve to locations inside the chart's designated storage directory once the archive is extracted or copied.

The flaw behind CVE-2020-13788 is that Harbor did not adequately validate or sanitize those internal paths before writing the extracted content to disk. An attacker could build a malicious chart whose file entries used ../../../ style traversal sequences in their names. When Harbor unpacked or stored that chart, the traversal sequences were honored literally, letting file content land well outside the intended chart storage location — anywhere the Harbor process's filesystem permissions allowed. This is the same class of bug popularized by the "Zip Slip" research from a few years earlier, applied here to Helm chart upload instead of a generic archive extraction routine.

The practical consequence is arbitrary file overwrite: an attacker with chart-push privileges on a project could potentially overwrite configuration files, application code, or other sensitive files reachable by the Harbor service account. Depending on what gets overwritten and how the host is configured, that can escalate from "corrupted files" to a foothold for further compromise of the registry host itself — which is a serious concern for a container registry that many other systems trust implicitly.

Affected Versions and Components

CVE-2020-13788 affects Harbor releases prior to the fixed versions:

• Harbor before 1.10.3 (1.x branch)
• Harbor before 2.0.0 (2.x branch)

The vulnerable code path sits in Harbor's chart repository / chart upload handling, which processes Helm chart packages submitted through Harbor's API. Any Harbor deployment that has chart repository support enabled and accepts chart uploads from users — including CI/CD pipelines authenticated with project-level push credentials — was potentially exposed. Because the flaw requires the ability to push a chart, the practical blast radius is scoped to users and automation with upload rights to at least one project, which is a meaningfully large population in most organizations that use Harbor as their internal Helm chart repository alongside their container registry.

CVSS, EPSS, and KEV Context

The Harbor maintainers and NVD classified CVE-2020-13788 as a High-severity issue, reflecting the significant integrity impact of arbitrary file overwrite weighed against the requirement for the attacker to already hold authenticated chart-push access — this isn't an unauthenticated, pre-auth remote code execution bug, but a privilege-boundary failure once inside the system.

As of this writing, CVE-2020-13788 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no widely reported evidence of in-the-wild exploitation. Its EPSS (Exploit Prediction Scoring System) probability is low, consistent with most authenticated, application-specific path traversal bugs that require both specific product knowledge and existing access. That said, "low observed exploitation" is not the same as "low risk." Registry compromise is exactly the kind of supply-chain foothold that pays off for an attacker over the long term — quietly, and often long before anyone notices file tampering on a registry host.

Disclosure Timeline

• Discovery and report: The path traversal weakness in Harbor's chart upload handling was identified and responsibly reported to the Harbor project's security process.
• Coordinated fix: The Harbor maintainers addressed the issue by adding proper validation of chart file paths during upload processing, closing off the traversal sequences that allowed writes outside the intended storage directory.
• Patched releases: The fix shipped in Harbor 1.10.3 and was included in the Harbor 2.0.0 release, giving users on either the 1.x maintenance branch or the newer 2.x line a path to remediation.
• Public disclosure: CVE-2020-13788 was published and cataloged, along with a corresponding GitHub Security Advisory describing the arbitrary file overwrite behavior in Harbor's chart repository component.

As with most registry and package-manager vulnerabilities, the gap between "patch available" and "patch applied" is where the real risk lives. Harbor is frequently deployed as long-running internal infrastructure — the kind of service teams stand up once and rarely revisit — which makes it a good candidate for silently running vulnerable versions years after a fix ships.

Remediation Steps

If you operate Harbor as your internal container registry and Helm chart repository, treat CVE-2020-13788 as a concrete action item, not just historical trivia:

1. Upgrade Harbor. Move to Harbor 1.10.3 or later on the 1.x branch, or to Harbor 2.0.0 or later. If you're still running a pre-2.0 Harbor instance today, this is also a good moment to plan a broader upgrade, since older branches accumulate unpatched issues over time.
2. Audit chart-push permissions. Review project-level RBAC to confirm only trusted users and pipelines can push Helm charts. Treat chart-push rights with the same scrutiny as image-push rights — both are write paths into your supply chain.
3. Check the filesystem for signs of tampering. If you were running a vulnerable version with untrusted or loosely controlled chart-push access, review the host filesystem around Harbor's chart storage paths for unexpected files or modified timestamps outside the normal chart directory structure.
4. Run Harbor components with least privilege. Ensure the service account running Harbor's core and chart-handling processes has the minimum filesystem write access it actually needs, and consider read-only root filesystems and container hardening where your deployment model allows it.
5. Add file integrity monitoring around Harbor's data directories so future path traversal or overwrite attempts — known or unknown — get flagged quickly rather than discovered months later.
6. Keep Harbor patched going forward. CVE-2020-13788 is one of several path traversal and access-control issues that have been found and fixed in Harbor over its history. Subscribing to Harbor's security advisories and maintaining a routine upgrade cadence is the durable fix, not a one-time upgrade.

How Safeguard Helps

CVE-2020-13788 is a good illustration of why software supply chain security has to cover the infrastructure that hosts your supply chain, not just the artifacts flowing through it. A container registry like Harbor is trusted by every downstream system that pulls from it — Kubernetes clusters, CI/CD runners, developer workstations. A path traversal bug that lets an attacker overwrite files on that registry host is a supply chain risk in the truest sense.

Safeguard helps teams close exactly this kind of gap:

• Continuous inventory and vulnerability matching across self-hosted infrastructure like Harbor, so a version affected by CVE-2020-13788 (or any other known CVE) is flagged automatically instead of relying on someone remembering to check release notes.
• SBOM-driven visibility into the software running your build and registry infrastructure, correlating installed versions against newly disclosed and historical CVEs so stale, vulnerable deployments don't linger unnoticed.
• Policy enforcement that can gate builds and deployments from registries or chart repositories running known-vulnerable versions, reducing the window between disclosure and remediation.
• Anomaly and integrity monitoring tuned to supply chain infrastructure, helping detect the kind of unexpected file writes that a path traversal exploit like this would produce.
• Prioritized remediation guidance that weighs real-world exploitability signals — including EPSS and KEV status — against your actual exposure, so teams fix the Harbor upgrade that matters instead of chasing every CVE with equal urgency.

Vulnerabilities like CVE-2020-13788 rarely make headlines, but they're precisely the kind of quiet, infrastructure-level weakness that erodes trust in a software supply chain over time. Keeping registry and chart repository software like Harbor current, tightly permissioned, and continuously monitored is foundational work — and it's exactly the kind of foundational work Safeguard is built to support.