AWS MWAA Execution Role Account Wildcard Vulnerability

Reading time: 3 minutes

The Vulnerability

MWAA's execution role (the IAM role that Airflow workers use to access AWS resources) requires this mandatory policy to function:

{  
    "Effect": "Allow",  
    "Action": [  
        "sqs:ChangeMessageVisibility",  
        "sqs:DeleteMessage",  
        "sqs:GetQueueAttributes",  
        "sqs:GetQueueUrl",  
        "sqs:ReceiveMessage",  
        "sqs:SendMessage"  
    ],  
    "Resource": "arn:aws:sqs:us-east-1:*:airflow-celery-*"  
}

The wildcard (*) in the account ID position allows the role to interact with any SQS queue in any AWS account that starts with airflow-celery-. This is required because AWS provisions MWAA's internal queues in a separate AWS-managed account. There is no restriction on making queues with the airflow-celery- prefix.

Cannot be fixed: Removing the wildcard pre-deployment breaks MWAA completely - the scheduler can't queue tasks for workers.

Documentation Verifying Vuln and Acknowledging Vectorr: AWS Documentation

Exploitation

All Airflow DAGs run with the execution role's permissions. DAGs are Python scripts that can execute arbitrary code - they can use yum or curl to install tools, download malicious scripts, or import any Python library. DAGs are pulled from an assigned S3 folder and run on schedule automatically, all an attacker needs is ability to PUT to that bucket path.

Anyone who can write DAGs (typically most users in MWAA environments) can abuse this permission:

1. Data Exfiltration: Create a queue named airflow-celery-exfil in an external account, write a DAG that sends sensitive data to it via boto3

2. Command & Control: Poll commands from an external queue, execute them, return results - creating a persistent backdoor through SQS APIs

3. Cross-Account Attacks: Inject malicious messages into other organizations' queues if they follow the naming pattern

All attacks bypass network controls since they use AWS APIs, not direct internet connections.

Impact

This is an architectural flaw in MWAA with no IAM-based mitigation. Every MWAA deployment following AWS documentation has this vulnerability.

Network Control Bypass: These attacks work even in private VPCs with no internet access. The SQS API calls use AWS's internal network and VPC endpoints, completely bypassing traditional network security controls, firewalls, and egress monitoring. Organizations cannot detect or block this data exfiltration path through network-level controls.