CVE-2026-13769: AWS CLI Credential File Permission Vulnerability (CVSS 5.5)

Technical summary

CVE-2026-13769 stems from insufficient file permission masking during credential file creation in AWS CLI. The vulnerability is classified as CWE-732 (Incorrect Permission Assignment for Critical Resource). When these three subcommands execute on a Unix-like system without a restrictive umask in place, the resulting credential files are created with world-readable or group-readable permissions instead of being restricted to the owning user only. An unprivileged local attacker with shell access to the system can read these files directly from the filesystem. The CVSS 3.1 score of 5.5 (MEDIUM) reflects the local attack vector and the requirement for an attacker to already have system access; however, the impact is high confidentiality loss of AWS credentials.

Business impact

Compromise of AWS credentials through this vulnerability could lead to unauthorized access to AWS services, data exfiltration, resource abuse, or lateral movement within your AWS infrastructure. The risk is particularly acute for development and CI/CD systems where CLI credentials are frequently generated and stored. An internal threat actor or compromised system account could escalate privileges within your AWS environment without detection if credentials from codeartifact, IAM, or deployment workflows are stolen. Organizations relying on CLI-based automation for sensitive operations face material risk until patching is complete.

Affected systems

AWS CLI v1 versions before 1.44.78 and v2 versions before 2.34.29 are vulnerable. This affects any Unix-like system (Linux distributions, macOS, BSD variants) where AWS CLI is installed and used, particularly development workstations, CI/CD runners, container images, and automation servers. Windows systems are not affected because Windows file permissions work fundamentally differently. The vulnerability is only exploitable if the system's umask has not been hardened—the default configuration on most systems leaves files world-readable unless explicitly restricted.

Exploitability

Exploitation requires local system access; remote exploitation is not possible. An attacker must already have a user account or shell access on the affected system. Once on the system, exploitation is trivial: simply reading the credential files created by the vulnerable CLI commands. No special tools, privileges escalation, or complex attack chains are needed. The barrier to exploitation is low once access is obtained, making this a moderate risk for multi-user systems, shared infrastructure, or environments where account compromise is a realistic threat model.

Remediation

Upgrade AWS CLI to version 1.44.78 or later for v1 users, or version 2.34.29 or later for v2 users. Verify the installed version using 'aws --version'. After upgrading, regenerate any AWS credentials that may have been written by the vulnerable CLI versions and are still in use. As a temporary mitigation before patching, ensure your system umask is set to 0077 (restricting file creation to owner-read/write only) via 'umask 0077' in your shell configuration, though this does not protect already-created files. Audit credential files in ~/.aws/credentials and similar locations for overly permissive permissions and correct them with 'chmod 600'.

Patch guidance

Patch immediately for all systems running AWS CLI v1 or v2 below the stated thresholds. For v1, upgrade to 1.44.78 or later. For v2, upgrade to 2.34.29 or later. Most users should prioritize v2 upgrades as v1 is in maintenance mode. Package managers (pip, apt, brew, yum, etc.) should have updated packages available. After patching, run a quick test of the affected subcommands to verify functionality. Consider automating CLI updates in your deployment pipeline and container image builds to prevent regression.

Detection guidance

Look for credential files in ~/.aws/credentials, ~/.aws/config, and temporary locations with permissions broader than 0600 (owner read/write only). Use 'find ~ -name credentials -o -name config | xargs ls -la' to audit. Check system logs for invocations of 'aws codeartifact login', 'aws iam create-virtual-mfa-device', or 'aws deploy register' on affected versions, especially if followed by file access patterns from other users. Monitor for unusual AWS API calls originating from contexts where credentials should not have been exposed. Inventory all systems running AWS CLI and verify version compliance programmatically.

Why prioritize this

This vulnerability should be patched as part of standard maintenance windows but does not require emergency out-of-band response unless you operate high-risk infrastructure (e.g., shared development boxes, CI/CD systems) where local compromise is a credible threat. The MEDIUM severity score reflects realistic constraints: local access is required, and umask misconfiguration is the enabling condition. However, the complete loss of AWS credential confidentiality once exploited makes this meaningful. Prioritize systems where multiple users or service accounts share access, or where AWS credentials grant broad permissions.

Risk score, explained

The CVSS 3.1 score of 5.5 (MEDIUM, vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) appropriately captures the threat: local attack vector (AV:L), low attack complexity (AC:L), requirement for low privileges (PR:L), no user interaction needed (UI:N), and high confidentiality impact (C:H) with no integrity or availability impact. The score does not reflect the downstream risk of compromised AWS credentials, which could be severe depending on IAM policies attached to those credentials. Organizations should consider context-specific risk elevation if their credential policies are overly permissive.

Frequently asked questions