Ansible‑core 2.22.0, 2.21.6 and 2.20.11: Galaxy File Write Fixes

ansible-galaxy collection install: symlink path escape #

The CVE-2026-89091 record says the archive extractor validated member paths with lexical normalisation (os.path.abspath) instead of resolving symbolic links, and performed no containment check on symlink-typed directory members before creating them. A crafted tarball can chain symlink directory entries so that a later file member is written outside the destination directory.

The record describes the attack as needing a victim to install a malicious collection:

allows an attacker who can get a victim to install a malicious collection to overwrite arbitrary files

CVE-2026-89091 record

The record also calls this a bypass of the fix for CVE-2020-10691. This suggests that the earlier fix did not cover symlink directory entries, so a reader should not treat it as sufficient for this path. The 2.22.0, 2.21.6 and 2.20.11 notes all list the fix under ansible-galaxy collection install, where the change validates that FILES.json entries are contained in the collection before they are created. CISA's SSVC assessment, dated 2026-10-09, rates exploitation as none. The weakness is CWE-59.

ansible-galaxy role install: role name containment and git clone arguments #

CVE-2026-105929 covers ansible-galaxy role install. The fix validates that the role name is contained to the configured role path, and the same change appears in the 2.22.0, 2.21.6 and 2.20.11 notes. A role name must therefore resolve inside the role path that ansible-galaxy is configured with.

CVE-2026-11332 appears only in the 2.22.0 notes. Role requirements are now passed as positional arguments to git clone. The entry states that before this change a malicious role author could inject arbitrary git configuration through role dependencies. Teams that install roles with dependencies from outside sources should treat the 2.22.0 change as the one that closes this path.

git module: parameters read from repository targets #

CVE-2026-84503 is listed in the 2.22.0, 2.21.6 and 2.20.11 notes with the same wording: the git module was "updated to avoid possible incorrect parameters read from the repo targets." All three notes place it under Bugfixes rather than Security Fixes, so the CVE number is the only marker that it is a security change.

The table lists the releases whose notes carry these fixes. The sources name no affected version range, and give no severity for CVE-2026-105929, CVE-2026-11332 or CVE-2026-84503.

ANSIBLE_DEBUG=1 can display secrets before they are masked #

The 2.22.0 Known Issues state that with ANSIBLE_DEBUG=1 set, raw stdout and stderr of commands run on the target, including module results, are displayed before their secrets are registered for masking. Values such as no_log options may appear in plaintext in debug output. The same release stops showing raw output at -vvv for ssh and -vvvvv for winrm and psrp, showing only the return code, and the raw output remains available with ANSIBLE_DEBUG=1.

For a reader, this means debug runs on playbooks that handle no_log values can expose those values even on 2.22.0. Keep ANSIBLE_DEBUG=1 off for such runs and out of shared logs.

Also in this release #

• Secret masking (2.22.0): known secrets are replaced with $REDACTED$ in display, module logging and callback task results. The ansible.module_utils.secrets API adds register_secret, register_secrets and mask_secrets.
• Breaking (2.22.0): no_log values are no longer shown as VALUE_SPECIFIED_IN_NO_LOG_PARAMETER; playbooks that check for that placeholder need updating.
• Breaking (2.22.0): ansible-config defaults to -t all; use -t base to keep the previous behaviour.
• Python (2.22.0): Python 3.15 is supported on the controller, and Python 3.12 is dropped on the controller.
• Callbacks (2.22.0): ANSIBLE_SUPPORTS_MASKING is removed and now ignored.
• Deprecations (2.22.0): heuristic_log_sanitize(), remove_values(), sanitize_keys() and the live argument of run_cmd are deprecated for removal in 2.25; ansible.module_utils.six is planned for removal in 2.24.
• Removals (2.22.0): ANSIBLE_CONNECTION_PATH, DEFAULT_LIBVIRT_LXC_NOSECLABEL, yes/no for follow_redirects in url/uri, and deprecated yum_repository parameters.
• URL credentials (2.22.0, 2.21.6, 2.20.11): mask_url handles exceptions on parseurl; 2.22.0 also masks passwords in URLs without a username, such as redis://:password@host.
• ansible-test remotes (2.21.6, 2.20.11): FreeBSD 14.5 and 15.1, RHEL 10.2 and 9.8 replace earlier remotes; 2.20.11 removes FreeBSD 13.5 and replaces 14.3 with 14.5.
• ansible-test containers (2.22.0): Ubuntu 22.04 is replaced with 26.04, Alpine 3.23 with 3.24 and Fedora 43 with 44; Windows Server 2016 managed remote is removed.
• ansible-test coverage (2.20.11): code coverage reporting for Python code in integration tests is restored.
• Other changes: git force and track_submodules behaviour, sudo-rs compatibility and more are in the 2.22.0 release notes, with the 2.21.6 and 2.20.11 notes.

Upgrading ansible-core to the fixed releases #

1. Upgrade to 2.22.0 on the 2.22 line, 2.21.6 on the 2.21 line, or 2.20.11 on the 2.20 line.
2. Before moving to 2.22.0, move any controller running Python 3.12 to another supported Python version, because 2.22.0 drops Python 3.12 on the controller.
3. Until the upgrade is done, install collections with ansible-galaxy collection install only from sources you trust, since the CVE record requires a victim to install a malicious collection.
4. Before the upgrade, run ANSIBLE_DEBUG=1 only on playbooks that carry no secrets, and keep its output out of shared logs.

Checking ansible-galaxy and git usage in your automation #

The affected commands are named in the notes as ansible-galaxy collection install and ansible-galaxy role install. Search your repositories and CI configuration for them, then compare the ansible-core release on each controller with the fixed release for its line.

grep -rn "ansible-galaxy \(collection\|role\) install" .