CVE-2020-11652: Directory traversal in SaltStack salt-master

In April 2020, security researchers at F-Secure disclosed two severe vulnerabilities in SaltStack Salt, the widely used open-source configuration management and remote execution framework. One of them, CVE-2020-11652, is a directory traversal vulnerability in the salt-master's ClearFuncs class that lets an attacker escape SaltStack's intended file_roots and reach files elsewhere on the master's filesystem. Paired with its sibling flaw, CVE-2020-11651 (an authentication bypass in the same class), the SaltStack directory traversal issue turned into one of the most consequential infrastructure vulnerabilities of 2020 — leading to real-world compromises of production systems within days of the patch shipping.

This post breaks down what CVE-2020-11652 actually does, who it affects, what we know about its severity and exploitation, and what teams still running Salt infrastructure should do about it.

What the vulnerability does

Salt's architecture relies on a salt-master process that manages a fleet of salt-minion agents over a lightweight ZeroMQ-based protocol on ports 4505 and 4506. The master exposes a set of "clear" (unauthenticated) and "AES" (authenticated) RPC-style functions through the ClearFuncs class to handle minion authentication, job publication, and file serving.

CVE-2020-11652 arises because several of the methods exposed through ClearFuncs — used for tasks like reading files out of the master's file roots or handling wheel/runner module calls — did not adequately sanitize path input. By supplying crafted arguments containing ../ sequences, a client could direct the master to read (and in some request paths, write) files outside the directories Salt intended to expose, reaching arbitrary locations on the salt-master host's filesystem.

On its own, this is a high-impact information disclosure bug: an attacker who can reach a vulnerable salt-master's network ports can pull sensitive files off the box — SSH keys, configuration secrets, Salt's own private keys, or credentials embedded in pillar/state data. What made 2020's incidents so damaging, though, is that CVE-2020-11652 didn't have to stand alone. Because CVE-2020-11651 let unauthenticated clients invoke the same ClearFuncs methods in the first place, the two bugs combined to give remote, unauthenticated attackers a path from "no access" to "arbitrary file read/write on the master" — and from there, to full remote code execution against the master and, by extension, every minion it managed.

Affected versions and components

The vulnerability affects the SaltStack Salt project itself — specifically the salt-master service and its ClearFuncs RPC handling. It is not limited to a downstream product; any deployment running an unpatched Salt master was exposed, including installations fronted by salt-api.

SaltStack's advisory identified all Salt versions prior to the fixed releases as vulnerable. The project shipped patches in Salt 2019.2.4 and Salt 3000.2, and organizations running any earlier 2019.2.x or 3000.x release (as well as older release lines) needed to upgrade. Because Salt underpins configuration management for a large number of SaaS platforms, hosting providers, and internal infrastructure-as-code pipelines, the practical blast radius extended well beyond organizations that directly manage Salt — anyone relying on a vendor whose infrastructure ran an exposed master was indirectly at risk.

CVSS, EPSS, and KEV context

NVD's CVSS v3.1 scoring for CVE-2020-11652 rates it as High severity (base score 7.5), reflecting a network-exploitable, unauthenticated vulnerability with a high confidentiality impact and no direct integrity or availability impact when scored in isolation (the vector is dominated by the ability to read arbitrary files). Its companion, CVE-2020-11651, is scored Critical (9.8), since it directly grants unauthenticated remote code execution when chained with directory traversal and file-write paths. It's this pairing — a critical auth bypass plus a high-severity traversal bug in the same code path — that made the combined exploit so dangerous in practice, even though CVE-2020-11652 alone doesn't carry a critical CVSS rating.

From an exploitation-likelihood standpoint, EPSS models consistently place CVE-2020-11652 among the higher end of the scoring distribution, which tracks with reality: this pair of bugs saw mass, automated exploitation in the wild almost immediately after disclosure, and that exploitation history is exactly the kind of signal EPSS is designed to capture.

Both CVE-2020-11651 and CVE-2020-11652 are listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. Their inclusion reflects confirmed, real-world exploitation rather than theoretical risk, and under Binding Operational Directive 22-01, federal civilian agencies with any affected Salt infrastructure were required to remediate on an accelerated timeline. For any organization tracking KEV as part of its vulnerability management SLA, this CVE pair should already be flagged as a mandatory, time-bound fix rather than a routine backlog item.

