GHSA-747p-wmpv-9c78

What it actually does

On Unix-like systems, AWS CLI can create its local command-history database without restrictive file permissions. Other local accounts that can reach the file may read recorded CLI invocations, including arguments and operational context that users typed when calling AWS APIs. This is local information disclosure, not remote code execution or credential theft by itself.

Why it matters to the business

Shared developer workstations, bastion hosts, CI runners, and multi-user Unix servers that run AWS CLI with history enabled can leak cloud operational detail to unauthorized local users. Impact is medium (CVSS 5.9): no CISA KEV listing, no ransomware association, and no public exploit maturity, but AWS CLI is widely deployed so unpatched shared hosts remain a reconnaissance risk. The issue has been public for more than seven months, so remaining exposure is primarily a hygiene and shared-host hardening problem rather than an emergency.

How an attack unfolds

An attacker who already has a local login, or control of a low-privilege process, on a Unix host searches user home directories for the AWS CLI history database. Because the file was created with overly permissive permissions, they read it without the owner’s credentials and extract historical AWS CLI commands. Recovered commands can reveal regions, services, resource names, and operational patterns that support further cloud reconnaissance. No remote unauthenticated exploit path is implied.

How to fix it

Upgrade awscli (PyPI) to 1.44.38 or later on all Unix systems. After upgrading, set existing history database files to owner-only read/write (typically mode 0600), remove history files that should not persist on shared hosts, and disable CLI history where it is not required. Prefer dedicated, single-user admin environments over multi-user hosts for AWS CLI work.

How to confirm the fix worked

Confirm the installed awscli package is 1.44.38 or newer. Enable CLI history in a test account and verify newly created history files are owner-only (not group- or world-readable). Inventory existing history files under user home directories, check their modes, and remediate any that remain overly permissive. On shared images, confirm history is disabled or the files are absent.

Typical attack path

1. Obtain local unprivileged access on a Unix system where AWS CLI is used
2. Discover AWS CLI history database files under a user’s home directory
3. Read the database because file permissions are not restricted to the owner
4. Extract historical AWS CLI commands and arguments
5. Use recovered cloud operational details for follow-on reconnaissance or targeting

How to detect it

This issue leaves no distinctive network payload. Hunt for exposure and possible local reads rather than a malware signature: locate AWS CLI history databases under user home directories and check whether they are group- or world-readable; review file-access audit logs (for example auditd or equivalent) for opens of those files by a UID other than the owner. Unexpected local users or service accounts reading another user’s history file is the primary post-exploitation artifact. There are no named threat actors or KEV-linked campaigns associated with this issue.

• .aws/cli/history
• cli_history

What your security team should do

• Patch awscli to 1.44.38+ first on shared Unix hosts, bastions, jump boxes, and CI images
• Inventory systems with AWS CLI history enabled and restrict or remove existing history databases
• Disable CLI history on multi-user systems unless there is a documented need
• Treat this as standard information-disclosure hygiene: not KEV and no known in-the-wild exploitation, but do not leave world-readable admin history on shared hosts
• Include AWS CLI version and history-file permissions in Unix configuration baselines and image builds