Summary:
A serious bug in SaltStack's popular automation platform allowed environments to read each other's configuration and data because of a caching flaw—if you use SaltStack's Git Providers with different environments, your minions could get the wrong code, corrupt data, or even leak secrets. This post explains the bug in simple terms, shows you how it happens, provides code snippets, and offers links to more information.

What is SaltStack?

SaltStack (just called "Salt") is a big deal in automation and configuration management. You use it to deploy files, set up systems, and more—often fetching configuration ("states" in Salt lingo) from Git repositories.

The Flaw: CVE-2023-20898

In Salt versions prior to 3005.2 and 3006.2, the Git Provider system cached data in a way that ignored which environment ("base", "dev", "prod", etc.) a minion should use.

Here’s the problem:
- When Salt pulls files from Git, it uses a directory in /var/cache/salt/master/gitfs/.

The directory is named using the base of the cache, *not* the environment.

- Two environments (like dev and prod) using Git Providers and the same repo could use the same cache folder.

What goes wrong:

You might “see” data from the other environment if you run debugging tools.

Security Impact:

How Does the Exploit Work?

Let’s say you have two environments: dev and prod. Both use the same repo, but different branches.

#### Example: salt/master config

file_roots:
  dev:
    - /srv/salt/dev
  prod:
    - /srv/salt/prod

gitfs_remotes:
  - https://github.com/myorg/salt-states.git

State Tree in Git

- dev branch: /top.sls has test/dev configs.
- prod branch: /top.sls has prod configs.

Salt’s (buggy) cache logic

cache_dir = os.path.join(
    opts['cachedir'],
    'gitfs',
    salt.utils.gitfs.gen_hash(repo_url),  # no "environment" part!
)

Salt *only* uses the repo URL to choose the folder. If you switch environments (_from dev to prod or vice versa_), and the cache is warm, you might get the wrong files entirely.

Make changes in the dev branch of Git.

2. Harvest secrets in your dev environment (dev/top.sls) you shouldn’t have in prod.

Run a Salt state in prod after dev ran and cached.

4. Oops: Salt loads states for dev because it sees the cache; wrong code runs on your production servers or wrong configs are read.

No fancy hacking needed: Just normal operation crosses the wires.

Run in prod immediately after:

Salt checks the cache directory—the files are from dev (e.g., debug code or secret keys that never should be in dev).

Example Pseudocode

# simplified, not actual Salt code
def read_from_git_cache(env, repo_url):
    cache_dir = '/var/cache/salt/master/gitfs/' + hash(repo_url) 
    files = os.listdir(cache_dir)  # No "env" in path!
    return files

Output in prod

['top.sls', 'debug.sls', 'dev-secrets.sls']  # NOT what you wanted!

*This should never happen: prod gets files from dev.*

Everything described happens at scale.

Companies with dev, stage, prod, and other environments are at high risk, especially if they store sensitive data per environment.
- Even backup and disaster recovery can read the wrong data—leading to data restoration from the wrong environment.

The cache directory now includes the environment, making cross-env cache reading impossible.

If you use an older version:
Upgrade now. Or, as a stopgap, clear the GitFS cache (/var/cache/salt/master/gitfs/) completely between environment runs—but this is error-prone.

Official Advisory:

- SaltStack Security Release Notes: CVE-2023-20898

SaltStack GitHub Issues:

- Bug Report Details on GitHub

Upgrade Instructions:

- Upgrade SaltStack

NVD Database Entry:

- NVD CVE-2023-20898

Conclusion

CVE-2023-20898 might sound boring, but it’s deadly in ops environments that depend on separation. If your Git-based Salt setup has sensitive separation between environments, check your version immediately and patch. This bug is a classic “get the wrong data” class flaw, and the remediation is simple: update SaltStack.

Don’t wait for your secrets or configs to accidentally spill into the wrong hands or break your production!

Timeline

Published on: 09/05/2023 11:15:33 UTC
Last modified on: 09/14/2023 03:15:08 UTC