CVE-2026-11332

Think of Ansible roles as “packages” of automation scripts. This issue is about what happens when you install a role: a malicious role can hide a trick inside its dependency instructions so that, when you run the install command, code runs on your computer instead of only setting up the role.

This matters if you use Red Hat Ansible Automation Platform 2 and run ansible-galaxy role install to install roles that aren’t fully trusted. It’s not something that silently affects you just by having Ansible installed; the risk is tied to installing a specially crafted malicious role. The reachability gate here is practical: it’s a risk only when an attacker’s role can get installed via ansible-galaxy role install (no known public exploitation details, and whether your default setup is reachable by default is not known).

This is an AMBER issue because it can lead to arbitrary code execution, but it requires you to install a malicious role through the role installation process. There is currently no confirmed fix/patch information available, so your immediate priority is preventing installation of untrusted roles and asking Red Hat for remediation guidance for CVE-2026-11332.

1. Exposure check (behavioral): Search your environment and documentation for usage of ansible-galaxy role install and for any automation (CI/CD jobs, scripts, provisioning playbooks) that installs roles dynamically.
2. Role source verification: For each installed role, document the source (repository/registry), who approves it, and whether you pin versions. Pay special attention to roles pulled from third-party authors, public role collections, or locations without review.
3. Validate installed content: Where possible, compare installed role directories against an approved provenance process (e.g., internal mirrors, signed artifacts, or checksums). The key “tell” is a role that could contain a crafted meta/requirements.yml dependency definition.
4. Mitigate immediately (workaround): Treat role installation as a high-trust action. Only install roles from sources you trust, and pin versions so changes can’t be swapped underneath you.
5. Watch for the fix: Since no fix/patch info is available yet, contact your Red Hat support channel or monitor Red Hat advisories specifically for CVE-2026-11332 in Red Hat Ansible Automation Platform 2. Apply the vendor update as soon as it’s released.
6. Operational monitoring: After any role installs, review for unexpected outbound connections or new binaries/scripts created on the machine running the install process, especially around the time ansible-galaxy role install ran.
7. Exploit status awareness: There is no public exploit code on record and the KEV list does not include this CVE; keep your focus on prevention and vendor follow-up rather than assuming widespread active exploitation.

CISA due date: not provided (not listed in KEV).

Severity and type: High (CWE-88, argument injection) with impact potential of code execution. Mechanism: During ansible-galaxy role install, ansible-core processes dependency specifications from a role’s meta/requirements.yml. Due to improper neutralization of argument delimiters in dependency fields (notably the src field), a malicious role can inject crafted git configuration/flags, which can cause arbitrary code execution on the installer’s machine. Attack vector and prerequisites: Local execution triggered by the victim running ansible-galaxy role install on a malicious role; no authentication is required for the attacker, but user interaction is required (you must perform the install). Exploitation maturity: No public exploit code on record; not listed in CISA KEV. Predicted likelihood (internal-only finding): EPSS prediction is flat (do not treat as confirmation of real-world exploitation). Fix status: No fixed version/patch information is available in the provided findings for CVE-2026-11332 at this time.