Just passing along a lesson learned from a recent website security review and WordPress updates project I was asked to assist with last week.
The scenario was simple enough. A prospective client called and asked, “Can you help me fix my hacked website?”
So, I said “Sure, I would love to help you…”
The hours flew by on that Sunday afternoon as I worked through the cleanup and archiving of years of old PHP scripting littering numerous directories, along with updating and securing four WordPress website installations. In the process of completing my work I made a mistake, hopefully, one you may learn from.
I don’t mind sharing this rather expensive failure, because, really, I should have known better.
Later that day, I called the client to report that all was done and all was loading nicely once again. By that point, I had put over 4 hours into the project. The sky was getting dark outside. No archery practice that day. 🙁
It turns out that along with the four WordPress sites, there was a /members directory as well, filled with PHP scripts the client had set up herself years prior. That directory was clear of malware so I didn’t put much thought to it.
In finishing our call, the client seemed overjoyed at how quickly I was able to work through the process—on what was supposed to be my day off.
And then the shoe fell the next morning.
During my review process, I normally do a spot check on the server’s PHP version. And in doing so I noticed this host was running a very old version of PHP 5.1. Wow! My jaw dropped.
So I thought, “Well that’s insane!” And without a second thought, I clicked over to the web hosts PHP version manager with it’s nicely listed options: PHP 5.6 and PHP 7.x, etc.
What would you have done given the client had at no point discussed with you the words “PHP version”?
A long story short, the next day the client send me a frantic email in uppercase regarding a paragraph in my final report from the day before about my updating PHP to 5.6. It read:
“The PHP problem is what it is, but I didn’t request a PHP upgrade and I didn’t believe it would be an issue because we were focusing on malware.”
It turns out the aforementioned /members directory required PHP 5.2 to function. She was aware of this but didn’t believe that PHP version on the server had a relation to website security.
Since the hosts PHP version manager would not allow a downgrade to a PHP version lower than 5.6, I asked her to contact her host, explaining that “I did not change how the server functions. If the script was working before I made the switch then the PHP version should still be accessible as it was before I clicked the PHP version manager in the web hosts control panel.”
As you can imagine, that response didn’t play so well.
In the end, I accepted that my “logic” wasn’t helping matters, I refunded her the fee paid and we parted ways relatively amicably.
The lesson learned here:
Before changing the PHP version on a client’s website, ask first.
Enjoy and Love.