Timeline

• April 2020 — F-Secure's research team identifies and privately reports the authentication bypass and directory traversal vulnerabilities in Salt's ClearFuncs class to SaltStack.
• Late April 2020 — SaltStack releases patched versions, 2019.2.4 and 3000.2, along with a security advisory describing the two issues and urging immediate upgrades.
• Days later, early May 2020 — Attackers reverse-engineer the patch and begin mass-scanning the internet for exposed, unpatched salt-master instances (identifiable via open 4505/4506 ports). Multiple organizations report compromise in this window, including widely reported incidents affecting LineageOS's build infrastructure, the Ghost blogging platform's hosting environment, and other Salt-managed infrastructure. The speed between patch release and active mass-exploitation became a widely cited example of how quickly n-day vulnerabilities get weaponized once a fix reveals the underlying flaw.
• November 2021 — CISA formally adds both CVE-2020-11651 and CVE-2020-11652 to the KEV catalog, cementing their status as confirmed-exploited vulnerabilities that organizations must prioritize.

Remediation steps

If you operate SaltStack infrastructure today, treat any Salt master not running a patched, currently supported release as an active incident risk, not a routine patching task:

1. Upgrade salt-master. Ensure you are running a release that includes the fixes introduced in 2019.2.4 / 3000.2 or later, and stay current with subsequent Salt releases — this vulnerability class (unauthenticated ClearFuncs access plus path traversal) has recurred in variant forms, so version currency matters more than a one-time patch.
2. Restrict network exposure. Salt masters should never be reachable from the open internet. Firewall ports 4505/4506 (and any exposed salt-api endpoint) to known minion IP ranges and management networks only.
3. Audit for exposure and compromise. Check whether your salt-master has ever been internet-facing, review authentication logs and job history for unrecognized activity, and inspect the filesystem for unexpected files, modified state/pillar data, or unfamiliar minion keys.
4. Rotate credentials and keys. If a master was exposed during the vulnerable window, rotate Salt's master keys, minion keys, and any secrets that were reachable via file_roots, pillar data, or the host filesystem — assume anything readable was read.
5. Harden salt-api usage. If you run salt-api, apply the same patch level and network restrictions, since it exposes the same underlying ClearFuncs functionality over HTTP.
6. Track this CVE pair in your vulnerability management program. Given its KEV status, confirm it's flagged for accelerated remediation SLAs rather than standard-cadence patching, and verify closure with an authenticated scan rather than a version string alone.

How Safeguard Helps

CVE-2020-11652 is a textbook example of why software supply chain security requires more than periodic patch reviews: the vulnerability window between disclosure and mass exploitation was measured in days, and the risk didn't stop at organizations directly running Salt — it extended to every downstream service and customer relying on Salt-managed infrastructure they never audited themselves.

Safeguard helps close that gap in a few concrete ways:

• Continuous SBOM and dependency visibility — Safeguard maintains an up-to-date inventory of the infrastructure tooling and software components across your environment and your vendors, so a component like SaltStack doesn't sit in a blind spot between annual assessments.
• KEV-aware prioritization — rather than treating every CVE as equally urgent, Safeguard surfaces vulnerabilities like CVE-2020-11651 and CVE-2020-11652 with their CISA KEV status front and center, so teams can align remediation timelines with actual exploitation risk instead of CVSS score alone.
• Exposure and configuration checks — Safeguard flags risky exposure patterns, such as management-plane ports left reachable from untrusted networks, which is precisely the condition that turned this SaltStack directory traversal flaw into a mass-exploitation event.
• Third-party and supply chain monitoring — because so much of this incident's impact came through vendors and hosting providers running vulnerable Salt infrastructure, Safeguard extends visibility beyond your own stack to the vendors and services your business depends on.

The SaltStack incident is a reminder that infrastructure-as-code tooling is itself part of your attack surface. Treating it with the same rigor as customer-facing applications — continuous inventory, KEV-driven prioritization, and exposure monitoring — is what turns the next disclosure-to-exploitation race into a non-event instead of an incident report.