Red Hat Security Advisory: satellite/iop-vulnerability-engine-rhel9 container image available as a Technology Preview
🔗 CVE IDs covered (6)
📋 Description
CVE-2025-66471 — urllib3: urllib3 Streaming API improperly handles highly compressed data CVE-2026-21441 — urllib3: urllib3 vulnerable to decompression-bomb safeguard bypass when following HTTP redirects (streaming API) CVE-2026-24486 — python-multipart: Python-Multipart: Arbitrary file write via path traversal vulnerability CVE-2026-42561 — python-multipart: python-multipart: Denial of Service via excessive multipart part headers CVE-2026-44431 — urllib3: urllib3: Information disclosure via cross-origin redirects forwarding sensitive headers CVE-2026-48710 — starlette: Starlette: Security restriction bypass via malformed HTTP Host header
🎯 Affected products2
- Red Hat Satellite 6.18
- registry.redhat.io/satellite/iop-vulnerability-engine-rhel9@sha256:e3ff62ed7083a6090e6ef023661c022e1665bbbf598eec929b5a67d80506e415_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: 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 vulnerability, avoid enabling the `UPLOAD_KEEP_FILENAME=True` configuration option in applications using `python-multipart`. This option, when used with `UPLOAD_DIR`, allows an attacker to write files to arbitrary locations. Disabling or not configuring `UPLOAD_KEEP_FILENAME=True` prevents the path traversal vulnerability. Workaround: Deploying an RFC-compliant reverse proxy (such as nginx, Apache, HAProxy, or Caddy) in front of the ASGI server will reject malformed Host headers before they reach the application. This is the most straightforward mitigation that does not require code changes. If custom middleware is present, it should be updated to use `request.scope["path"]` instead of `request.url.path` for any security decisions. The ASGI scope path is derived from the HTTP request line and is not influenced by the Host header, so it reflects the actual request target.
🔗 References (13)
- selfhttps://access.redhat.com/errata/RHSA-2026:51357
- externalhttps://access.redhat.com/documentation/en-us/red_hat_satellite/6.18/html/updating_red_hat_satellite/index
- externalhttps://access.redhat.com/security/cve/CVE-2025-66471
- externalhttps://access.redhat.com/security/cve/CVE-2026-21441
- externalhttps://access.redhat.com/security/cve/CVE-2026-24486
- externalhttps://access.redhat.com/security/cve/CVE-2026-42561
- externalhttps://access.redhat.com/security/cve/CVE-2026-44431
- externalhttps://access.redhat.com/security/cve/CVE-2026-48710
- externalhttps://access.redhat.com/security/updates/classification/
- externalhttps://catalog.redhat.com/software/containers/search
- externalhttps://docs.redhat.com/en/documentation/red_hat_satellite/6.18/html/installing_satellite_server_in_a_connected_network_environment/performing-additional-configuration-on-server_satellite#installing-and-configuring-red-hat-lightspeed-in-satellite
- externalhttps://docs.redhat.com/en/documentation/red_hat_satellite/6.18/html/installing_satellite_server_in_a_disconnected_network_environment/performing-additional-configuration#installing-and-configuring-red-hat-lightspeed-in-satellite
- selfhttps://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_51357.json