You can't really upgrade as you're on the official ClearOS/Centos/RHEL latest. However, have a look at the PHP Engines app. It gives you access at least 3 more PHP versions (7.0, 7.1 and 5.?) and the Web Server app gains another another dropdown allowing you to select the PHP version for your site.

Thank you so much for the reply Nick. Unfortunately, the upgrade isn't for PHP, but for security purposes. I wish to publish the webconfig to our public IP, but the security scan result returned failed due to the version of the Apache. Well, if upgrade isn't an option, then I guess publishing the webconfig isn't an option for me too.

I'm wondering why my first reply didn't post... Anway...

Thank you so much Nick for the reply.

Unfortunately, the upgrade isn't for php but for security purposes. I was planning to publish the webconfig over to our public IP but a security scan failed due to the outdated version of the Apache. If upgrade isn't an option, then I guess publishing the webconfig isn't an option for me too.

For new posters the first couple of posts get moderated.

I wish I know where to find the docs, but PHP is pretty well patched against current security vulnerabilities. Have a look at this link, for example. Also try:

rpm -q --changelog php

Any pen testing site which automatically fails php based on version number alone does not understand the RedHat philosophy of keeping packages at stable versions then backporting fixes into them.

Try this link for a better explanation.

Thanks Nick for replying with all effort. However, to give you a clearer idea of what I am facing, please see the attachment as this is the result of my PCI DSS vulnerability scan.

That's just few (maybe half) of so many errors I got due to the apache being outdated. FYI, SSL passed.

So you have not looked at the links I posted?

Taking the first CVE from your image, 2017-7679, and browsing through RedHat's list, it is an httpd (aka Apache) bug, not a php bug. Then looking at the changelog for httpd you see:

[root@server ~]# rpm -q --changelog httpd | grep 7679 -A 3 -B 4

* Tue Jul 25 2017 Luboš Uhliarik <luhliari@redhat.com> - 2.4.6-68

- Resolves: #1463194 - CVE-2017-3167 httpd: ap_get_basic_auth_pw()

  authentication bypass

- Resolves: #1463197 - CVE-2017-3169 httpd: mod_ssl NULL pointer dereference

- Resolves: #1463207 - CVE-2017-7679 httpd: mod_mime buffer overread

- Resolves: #1463205 - CVE-2017-7668 httpd: ap_find_token() buffer overread

- Resolves: #1470748 - CVE-2017-9788 httpd: Uninitialized memory reflection

  in mod_auth_digest

httpd is currently at version 2.4.6-80 so this was fixed many updates ago. Redhat are backporting all the security fixes into httpd-2.4.6 and just issuing minor releases.

I'll let you investigate the other CVE's but I think you'll find ClearOS is pretty (very) clean.

To tell you honestly, I did clicked on the links but didn't bother reading them. Now since you pointed that out, I need to check why the ASV detects these errors. Let me verify the version of the apache. Unfortunately, it is a weekend and the client has left their premises. I will get back to you once I got a hold of him to verify the apache version. Thank you so much Nick!

I'd expect him to be on the same version if running 7.x. Again following the info I posted earlier, it looks like the PCI DSS vulnerability scan is just doing a basic version check and reports back against that, not understanding the Redhat patching system.

This is a good read:

https://www.clearos.com/resources/documentation/clearos/content:en_us:kb_bestpractices_vulnerabilities_overview

I'll add this to the CVE database for ClearOS but Nick's answer is spot on. ClearOS is not vulnerable to this if you are patched and up to date. It was fixed long ago.

The short answer, provided in the link above, is that ClearOS backports fixes into existing versions in order to maintain compatibility. Many pen tests and vulnerability scans do not actually test the vulnerability but rather look at the reported version number ONLY. This is what your test likely did. To satisfy a test, you simply need to rebuttal the results. Since the test fails to validate the vulnerability and answer to the auditor that states:

The current version of Apache running on this system is X (find it from command line with rpm -qi packagename) was fixed in httpd-2.4.6-45.el7_3.5.x86_64.rpm. The system is not vulnerable to the CVE specified.

Redhat has an article worth reading if you are not familiar with the practice of 'backporting fixes'.

https://access.redhat.com/security/updates/backporting