CVE-2022-22967: SaltStack Salt Auth Bypass Vulnerability

CVE-2022-22967 Overview

CVE-2022-22967 affects SaltStack Salt versions prior to 3002.9, 3003.5, and 3004.2. The flaw resides in the Pluggable Authentication Modules (PAM) authentication path. Salt's PAM eauth implementation fails to reject locked user accounts during authentication checks. A previously authorized user whose account has since been locked can continue executing Salt commands. The issue impacts both local shell accounts with an active session and salt-api users authenticating through PAM eauth. The weakness maps to CWE-863: Incorrect Authorization. Salt operates as a high-privilege orchestration framework, so unauthorized command execution can extend across every managed minion in the infrastructure.

Critical Impact

A locked or disabled user account retains the ability to execute Salt commands across the master and connected minions, defeating account lifecycle controls.

Affected Products

• SaltStack Salt versions prior to 3002.9
• SaltStack Salt 3003 versions prior to 3003.5
• SaltStack Salt 3004 versions prior to 3004.2

Discovery Timeline

• 2022-06-23 - CVE-2022-22967 published to the National Vulnerability Database
• 2023-10 - Gentoo issues GLSA 202310-22 covering the advisory
• 2025-05-05 - Last updated in NVD database

Technical Details for CVE-2022-22967

Vulnerability Analysis

Salt provides external authentication (eauth) backends that allow operators and API clients to authenticate using existing identity systems. The PAM eauth backend delegates credential verification to the host operating system through Linux PAM. The implementation in affected versions validates only credential correctness and group membership. It does not query the account status flags that PAM exposes through pam_acct_mgmt. As a result, accounts marked as locked, expired, or disabled by an administrator continue to authenticate successfully against the Salt master. The authorization decision relies solely on the eauth ACL, which references the username regardless of its current state in the underlying user database.

Root Cause

The root cause is an incomplete authorization check in the PAM eauth flow. Salt invokes the authentication phase of PAM but skips the account management phase that enforces lockout, expiration, and policy restrictions. The defect is classified as CWE-863: Incorrect Authorization because the system grants access decisions on stale identity assumptions rather than the current account state.

Attack Vector

Exploitation requires that an attacker previously held valid credentials on a Salt master with PAM eauth configured. After administrators lock the account through passwd -l, usermod -L, or equivalent directory operations, the attacker continues to issue authenticated requests to salt-api or runs Salt commands from a local shell session. Successful command execution can target any minion permitted by the user's eauth ACL, providing a path to lateral movement, configuration tampering, and arbitrary code execution on managed hosts.

No verified public proof-of-concept code is available. Refer to the Salt Project Security Advisory for vendor technical details.

Detection Methods for CVE-2022-22967

Indicators of Compromise

• Successful Salt master authentication events from user principals whose OS account state is L (locked) in passwd -S output.
• salt-api access logs showing token issuance for usernames that no longer appear in active directory groups or have been disabled.
• Salt job records (salt-run jobs.list_jobs) initiated by users after their offboarding date in the identity management system.

Detection Strategies

• Correlate Salt master authentication logs with identity provider lifecycle events to surface authentications by locked or terminated accounts.
• Run scheduled reconciliation between /etc/shadow lock flags and the eauth user list defined in the Salt master configuration.
• Hunt for Salt job submissions executed outside of approved change windows by users with recent account state changes.

Monitoring Recommendations

• Forward salt-master and salt-api logs to a centralized SIEM and alert on authentications by users flagged as disabled in the HR or IAM system.
• Track use of high-impact Salt modules such as cmd.run, file.write, and state.apply and tie execution back to the originating eauth identity.
• Audit Salt eauth ACL configuration files (/etc/salt/master.d/*) for stale user entries on a recurring schedule.

How to Mitigate CVE-2022-22967

Immediate Actions Required

• Upgrade Salt to 3002.9, 3003.5, 3004.2, or later on every Salt master and salt-api host.
• Remove decommissioned or locked user accounts from the Salt master eauth configuration rather than relying solely on OS-level lockout.
• Rotate or invalidate existing Salt authentication tokens after upgrading to force re-authentication of all clients.

Patch Information

The Salt Project released fixed builds on June 21, 2022 covering branches 3002.9, 3003.5, and 3004.2. Packages are distributed through the Salt Project Repository. Downstream distribution fixes are tracked in Gentoo GLSA 202310-22. The patch adds account management validation to the PAM eauth flow so locked accounts are rejected during authentication.

Workarounds

• Disable the PAM eauth module on the Salt master and switch to an authentication backend that enforces full account state checks until patches are applied.
• Restrict network access to salt-api (default TCP 8000) to a tightly scoped management subnet using host firewalls.
• Tighten eauth ACLs to limit which Salt modules each user can invoke, reducing the impact of any unauthorized session.

# Verify installed Salt version and apply upgrade
salt --version

# Debian/Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade salt-master salt-api

# RHEL/CentOS
sudo yum update salt-master salt-api

# Confirm locked accounts are rejected after patching
sudo passwd -l testuser
curl -sSk https://salt-master:8000/login \
  -d username=testuser -d password='Passw0rd!' -d eauth=pam
# Expected response after patch: authentication failure