CVE-2022-22967: SaltStack Salt Auth Bypass Vulnerability

CVE-2022-22967 Overview

An authentication bypass vulnerability was discovered in SaltStack Salt that allows previously authorized users with locked accounts to continue executing Salt commands. The PAM (Pluggable Authentication Modules) authentication mechanism fails to properly reject locked accounts, enabling unauthorized access to Salt infrastructure even after administrative lockouts have been applied.

This vulnerability affects both local shell accounts with active sessions and salt-api users who authenticate via PAM eauth. The flaw undermines fundamental access control mechanisms, allowing terminated or suspended users to maintain operational control over Salt-managed infrastructure.

Critical Impact

Locked or terminated user accounts can continue executing Salt commands with full privileges, bypassing account lockout security controls and enabling unauthorized infrastructure management.

Affected Products

• SaltStack Salt versions before 3002.9
• SaltStack Salt versions before 3003.5
• SaltStack Salt versions before 3004.2

Discovery Timeline

• 2022-06-23 - CVE CVE-2022-22967 published to NVD
• 2025-05-05 - Last updated in NVD database

Technical Details for CVE-2022-22967

Vulnerability Analysis

This vulnerability falls under CWE-863 (Incorrect Authorization), where the PAM authentication subsystem in SaltStack Salt fails to properly validate account status during authentication checks. When a user account is locked at the system level (typically via /etc/shadow modifications or PAM account management modules), Salt's PAM eauth integration does not correctly interpret or enforce this locked status.

The attack requires network access and low-privilege authentication credentials belonging to a locked account. An attacker who previously had legitimate access, or who has obtained credentials for a locked account, can leverage existing sessions or initiate new connections to execute Salt commands. This represents a significant authorization bypass that undermines the security assumption that locking an account immediately revokes access.

The impact spans confidentiality, integrity, and availability of Salt-managed infrastructure. An unauthorized user can read sensitive configuration data, modify system states across managed minions, and potentially disrupt operations—all while their account should be disabled.

Root Cause

The root cause lies in Salt's PAM authentication implementation, which checks password validity but fails to verify the account's locked status through the appropriate PAM account management modules (pam_acct_mgmt). Standard PAM authentication flows involve multiple phases: authentication (verifying credentials), account management (checking if the account is permitted to log in), and session management. Salt's implementation appears to bypass or incorrectly handle the account management phase, which would normally reject locked accounts.

Attack Vector

The vulnerability is exploitable over the network with low attack complexity. An attacker with credentials for a locked account can authenticate to the Salt master or salt-api service and execute commands as if their account were still active. This is particularly dangerous in scenarios where:

1. An employee is terminated and their account is locked, but Salt sessions persist
2. A compromised account is locked for remediation, but the attacker maintains access
3. Service accounts are disabled but continue to function through Salt
4. salt-api endpoints remain accessible to locked PAM users

The vulnerability mechanism involves the PAM eauth handler processing authentication requests without properly checking account lockout flags. When a user authenticates via PAM, Salt validates the password but does not query whether the account itself is in a locked state, allowing continued access regardless of administrative lockout actions.

Detection Methods for CVE-2022-22967

Indicators of Compromise

• Successful Salt command execution from accounts that have been administratively locked or disabled
• Authentication logs showing PAM authentications from accounts with locked status in /etc/shadow
• Salt event bus activity originating from user accounts that should be inactive
• salt-api access logs showing sessions from terminated or suspended user accounts

Detection Strategies

• Monitor Salt master authentication logs for connections from accounts flagged as locked in system PAM databases
• Correlate Salt command execution events with HR/IAM systems to identify activity from terminated accounts
• Implement log analysis rules to detect authentication successes for accounts with ! or * password lock indicators in /etc/shadow
• Deploy SentinelOne Singularity XDR to detect anomalous Salt master activity and unauthorized command execution patterns

Monitoring Recommendations

• Enable comprehensive Salt event logging and forward events to SIEM for correlation with account status databases
• Configure alerts for Salt command execution by accounts that do not appear in active user directories
• Implement periodic reconciliation between Salt user activity and IAM account status
• Monitor salt-api authentication endpoints for access attempts from disabled accounts

How to Mitigate CVE-2022-22967

Immediate Actions Required

• Upgrade SaltStack Salt to version 3002.9, 3003.5, 3004.2 or later immediately
• Audit all PAM-authenticated Salt users and verify their account status
• Terminate active Salt sessions for any accounts that are currently locked
• Review Salt command history for any activity from accounts that should have been disabled
• Consider temporarily disabling PAM eauth and switching to alternative authentication methods until patching is complete

Patch Information

VMware (SaltStack) has released patched versions that properly validate account lockout status during PAM authentication. Security patches are available through the Salt Project Repository. Additional details are available in the Salt Project Security Advisory and Gentoo GLSA #202310-22.

Administrators should upgrade to the following minimum versions:

• Salt 3002.9 for the 3002.x release branch
• Salt 3003.5 for the 3003.x release branch
• Salt 3004.2 for the 3004.x release branch

Workarounds

• Disable PAM eauth authentication and switch to Salt's internal authentication mechanisms or LDAP eauth
• Implement network-level access controls to restrict Salt master and salt-api access to trusted networks only
• Manually terminate all active sessions when locking user accounts and restart Salt services
• Configure firewall rules to limit salt-api exposure and require VPN access for remote administration
• Deploy application-layer authentication proxies that perform independent account status verification

# Configuration example - Disable PAM eauth in Salt master config
# /etc/salt/master.d/auth.conf

# Disable PAM external authentication
external_auth:
  # Comment out or remove PAM configuration
  # pam:
  #   user1:
  #     - '.*'
  
  # Use file-based authentication instead
  file:
    ^filename: /etc/salt/master.d/users.txt
    admin:
      - '.*'
      - '@runner'
      - '@wheel'