urllib3 vulnerable to decompression-bomb safeguard bypass when following HTTP redirects (streaming API)
CVE: CVE-2026-21441
Component: urllib3
CWE: CWE-409
Severity: Important
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2026-01-07T22:09:01.936000+00:00

urllib3 is an HTTP client library for Python. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable redirects by setting `redirect=False` for requests to untrusted source.


Remediation:
Before applying this update, make sure all previously released errata relevant
to your system have been applied.

1. Apply the update

This update is delivered via a package update, not a new installer. To apply the fix, update the necessary package:

dnf -y update python3.11-urllib3

(Alternatively, rerunning the current rhui-installer will also install this package update automatically.)

2. Restart RHUI services

Execute the following command for the update to take effect:

rhui-services-restart

(Alternatively, if you have rerun the installer, this command is not needed because rerunning the installer restarts RHUI services automatically.)
Before applying this update, make sure all previously released errata
relevant to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258
Before applying this update, make sure all previously released errata
relevant to your system have been applied.

For detailed instructions how to apply this update, refer to:

https://docs.redhat.com/en/documentation/red_hat_satellite/6.17/html/updating_red_hat_satellite/index
Before applying this update, make sure all previously released errata
relevant to your system have been applied.

For detailed instructions how to apply this update, refer to:

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.18/html/updating_red_hat_satellite/index
For more details, see the Red Hat Advanced Cluster Management for Kubernetes documentation:

https://docs.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.14/html/multicluster_global_hub/index
Before applying this update, make sure all previously released errata
relevant to your system have been applied.
For more information visit https://access.redhat.com/errata/RHSA-2026:3461
For more information visit https://access.redhat.com/errata/RHSA-2026:3462
If you are using an earlier version of RHACS, you are advised to
upgrade to the version of RHACS mentioned in the synopsis and release
notes in order to take advantage of the enhancements, bug fixes, and/or
security patches in the release.
If you are using an earlier version of RHACS, you are advised to
upgrade to the version of RHACS mentioned in the synopsis and release
notes in order to take advantage of the enhancements, bug fixes, and/or
security patches in the release.
Before applying this update, make sure all previously released errata relevant to your system have been applied.
For details on how to apply this update, refer to:
https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.4#Installation%20and%20upgrade
Before applying this update, make sure all previously released errata relevant to your system have been applied.
For details on how to apply this update, refer to:
https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.5#Upgrading
Before applying this update, make sure all previously released errata relevant to your system have been applied.
For details on how to apply this update, refer to:
https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6#Upgrade
Before applying this update, make sure all previously released errata relevant to your system have been applied.
For details on how to apply this update, refer to:
https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6#Upgrade
The container images provided by this update can be downloaded from the
Red Hat container registry at registry.redhat.io using the "podman pull" command.
The container images provided by this update can be downloaded from the
Red Hat container registry at registry.redhat.io using the "podman pull" command.
The containers required to run Discovery can be installed through discovery-installer
RPM. See the official documentation for more details.
For Red Hat OpenShift AI 2.25.3 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this errata update:

https://docs.redhat.com/en/documentation/red_hat_openshift_ai/
For Red Hat OpenShift AI 2.25.2 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this errata update:

https://docs.redhat.com/en/documentation/red_hat_openshift_ai/
For Red Hat OpenShift AI 2.25.2 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this errata update:

https://docs.redhat.com/en/documentation/red_hat_openshift_ai/
For Red Hat OpenShift AI 3.3 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this errata update:

https://docs.redhat.com/en/documentation/red_hat_openshift_ai/
Before applying this update, make sure all previously released errata relevant to your system have been applied.
For details on how to apply this update, refer to:
https://access.redhat.com/articles/11258
Before applying this update, make sure all previously released errata relevant to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258
Before applying this update, make sure all previously released errata relevant to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258
Before applying this update, make sure all previously released errata relevant to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258
Before applying this update, make sure all previously released errata relevant
to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258
Before applying this update, make sure all previously released errata relevant
to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11358
Before applying this update, make sure all previously released errata relevant
to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11458
Before applying this update, make sure all previously released errata relevant
to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258
Before applying this update, make sure all previously released errata relevant
to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258
Before applying this update, make sure all previously released errata relevant
to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258
For Satellite MCP integration see the Red Hat Satellite documentation.
Red Hat Trusted Artifact Signer simplifies cryptographic signing and verifying of software artifacts such as container images, binaries and source code changes. It is a self-managed on-premise deployment of the Sigstore project available at https://sigstore.dev

