RHSA-2026:42079HighCVSS 9.0

Red Hat Security Advisory: Red Hat Ansible Automation Platform 2.6 Product Security and Bug Fix Update

Published
July 20, 2026
Last Modified
September 6, 2026

🔗 CVE IDs covered (14)

📋 Description

CVE-2026-6321 — fast-uri: fast-uri: Path traversal vulnerability allows bypass of security policies CVE-2026-8643 — python-pip: Path traversal via malicious entry point name in pip wheel installation allows arbitrary file overwrite CVE-2026-11332 — ansible-core: argument injection in ansible-galaxy role install leads to arbitrary code execution CVE-2026-12701 — pulpcore: pulpcore: relative_path_validator bypass via directory traversal in FilesystemExport CVE-2026-25681 — golang.org/x/net/html: golang.org/x/net/html: Arbitrary code execution via Cross-Site Scripting CVE-2026-27136 — golang.org/x/net/html: golang: golang.org/x/net/html: Cross-Site Scripting via HTML parsing bypass CVE-2026-27145 — crypto/x509: golang: golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries CVE-2026-32281 — crypto/x509: golang: Go crypto/x509: Denial of Service via inefficient certificate chain validation CVE-2026-33811 — net: golang: Go net package: Denial of Service via long CNAME response in LookupCNAME CVE-2026-39821 — golang.org/x/net/idna: golang: net/http: golang.org/x/net/idna: Privilege escalation via incorrect Punycode label processing CVE-2026-42215 — GitPython: GitPython: Arbitrary command execution due to bypass of dangerous Git option checks CVE-2026-42284 — GitPython: GitPython: Arbitrary code execution via improper validation of clone options CVE-2026-44244 — GitPython: GitPython: Arbitrary code execution via injected newlines in Git configuration CVE-2026-44432 — urllib3: urllib3: Denial of Service due to excessive HTTP response decompression

🎯 Affected products140

  • Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • aap-metrics-utility-0:0.7.5-3.el9ap.aarch64 as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • aap-metrics-utility-0:0.7.5-3.el9ap.ppc64le as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • aap-metrics-utility-0:0.7.5-3.el9ap.s390x as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • aap-metrics-utility-0:0.7.5-3.el9ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • aap-metrics-utility-0:0.7.5-3.el9ap.x86_64 as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-automation-platform-installer-0:2.6-8.1.el9ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-automation-platform-installer-0:2.6-8.1.el9ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-core-1:2.16.19-1.el9ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-core-1:2.16.19-1.el9ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-core-2:2.16.19-1.el10ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-core-2:2.16.19-1.el10ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-creator-0:26.6.1-1.el10ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-creator-0:26.6.1-1.el10ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-creator-0:26.6.1-1.el9ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-creator-0:26.6.1-1.el9ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-dev-environment-0:26.6.1-1.el10ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-dev-environment-0:26.6.1-1.el10ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-dev-environment-0:26.6.1-1.el9ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-dev-environment-0:26.6.1-1.el9ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-dev-tools+server-0:26.7.1-1.el10ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-dev-tools+server-0:26.7.1-1.el9ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-dev-tools-0:26.7.1-1.el10ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-dev-tools-0:26.7.1-1.el10ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-dev-tools-0:26.7.1-1.el9ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-dev-tools-0:26.7.1-1.el9ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • ansible-lint-0:26.6.0-1.el10ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-lint-0:26.6.0-1.el10ap.src as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 10
  • ansible-lint-0:26.6.0-1.el9ap.noarch as a component of Red Hat Ansible Automation Platform 2.6 for RHEL 9
  • +110 more not shown

✅ Remediation

For details on how to apply this update, refer to Ansible Automation Platform documentation. Workaround: To mitigate this issue, users should avoid installing Python wheels from untrusted sources. It is strongly advised against using `pip install` with elevated privileges, such as `sudo`, when installing wheels. Additionally, administrators should inspect `entry_points.txt` within wheels for path separators or absolute paths before installation. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: There is no complete mitigation for this vulnerability. The following measures can reduce risk: 1. If FilesystemExport was never configured on your deployment, you are not affected by this issue. 2. If FilesystemExporters exist in the database, audit them for path traversal sequences ("../"). Existing malicious entries must be cleaned up manually, as the validation functions documented to raise ValidationError do not actually do so in all code paths. 3. Restrict admin-level access to the Pulp API to only trusted operators. Review and audit which accounts have administrator privileges. 4. Ensure SELinux is in enforcing mode on Satellite/Pulp servers to limit the directories the Pulp service user can write to. 5. Monitor filesystem changes outside of expected Pulp directories for signs of exploitation. Workaround: To mitigate this flaw, applications processing untrusted HTML input must implement strict input sanitization and ensure all output is properly encoded before rendering. Deploying a comprehensive Content Security Policy (CSP) can restrict script execution, further reducing the attack surface. Administrators should review application configurations to ensure adequate protection against XSS. Workaround: A flaw was found in the Go standard library crypto/x509 package. When verifying a TLS certificate hostname, VerifyHostname processed each DNS Subject Alternative Name (SAN) entry in a loop and repeatedly split the candidate hostname on "." characters. For certificates with a very large DNS SAN list, CPU use could grow quadratically with the number of SAN entries and hostname labels. Because hostname verification runs before the certificate chain is built, this overhead can occur even when the certificate is not trusted. Red Hat rates this issue as Important. It affects Red Hat products that include the Go standard library crypto/x509 code from an affected Go toolchain version (before Go 1.25.11, or from Go 1.26.0 through Go 1.26.3). Applications and container images built with a fixed Go release (1.25.11 or later, or 1.26.4 or later) are not affected. Community distributions such as Fedora are also affected. Upstream fix: Go 1.25.11 and Go 1.26.4 (GO-2026-5037). Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability. Workaround: To mitigate this issue, applications can be configured to use the pure Go DNS resolver instead of the `cgo` DNS resolver. This can be achieved by setting the `GODEBUG` environment variable to `netdns=go`. For example, to run a Go application with this mitigation: `GODEBUG=netdns=go /path/to/your/go/application`. This change may require restarting affected applications or services to take effect. Users should verify that this change does not negatively impact DNS resolution for their specific application environment. Workaround: Upgrade to a fixed golang.org/x/net release that includes the idna correction, via updated golang or dependent package rebuilds. Workaround: To mitigate this issue, applications that use GitPython and process untrusted input for Git configuration values must implement robust input validation and sanitization. This prevents the injection of newlines that could manipulate `core.hooksPath` and lead to arbitrary code execution. Additionally, ensure that applications interacting with Git repositories operate with the principle of least privilege to limit the potential impact of any successful exploitation.

🔗 References (16)