RHSA-2026:42815HighCVSS 8.1

Red Hat Security Advisory: Red Hat Ansible Automation Platform 2.2 security update

Published
July 21, 2026
Last Modified
September 10, 2026

🔗 CVE IDs covered (11)

📋 Description

CVE-2026-13149 — brace-expansion: Brace-expansion: Denial of Service due to exponential-time complexity CVE-2026-13676 — fast-uri: fast-uri: Security policy bypass due to improper Unicode hostname canonicalization CVE-2026-44289 — protobufjs: protobufjs: Denial of Service via uncontrolled recursion in protobuf decoding CVE-2026-44290 — protobufjs: protobufjs: Denial of Service via crafted schema CVE-2026-44291 — protobufjs: protobufjs: Arbitrary Code Execution via prototype pollution CVE-2026-44292 — protobufjs: protobufjs: Data integrity impact due to prototype pollution CVE-2026-45740 — protobufjs: protobufjs: Denial of Service via crafted JSON descriptors CVE-2026-48801 — linkify-it: linkify-it: Denial of Service via algorithmic complexity vulnerability CVE-2026-49978 — dompurify: DOMPurify: Cross-site scripting vulnerability allows code execution CVE-2026-59873 — tar: node-tar: Denial of Service via crafted gzip bomb CVE-2026-59874 — tar: Node-tar: Denial of Service via malformed tar archive header

🎯 Affected products2

  • Red Hat Ansible Automation Platform 2.2
  • registry.redhat.io/ansible-automation-platform/automation-portal@sha256:22b248581cace0f76628071e1fcb111e212479e3096fd6a70bac3823c3ce4f0f_amd64 as a component of Red Hat Ansible Automation Platform 2.2

✅ Remediation

For more about Ansible plugins for Red Hat Developer Hub, see References links Workaround: There is no practical mitigation for this vulnerability. The brace-expansion package is typically a transitive dependency pulled in via minimatch and glob, making it difficult to isolate. Users should upgrade to a fixed version of brace-expansion when one becomes available. 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: Avoid decoding untrusted protobuf binary data with affected versions. If immediate upgrade is not possible, reject excessively nested messages at an outer protocol boundary where feasible, or isolate protobuf decoding in a process that can be safely restarted. Workaround: To mitigate this issue, Red Hat recommends configuring applications to avoid parsing or loading protobuf schemas or JSON descriptors from untrusted sources. If processing untrusted schemas is unavoidable, implement strict validation to reject option names containing unsafe property path components before loading them. Additionally, consider running schema processing in an isolated environment to limit the blast radius of potential corruption. Workaround: Mitigation involves preventing prototype pollution within applications that utilize protobufjs. Administrators should ensure that untrusted input cannot pollute `Object.prototype` in the application or its dependencies. Additionally, isolating schema and message processing from untrusted application states can prevent attacker-controlled properties from being resolved as valid protobuf type information. Workaround: To mitigate this issue, applications should avoid directly passing attacker-controlled plain objects to protobufjs message constructors. If processing untrusted JSON input, it is crucial to validate or sanitize object keys and explicitly reject any `__proto__` properties before constructing protobuf messages. This operational control prevents the manipulation of message instance prototypes. Workaround: To mitigate this issue, avoid loading untrusted protobuf JSON descriptors in applications utilizing protobufjs. If untrusted descriptors must be processed, implement validation at an outer boundary to reject excessively nested structures. Alternatively, isolate the descriptor loading process in an environment that can be safely restarted in case of a denial of service.

🔗 References (15)