Platform Engineers, Software Developers and Security Professionals may use RHTAS to ensure the integrity, transparency and assurance of their organization's software supply chain.

For details on using the operator, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.2

You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.2/html-single/release_notes/index
Red Hat Trusted Artifact Signer simplifies cryptographic signing and verifying of software artifacts such as container images, binaries and source code changes. It is a self-managed on-premise deployment of the Sigstore project available at https://sigstore.dev

Platform Engineers, Software Developers and Security Professionals may use RHTAS to ensure the integrity, transparency and assurance of their organization's software supply chain.

For details on using the operator, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.2

You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.2/html-single/release_notes/index
Red Hat Trusted Artifact Signer simplifies cryptographic signing and verifying of software artifacts such as container images, binaries and source code changes. It is a self-managed on-premise deployment of the Sigstore project available at https://sigstore.dev

Platform Engineers, Software Developers and Security Professionals may use RHTAS to ensure the integrity, transparency and assurance of their organization's software supply chain.

For details on using the operator, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.2

You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.2/html-single/release_notes/index
Red Hat Trusted Artifact Signer simplifies cryptographic signing and verifying of software artifacts such as container images, binaries and source code changes. It is a self-managed on-premise deployment of the Sigstore project available at https://sigstore.dev

Platform Engineers, Software Developers and Security Professionals may use RHTAS to ensure the integrity, transparency and assurance of their organization's software supply chain.

For details on using the operator, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.2

You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.2/html-single/release_notes/index
Red Hat Trusted Artifact Signer simplifies cryptographic signing and verifying of software artifacts such as container images, binaries and source code changes. It is a self-managed on-premise deployment of the Sigstore project available at https://sigstore.dev

Platform Engineers, Software Developers and Security Professionals may use RHTAS to ensure the integrity, transparency and assurance of their organization's software supply chain.

For details on using the operator, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3

You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3/html-single/release_notes/index
The Model Transparency CLI Image is a containerized command-line tool for signing and verifying AI/ML workloads against a private Red Hat Trusted Artifact Signer (RHTAS) instance. It lets teams create signatures and attestations for model artifacts and validate them at build or deploy time using enterprise trust material (e.g., Fulcio/Rekor).

For details on using the Model Transparency CLI image, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3

You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3/html-single/release_notes/index
The RHTAS Policy Controller Operator is Helm-based operator for deploying and managing instances of the Sigstore Policy Controller on OpenShift. It is a self-managed on-premise deployment of the Policy Controller Helm Charts available at https://github.com/sigstore/helm-charts/tree/main/charts/policy-controller

Platform Engineers, Software Developers and Security Professionals may use the RHTAS Policy Controller Operator to enforce policies on OCP clusters by using supply-chain metadata.

For details on using the RHTAS Policy Controller Operator, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3
Red Hat Trusted Artifact Signer simplifies cryptographic signing and verifying of software artifacts such as container images, binaries and source code changes. It is a self-managed on-premise deployment of the Sigstore project available at https://sigstore.dev

Platform Engineers, Software Developers and Security Professionals may use RHTAS to ensure the integrity, transparency and assurance of their organization's software supply chain.

For details on using the operator, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3

You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3/html-single/release_notes/index
Red Hat Trusted Artifact Signer simplifies cryptographic signing and verifying of software artifacts such as container images, binaries and source code changes. It is a self-managed on-premise deployment of the Sigstore project available at https://sigstore.dev

Platform Engineers, Software Developers and Security Professionals may use RHTAS to ensure the integrity, transparency and assurance of their organization's software supply chain.

For details on using the operator, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3

You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3/html-single/release_notes/index
Red Hat Trusted Artifact Signer simplifies cryptographic signing and verifying of software artifacts such as container images, binaries and source code changes. It is a self-managed on-premise deployment of the Sigstore project available at https://sigstore.dev

Platform Engineers, Software Developers and Security Professionals may use RHTAS to ensure the integrity, transparency and assurance of their organization's software supply chain.

For details on using the operator, refer to the product documentation at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3

