Addressing vulnerabilities in upstream apps

Latest response

How does the RHSC package users address vulnerabilities found in bundled projects like php 7.2.10, that have been addressed upstream developers, say in 7.2.14 but have yet to be made available to enterprise users of RHSC? This has now come up a few times when we do releases, and we get the dreaded "no go", because a patch is not readily available . If we go out and deploy open source version available from the dev community, say php 7.2.14, will we still get support from REDHAT?


Hello Joseph,

Welcome to the Customer Portal Community.

I'm not entirely sure if I understood your question correctly but I will try to answer it.

In the Red Hat Software Collections Product Life Cycle you could see that PHP 7.2 will be supported until Nov 2020. At the bottom of the page you could read:

At minimum, Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) will be issued if and when available. Lower-impact security advisories may be made in the next point release. All errata are provided at Red Hat's discretion.

So I would guess that if there is a critical security vulnerability in upstream that affects the version in RHSCL, too, Red Hat will backport the patch to fix this vulnerability.

If you know the CVE of a certain vulnerability you could use the Red Hat CVE Database to check whether a Red Hat software package is affected by this one or not.

And last but not least I would suggest the reading of the Blog post Is your software fixed? which contains further information on how to check whether your software is affected or not.

Hope this helps.

Best regards,

Thanks for the prompt reply. My question is really about support if we go out get binaries from the 3rd party. Take for example CVE-2019-9020, its under investigation by RHAT and deemed moderate, whereas the scan system scores it a critical. So if we install the version of php that address this issue (7.2.14) from git, are we on our own in terms of supporting any php issue that arise from using the newer version. What exactly does "support" for RHSC packages include?

Joseph, I'm going to put in a case myself to get an answer, because I don't have the answer. Still recommend you put in a case with Red Hat to get a definitive answer (see my other posts from yesterday)




Please see Jörg Kastning's reply previous to mine for some useful info... also... Please see if this overview on Red Hat Software Collections (RHSC) provides some of the answers you are hunting for Additionally, see this Red Hat solution/article at

Quoted material from link above, highly recommend reading it from the link above

When developing applications for Red Hat® Enterprise Linux®, developers have two major tools chains to choose from:

1.There is a set of tools (known as base tools) delivered within Red Hat Enterprise Linux which includes Python, gcc, PHP, Ruby, Perl, and much more. These tools have the same support life cycle as Red Hat Enterprise Linux - up to ten years. To maintain compatibility, the major versions of these tools are fixed at the time of the "dot-zero" release of Red Hat Enterprise Linux. If you want a toolchain that’s supported for 10 years, then use these.

2.Red Hat Software Collections (RHSCL) are for developers looking for continually updated tools such as the latest stable versions of dynamic languages, open source databases, web infrastructure, and other essential development tools.

RHSCL releases occur semi-annually. The collections have a 2-3 year support life cycle to allow for rapid innovation without sacrificing stability. RHSCL is available with supported Red Hat Enterprise Linux 6 and 7 subscriptions, all Red Hat Enterprise Linux developer subscriptions, and the no-cost Red Hat Enterprise Linux Developer subscription.  In addition to Red Hat Enterprise Linux, many of the collections with Linux containers are also available on Red Hat OpenShift Container Platform, and more.

Software collections allow you to concurrently install multiple versions of the same software components on your system. Packages built as a software collection do not overwrite the versions (base tools) included with Red Hat Enterprise Linux.

Building applications in Linux containers. 

Many RHSCL collections are available with dockerfiles, but are also distributed as full Linux container images that can be obtained from the Red Hat Container Catalog. This makes it easy to build and deploy applications in Linux containers that use RHSCL components. 

The dockerfiles used to build the RHSCL container images are provided as RHSCL RPMs on Red Hat Enterprise Linux 7. These source dockerfiles can be used for building containers with customized RHSCL components.

The Portfolio

Red Hat Software Collections includes many popular developer resources - here are a few of the latest versions:

•Languages and frameworks
◦Node.js v10 and v8
◦Perl 5.26
◦PHP 7.2
◦Python 3.6
◦Ruby 2.5
◦Ruby on Rails 5.0

•Databases (learn about syspaths with some of these}
◦MariaDB 10.2
◦MongoDB 3.6
◦MySQL 8.0
◦PostgreSQL 10

•Web and application servers and HTTP accelerators
◦Apache httpd 2.4
◦nginx 1.14
◦Phusion Passenger 4.0
◦Varnish Cache 6.0

•Complementary development tools
◦Git 2.18
◦Maven 3.5

•IDE ◦Eclipse IDE 4.7

For the full list of collections see the latest RHSCL Release Notes, and here for their respective life cycles.

One other thought,

