As practitioners of IT whether be it infrastructure , web development or information security we would have had the interaction with PHP and related requirements in various stages of our professional experience.

That being said, what is so critical about this End of Life (EoL) is that , beyond 31 Dec 2018 both versions including 5.6 and 7 would be cut off with critical patch updates. In other words, even if vulnerabilities are identified & highlighted, there won’t be patches released for these two versions as per PHP supported versions announcement.

Though the original EoL for v5.6 was set at Jan 2017, it was extended until 31 Dec 2018 for obvious reasons of high demand and large scale implementation giving ample time and scope for migrations. In the end, they have decided to no longer extend the cut off date.

Considering the fact, even the vast majority of the websites still run on v5.6, this is going to be an uphill task for sure. As per ThreatPost , neither WordPress nor Joomla have provided a clear road map on the migration plans needed. Drupal has released an update that effective 6 Mar 2019, the minimum requirement of PHP would be versions 7.1+.

With the deadline nearing closer and closer, not much of action is seen from infrastructure side on the migrations to v7.2 or above. A quick scan of the Top 1 million websites offered by Alexa, clearly shows only 4.88 % is currently running with v7.2 or v7.3.

With all these information available, what can we do to increase the adoption of v7.2 on the sole basis of security was to highlight to respective websites on the current risks through public channels and forums.


In this attempt, I tried to scan the entire Top 1 million of Alexa and found to my surprise , not only we have very low adoption,there were so many websites that are leaking their PHP versions in web servers header information itself. As a best practise and part of server hardening, version information should be turned off and that is missed as well giving ample scope to check their individual versions on websites leaking such data.

This PHP information leak can be easily fixed with a simple configuration which is clearly documented in website itself.

With my scan data of the websites leaking PHP versions from  Top 1 million websites, parsed the data quickly and created a simple phpVatch which can showcase the findings in a simple form.

Interesting enough, this scan and the entire process of data collation and interpretation has given me a good experience and I wanted to share the same over here. Simple glance at the above graph clearly shows the alarmingly high and hovering wave of unsafe versions over the safe one which is pretty close to the border line.

Technology used :

Well, I fancy Python for all my scripting work ( sorry PHP fans ) and I tried to whip up a simple scanner to get the header information of the websites from the list.

Differences between multi-threading and multiprocessing made more sense and I ran my initial script in a multiprocessing mode and to my utter dismay it was able to scan very slowly. That clearly shows that I was not prepared well enough to do this and I went back to drawing board and started scouting for ways and means of increasing the efficiency of this script.

Voila. I found a solution which was reasonably good enough to meet my
requirements without demanding too much of infrastructure computing
power. It was the combination of RabbitMQ and Celery running my python scanner in a smooth manner which actually delighted me considering the initial failure. Flower
was one beautiful  tool which I used for progress  monitoring. Within
couple of hours, I was able to get all the data and now I was left with
the task of presenting the same.

Took the regular route of Bootstrap with simple API to serve the contents for phpVatch and completed the same, similar to my earlier project XposedOrNot: Want 850 Million Passwords For Free?.

All scan data is sorted alphabetically and stored as plain text and the API feeds on this raw data for providing the web page with content. The idea of using API instead of static page is to provide the opportunity of refreshing the data at regular intervals and not touching the front end interface.

Couple of things I am happy about this project is that, though phpVatch caters to a very small target who might be interested in PHP, this has given me the opportunity to learn and effectively use more tools which can benefit all. For example, just ran the site through Google Chrome’s Audit under the Developer tool set and to my excitement found that it scored 100% on all three parameters checked, which by itself is a great milestone for me.


Would request all the readers to pass on this critical PHP EoL to folks who need to migrate. Let us all help each other in improving and making the web as a safe and secure one. 



Update 21-Nov-2018

Update 2-Dec-2018

Update 1-Jan-2019