You can find the release notes for this version of Red Hat Trusted Artifact Signer at https://access.redhat.com/documentation/en-us/red_hat_trusted_artifact_signer/1.3/html-single/release_notes/index
The container images provided by this release, apart from the installer, should be deployed using rhui-installer utility.
See the official documentation for more details.
For more details, see the Red Hat Advanced Cluster Management for Kubernetes documentation:

https://docs.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.13/html/multicluster_global_hub/index
Before applying this update, make sure all previously released errata relevant to your system have been applied.

The steps to apply the upgraded images are different depending on the installation plan approval policy you used
when installing the cert-manager Operator for Red Hat OpenShift.

- If the approval policy is set to `Automatic`, then the Operator will be upgraded automatically when there is a
new version of the Operator. No further action is required to upgrade. This is the default setting.

- If you changed the approval policy to `Manual`, then you must manually approve the upgrade to the Operator.

See https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html for additional
information.
Before applying this update, make sure all previously released errata relevant to your system have been applied.

The steps to apply the upgraded images are different depending on the installation plan approval policy you used
when installing the cert-manager Operator for Red Hat OpenShift.

- If the approval policy is set to `Automatic`, then the Operator will be upgraded automatically when there is a
new version of the Operator. No further action is required to upgrade. This is the default setting.

- If you changed the approval policy to `Manual`, then you must manually approve the upgrade to the Operator.

See https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html for additional
information.
Before applying this update, make sure all previously released errata relevant to your system have been applied.

The steps to apply the upgraded images are different depending on the installation plan approval policy you used
when installing the cert-manager Operator for Red Hat OpenShift.

- If the approval policy is set to `Automatic`, then the Operator will be upgraded automatically when there is a
new version of the Operator. No further action is required to upgrade. This is the default setting.

- If you changed the approval policy to `Manual`, then you must manually approve the upgrade to the Operator.

See https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html for additional
information.
Before applying this update, make sure all previously released errata relevant to your system have been applied.

The steps to apply the upgraded images are different depending on the installation plan approval policy you used
when installing the cert-manager Operator for Red Hat OpenShift.

- If the approval policy is set to `Automatic`, then the Operator will be upgraded automatically when there is a
new version of the Operator. No further action is required to upgrade. This is the default setting.

- If you changed the approval policy to `Manual`, then you must manually approve the upgrade to the Operator.

See https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html for additional
information.
Before applying this update, make sure all previously released errata relevant to your system have been applied.

The steps to apply the upgraded images are different depending on the installation plan approval policy you used
when installing the cert-manager Operator for Red Hat OpenShift.

- If the approval policy is set to `Automatic`, then the Operator will be upgraded automatically when there is a
new version of the Operator. No further action is required to upgrade. This is the default setting.

- If you changed the approval policy to `Manual`, then you must manually approve the upgrade to the Operator.

See https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html for additional
information.
Before applying this update, make sure all previously released errata relevant to your system have been applied.

The steps to apply the upgraded images are different depending on the installation plan approval policy you used
when installing the cert-manager Operator for Red Hat OpenShift.

- If the approval policy is set to `Automatic`, then the Operator will be upgraded automatically when there is a
new version of the Operator. No further action is required to upgrade. This is the default setting.

- If you changed the approval policy to `Manual`, then you must manually approve the upgrade to the Operator.

See https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html for additional
information.
Before applying this update, make sure all previously released errata relevant to your system have been applied.

The steps to apply the upgraded images are different depending on the installation plan approval policy you used
when installing the cert-manager Operator for Red Hat OpenShift.

- If the approval policy is set to `Automatic`, then the Operator will be upgraded automatically when there is a
new version of the Operator. No further action is required to upgrade. This is the default setting.

- If you changed the approval policy to `Manual`, then you must manually approve the upgrade to the Operator.

See https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html for additional
information.
Before applying this update, make sure all previously released errata relevant to your system have been applied.

The steps to apply the upgraded images are different depending on the installation plan approval policy you used
when installing the cert-manager Operator for Red Hat OpenShift.

- If the approval policy is set to `Automatic`, then the Operator will be upgraded automatically when there is a
new version of the Operator. No further action is required to upgrade. This is the default setting.

- If you changed the approval policy to `Manual`, then you must manually approve the upgrade to the Operator.

See https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html for additional
information.