RHSA-2026:68766HighCVSS 8.2

Red Hat Security Advisory: General availability of the satellite/iop-remediations-rhel9 container image

Published
September 17, 2026
Last Modified
October 5, 2026

🔗 CVE IDs covered (9)

CVE-2026-82417 →CVE-2026-84375 →CVE-2026-12143 →CVE-2026-44705 →CVE-2026-75975 →CVE-2026-76172 →CVE-2026-59869 →CVE-2026-75899 →CVE-2026-75931 →

📋 Description

CVE-2026-12143 — form-data: form-data: Form field override via CRLF injection CVE-2026-44705 — tmp: path Traversal via unsanitized prefix/postfix enables directory escape CVE-2026-59869 — js-yaml: js-yaml: Denial of Service via crafted YAML documents CVE-2026-75899 — fast-uri: fast-uri: Server-Side Request Forgery via repeated hostname percent-decoding CVE-2026-75931 — fast-uri: fast-uri: Host confusion via skipped IDN canonicalization CVE-2026-75975 — fast-uri: fast-uri: Server-side request forgery via malformed IPv6 normalization CVE-2026-76172 — fast-uri: fast-uri: URI parsing flaw enables server-side request forgery and redirects CVE-2026-82417 — qs: qs: Denial of Service via improper validation in stringify function CVE-2026-84375 — js-yaml: js-yaml: Denial of Service vulnerability in YAML parsing

🎯 Affected products2

  • Red Hat Satellite 6.18
  • registry.redhat.io/satellite/iop-remediations-rhel9@sha256:44e25e6001ef3e1aff88973726038ceced40a1d73158af2dadbfab8c45faa2a6_amd64 as a component of Red Hat Satellite 6.18

✅ Remediation

For Red Hat Lightspeed in Satellite installation see the Red Hat Satellite documentation. Workaround: Applications using the `form-data` library should implement strict input validation and sanitization for all field names and filenames derived from untrusted sources. This prevents the injection of control characters (CR, LF, ") that could lead to header injection or form field overrides. Deployments that exclusively use fixed or trusted field names are not impacted. Workaround: To mitigate this vulnerability, validate and sanitize any user-controlled data before it is passed to the prefix, postfix or dir options of the file or directory creation functions, specifically rejecting or stripping input containing path traversal sequences. Workaround: To reduce exposure, restrict the processing of untrusted YAML documents by applications that rely on `js-yaml`. Implement robust input validation and sanitization for all YAML data originating from external or untrusted sources. Consider limiting network access to services that parse YAML content to trusted networks or clients through appropriate firewall configurations. 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: 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. Until updates are available, restrict the processing of user-supplied URIs to trusted sources only, implement strict allowlists for destination hosts (preferably IP-based rather than hostname-based), and apply egress filtering to prevent server-initiated connections to internal networks or cloud metadata services. Workaround: There is no mitigation available for this issue. Apply updates as they become available from Red Hat product teams. Workaround: If an immediate upgrade to qs 6.16.0 is not feasible, avoid re-serializing attacker-influenced parsed query or body objects with qs.stringify. Where qs.parse is used directly, set allowPrototypes: false unless prototype keys are required. For Express applications, review whether the default query parser configuration is necessary. Wrapping qs.stringify calls in try/catch can limit impact to individual requests.

🔗 References (16)