ansible‑core 2.22.0, 2.21.6 and 2.20.11 Fix CVE‑2026‑89091 and Two More

Fixed ansible-core Releases for Each Line #

The 2.21.6 and 2.20.11 changelogs list the same three fixes as 2.22.0, the first release of the new 2.22 line, and 2.19.15 carries them as well. Two of the three are filed under Security Fixes; the git module fix, CVE-2026-84503, sits under Bugfixes on every line.

The 2.22.0 Security Fixes also list CVE-2026-11332, a git configuration injection through role dependencies. That entry is not new: 2.22.0 collects the fixes made during its beta cycle, and the same fix shipped on June 18 in 2.21.1, 2.20.7 and 2.19.11. A 2.21, 2.20 or 2.19 installation that is current since June already has it.

CVE-2026-89091: Symlinks in a Collection Tarball Write Outside the Target #

When ansible-galaxy collection install unpacks a collection, it checked member paths with lexical normalisation, os.path.abspath, instead of resolving symlinks with os.path.realpath, and it did not check where symlink directory members pointed before creating them. According to the CVE record, a crafted tarball can chain symlink directory entries so that a later file member lands outside the destination directory. The attacker only has to get the victim to install the collection, and the overwritten file can lead to code execution with that user's privileges on the control node.

Red Hat published the record on October 8, 25 days before the fix, and describes it as a bypass of the fix for CVE-2020-10691. The changelogs word the fix as validating that FILES.json entries are contained in the collection before creating them. CISA's SSVC assessment of October 9 rates exploitation as none.

CVE-2026-105929 and CVE-2026-84503: Role Paths and git Arguments #

CVE-2026-105929 concerns ansible-galaxy role install, which did not validate that a role name stays inside the configured role path. The changelogs give only that one line, and no CVE record was published by November 13.

The ansible.builtin.git module runs git ls-remote, clone and fetch with the repository URL as a positional argument and without a -- separator. A URL that begins with a dash is therefore read by git as an option, and the record names --upload-pack and --exec as examples. A playbook that passes an attacker-controlled repository URL to the module can run arbitrary commands on the host where the module runs. Red Hat rates CVE-2026-84503 at 6.7 and published the record on November 9, a week after the fix.

Secret Masking in 2.22.0 and the ANSIBLE_DEBUG Gap #

2.22.0 adds secret masking: Ansible now replaces known secret values with $REDACTED$ in display output, module logging and task results passed to callback plugins, while tasks still see the real value. A new ansible.module_utils.secrets API registers further values to mask. The changelog's Known Issues section adds a limit: with ANSIBLE_DEBUG=1, raw stdout and stderr of commands on the target are printed before their secrets are registered, so values only the module knows, such as no_log options, can appear in plaintext. 2.22.0 also drops Python 3.12 on the controller.

Also in this release #

• Security Fixes in 2.22.0: psrp and winrm no longer log raw stdout and stderr at verbosity 5 when a task sets no_log: true.
• 2.22.0 bugfixes with a security angle: tempfile rejects prefix and suffix values with path components, the user module unlinks target SSH key files that are symlinks, and ansible-connection keeps its persistent directory private.
• 2.21.6 and 2.20.11: module_utils.mask_url handles parse errors so it does not disclose the URL, and the sudo become plugin works with sudo-rs in non-English locales.

Upgrading ansible-core and Reviewing What It Installs #

1. Install 2.22.0, 2.21.6, 2.20.11 or 2.19.15 on every control node and execution environment image that runs ansible-galaxy or the git module.
2. On 2.18 or 2.16, plan the move to 2.19 or later, since their November 2 releases list none of these fixes.
3. Until the update, install collections and roles only from Galaxy namespaces or Git repositories that the team controls or has reviewed, and inspect tarballs from elsewhere for symlink entries before installing them.
4. Check every task that passes a variable to the repo option of the git module, and reject values that start with a dash.
5. When moving to 2.22.0, confirm the controller no longer runs Python 3.12, and keep ANSIBLE_DEBUG off wherever logs leave the control node.

pip install --upgrade "ansible-core==2.22.0"    # or 2.21.6, 2.20.11, 2.19.15
ansible --version

Checking Playbooks for ansible-galaxy and git Module Use #

The first search finds install commands and requirements files, which decide whether the two Galaxy CVEs apply. The second lists every git task and its repo value, so a reviewer can see which ones take input from variables.

grep -rnE "ansible-galaxy (collection|role)? ?install|requirements\.ya?ml" --include="*.yml" --include="*.yaml" --include="*.sh" --include="Dockerfile" .
grep -rnE -A4 "(ansible\.builtin\.)?git:" --include="*.yml" --include="*.yaml" . | grep -E "git:|repo:"
tar -tvzf collection.tar.gz | grep "^l"