The urllib3 library 1.26.x before 1.26.4 for Python omits SSL certificate validation in some cases involving HTTPS to HTTPS proxies. The initial connection to the HTTPS proxy (if an SSLContext isn't given via proxy_config) doesn't verify the hostname of the certificate. This means certificates for different servers that still validate properly with the default urllib3 SSLContext will be silently accepted.
Created python-pip tracking bugs for this issue:
Affects: fedora-all [bug 1945142]
Created python-pip-epel tracking bugs for this issue:
Affects: epel-7 [bug 1945137]
Created python-urllib3 tracking bugs for this issue:
Affects: fedora-all [bug 1945141]
Created python3-urllib3 tracking bugs for this issue:
Affects: epel-all [bug 1945138]
Does this affect urllib3 1.25.x?
(In reply to Miro Hrončok from comment #2)
> Does this affect urllib3 1.25.x?
Probably not, as upstream only added support for HTTPS proxies in 1.26.0:
That's likely the reason why CVE description explicitly mentions 1.26.x: The urllib3 library 1.26.x before 1.26.4 ...
As support for HTTPS proxies was only added in urllib3 version 1.26.0 (see comment 6 above), earlier versions are not affected by this flaw. Version 1.26.0 is not yet used in Red Hat Enterprise Linux or Fedora.
Only versions 1.26.0 - 1.26.3 are affected by this issue.
* Red Hat OpenShift Container Platform (OCP) 4 delivers the python-urllib3 package which includes a vulnerable version of urllib3 module, however from OCP 4.6 the python-urllib3 package is no longer shipped. OCP 4.5 is out of support scope for Moderate and Low impact vulnerabilities, hence is marked Out Of Support Scope.
* Red Hat CodeReady WorkSpaces 2 and Red Hat Gluster Storage 3 are not affected by this flaw because both the products does not ship a vulnerable version of urllib3.