If you have a public facing Red Hat system, you can subscribe that system to RHSCL (aka RHSC) repository and then do a reposync command to synchronize the repository and then "carry" that sum of rpms to systems (perhaps behind a corporate firewall) and publish (i.e. nfs or web based repository for example) the updated repository to your systems.



Well, if you need some sort of local mirror server to publish packages from RHSCL to other systems behind a corporate firewall as R. Hinton suggested you might wanna take a look at the Poor Man's RHEL Mirror. It servers me well for quite some time, now.


Thanks for letting us know of that, it seems like it is a nice wrapper against reposync & createrepo.



Hi RJ,
You are right. The Poor Man's RHEL Mirror is a collection of wrapper scripts around the tools reposync, createrepo, rsync and modifyrepo.

They make it (at least in my opinion) easier to setup a local mirror server and provide repositories for different stages.




Red Hat in the links I've provided and as Jörg mentioned has stated that RHSCL (aka RHSC) is supported. This means they provide updates. From my cursory reading from what I wrote previously, I suspect it is released quarterly. That being said, there seems to be a delta, a difference in rpms each month when I "grab" the repository using reposync (I just do the reposync/createrepo manually, but Jörg's method could prove very useful).

At this link is some tacit info regarding updates. After you scroll down to the bottom of that page, you are presented with this link which just denotes severity of vulnerabilities.

At this link that I cited earlier it shows when they release new minor releases of the package collection, which of course doesn't directly answer your question...

My currently unconfirmed suspicion is that Red Hat likely (requires confirmation) provides updates during this process but you'd have to do a respository reposync to acquire them.

I recommend opening a case directly with Red Hat informing them you've opened a discussion and that you've read the documentation that Community members have provided but still need questions answered regarding vulnerability updates. You might have to isolate and refocus the initial responses you get to your case from Red Hat from eager technicians who make a quick answer without fully understanding you've already done some research and they provide some of the links we have provided without fully getting to the bottom of your question.

Now Red Hat is on the hook to provide security updates on RHSC (aka RHSCL) since they state they support it. The question is how often. As I've mentioned earlier, I suspect (but can not immediately confirm) that they provide updates for the minor releases and you'd have to do periodic repository reposyncs.

Now the final bit after all of the above is said, Please put in a case with Red Hat with these direct questions that remain unanswered as a result of mine and Jörg's inputs as I mentioned earlier. I think I will do the same (because I'm interested in this with some that have requested this at my work place recently) and whoever finds out first, let's post it here.




I did some digging regarding PHP and found this CVE. The specific RPM you mention is (correction) not there. Sadly they have cast it as "will not fix". See that link. I see PHP through 5.6.33, 7.0.x before 7.0.28, 7.1.x through 7.1.14, and 7.2.x through 7.2.2 but not 7.2.14 cited specifically (read that link to be sure).

The MITRE CVE dictionary describes this issue as:

In PHP through 5.6.33, 7.0.x before 7.0.28, 7.1.x through 7.1.14, and 7.2.x 
through 7.2.2, there is a stack-based buffer under-read while parsing an 
HTTP response in the php_stream_url_wrap_http_ex function in 
ext/standard/http_fopen_wrapper.c. This subsequently results in 
copying a large string.


Red Hat of course won't patch the 3rd party software, but they are on the hook to patch/update their own. As I mentioned earlier, I'm going to put in a case with Red Hat and get more specifics along this discussion

end added




Regarding your previous question:


Thanks for the prompt reply. My question is really about support if we go out get binaries from the 
3rd party. Take for example CVE-2019-9020, its under investigation by RHAT and deemed 
moderate, whereas the scan system scores it a critical. So if we install the version of php that 
address this issue (7.2.14) from git, are we on our own in terms of supporting any php issue that 
arise from using the newer version. What exactly does "support" for RHSC packages include?

In your zeal to potentially install the upstream non-Red-Hat version of any given rpm to mitigate a vulnerability, you may most likely introduce additional vulnerabilities Red Hat mitigated with something called "backporting".

I seriously recommend you read the next two links regarding backporting because it is integral to your desire to have a good security posture. Without this knowledge of backporting and merely applying a version that seemingly seems higher may just introduce other vulnerabilities. backporting info link 1, please read and also backporting link 2, please read

I can't overstate the importance of knowing about backporting in the context of security and how Red Hat does their versioning from the upstream project, in the context of your questions within this thread. Please examine the related links in both of those pages I cited.

Again, please open a case directly with Red Hat as mentioned earlier as they'll be able to more cleanly answer your other questions.



I did open a tik a while back and actually started this thread afterwards. I heard back and it looks like there's no backporting for the issues we saw. Interestingly CVE's deemed "crictical " by Nexpose have a rating of "moderate" by RHAT. I understand the subtleties of ratings by different security teams, but in the end if you are in the RHAT camp, you have to rely on their rating, and their timelines.