When Squid is run as root, it spawns its child processes as a lesser user, by default the user nobody. This is done via the leave_suid call. leave_suid leaves the Saved UID as 0. This makes it trivial for an attacker who has compromised the child process to escalate their privileges back to root.
Upstream Issue: https://gitlab.com/jeriko.one/security/-/blob/master/squid/CVEs/CVE-2019-12522.txt
Statement: This issue is not a big problem on its own, as it requires another remote code execution vulnerability or that a local user has the privileges to modify the squid processes to be exploited. Thus, it is actually closer to a security enhancement than a vulnerability.
To give a view from RHEL Engineering: This is an unusual CVE assignment which has resulted from a security research report. The report is a critique of the design of Squid, rather than a identifiable, exploitable vulnerability in the software. It can be valuable for any software to get such a critique, but in security research a "vulnerability" must describe a flaw in the implementation in comparison to the design. Hence, I cannot see how it is valid that a CVE name has been assigned to this. (A reductio ad absurdum argument: it will always be possible to imagine a hypothetical improvement in the design of ANY network-facing software, regardless of how non-trivial that might be, or what trade-offs are involved; thus, assigning a CVE name because of the ABSENCE of such an improvement is clearly ridiculous.)
[Satellite's perspective] Satellite does not directly ship the squid package and relies on the version included in Red Hat Enterprise Linux base operating system in the rhel-7-server-rpms repository. The /etc/squid/squid.conf file ensures that the only localhost has cachemgr access and squid is denying all other access to squid. https://github.com/theforeman/puppet-pulp/blob/master/manifests/squid.pp#L25 Red Hat Enterprise Linux 7 also is configured by default with a firewall enabled which ensures that only ports required for external access are allowed as outlined in our installation guide: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.8/html/installing_satellite_server_from_a_connected_network/preparing-environment-for-satellite-installation#satellite-ports-and-firewalls-requirements_satellite This is to protect the system from any unwanted traffic from outside. You can verify that squid (default port: 3128) is not included in the list of ports: # firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: eno49 sources: services: dhcpv6-client mdns ssh vnc-server ports: 80/tcp 443/tcp 5646/tcp 5647/tcp 5671/tcp 8000/tcp 8140/tcp 8443/tcp 9090/tcp 22/tcp 2375/tcp 5000/tcp 16509/tcp 53/udp 69/udp protocols: masquerade: no I think 4.5 CVSS scoring applies to Satellite squid configuration as well. We've already explained the reasoning behind low severity on the CVE page (under "Why did Red Hat score this CVE differently?" section). https://access.redhat.com/security/cve/CVE-2019-12522