Arz.

PHP 5 and PHP 7 sites · upgrades and security fixes

Upgrade your old PHP site, and fix what has been hiding in it

PHP 7 and everything before it stopped receiving security fixes years ago. I'm Arz. I have recently been moving three long-running sites to PHP 8, and on each server I found something more urgent than an old version number. One had a backdoor planted more than a year earlier. On another, changing a single form field at checkout changed the order total.

Email me your URL See what I found

No technical background needed. Email the URL and the name of your host to sharefood@gmail.com, and we can start from there.

Signs that it is time

  • Your host has told you PHP 7 is being switched off, or wants extra money to keep it running
  • The site was built by an agency years ago and you can no longer reach them
  • A few admin pages show a blank screen on save, so nobody touches them
  • The code is custom or sits on a very old framework, not WordPress, and nobody wants to take it on
  • You do not know whether it has been hacked, because nobody has ever looked on the server
  • Test files, backup files and phpMyAdmin are still sitting on the live site
Official end of security fixes, by PHP version
VersionSecurity fixes
PHP 5.6Ended December 2018
PHP 7.0Ended January 2019
PHP 7.2Ended November 2020
PHP 7.4Ended November 2022
PHP 8.1Ended December 2025
PHP 8.4Supported until December 2028

Source: php.net supported versions and end-of-life list.

Three sites, and what was on the server

These are sites I worked on recently. Client names and URLs are removed. Everything else comes from the assessment reports and change logs written at the time, and the numbers are as recorded.

Online shop for farm produce

  • PHP 7.2 → 8.3
  • Live in production
Found
  • Adding one extra field at checkout set the order total to any number
  • URL parameters on several admin pages were open to SQL injection
  • The account-management page was only hidden from the menu; any staff member could type the URL and create an administrator
  • A test folder still held the key file for a third-party login, downloadable by anyone
Fixed
Checkout now accepts only an allowlist of fields. URL parameters are cast to integers. Permissions are checked on the server. Test and backup files were removed, and rotating the key went on the handover list for the owner.
Verified
A script crawled 439 public pages. In the admin, 58 pages were checked and 11 modules saved one by one. Then I placed a real order with a forged total: the system ignored it and charged the correct amount.

Tour booking site

  • PHP 7.0 → 8.4
  • Tested on the new server
Found
  • The operating system, PHP and the database were all past end of life, so upgrading in place was not possible
  • A scan report left on the server from over a year earlier listed an obfuscated backdoor file planted at that time
  • One piece of admin code could be used to run arbitrary commands
  • The file uploader in the partner admin did not require a login
  • Payment notifications were accepted without checking their signature, so "paid" could be forged
Fixed
The old site was not copied over wholesale. Clean code was deployed to a new server instead. The uploader now requires a login, upload folders cannot execute scripts, the mail library was replaced with a patched release, and payment notifications are signature-checked.
Verified
Credit card, ATM transfer and pay-at-counter were each run end to end in the payment provider's sandbox. A forged payment notification was rejected and the order stayed unpaid. All 3,499 uploaded files matched the old server file by file.

Brand website

  • PHP 7.1
  • Incident review and upgrade assessment
Found
  • It began with a report that someone might have gained control of the server. Logging in confirmed an uploaded backdoor (a webshell)
  • The operating system, PHP and the database were all out of vendor support
Done
A full backup came first, with its integrity verified. Then an inventory of 4,823 PHP files, roughly 390,000 lines, which turned up 143 places certain to break after an upgrade. All of it went into an assessment report.
Advice
Run two tracks. The upload hole is in the application code and can be closed on the current server now. Moving platforms is a large job and gets its own schedule. Do not hold the fix back while waiting for the move.

How I work

  1. Log in and look

    No guessing from a questionnaire. The versions actually running, what is installed, any suspicious files: all of it goes into an assessment report with an estimate.

  2. Change it on staging

    The live site stays as it is. The code goes into version control and every batch of fixes is recorded, so you can later see what changed and when.

  3. Test page by page

    A script crawls every public page. In the admin, saving and deleting are tried in every module. If the site takes payments, the full payment flow is run in the sandbox.

  4. Switch over

    Production is backed up in full before the switch. Afterwards the whole site is crawled again and compared with the staging results.

  5. Hand over

    What changed, what did not, and what needs a decision from you or help from your host is written down and given to you. Unfinished items are listed, not left out.

From the change logs (client details removed)
  • Short tags <? → <?php: 255 places in 57 files
  • eval() in the admin menu page replaced with allowlisted variables (was RCE)
  • PHPMailer 5.2.6 → 6.12.0 (CVE-2016-10033 and others)
  • Checkout: removed the foreach($_POST) variable import; allowlisted fields only
  • Admin id parameters cast to int (several SQL injections)
  • Captcha now uses random_int and expires on a wrong answer (was unlimited retries)
  • Upload folder .htaccess: script execution denied
  • Crawled 439 public pages: all 200 except delisted products and expired documents

What AI does, and what I do

I work with AI assistance and see no reason to hide it. AI reads tens of thousands of lines of old code far faster than a person can. Whether its findings are right is settled one item at a time, by testing on staging.

Left to AI

  • Reading the entire codebase
  • Flagging code that breaks on PHP 8 and code that looks suspicious
  • Proposing fixes
  • Writing crawl and test scripts

Done by me

  • Deciding whether to change something, and how
  • Testing every fix on staging before it goes live
  • Judging which risks you need to hear about first
  • Answering for the result

Who I am, and what I don't do

I'm Arz, an engineer at 造雨人科技, a company in Taiwan. I have been building systems for more than twenty years: admin back ends, payment integrations and workflow automation.

Security is not where I started, and I hold no security certification. What I do is move old code onto a version that is still maintained and close the holes found on the way. If you need a penetration-test report, digital forensics or a compliance audit, that is a job for a security firm, and I will say so. WordPress is not my main field either. Custom PHP sites are what I know best.

Arz's systems development background (Chinese)

Questions people ask

What happens if I leave an old PHP version alone?

Once a version is past its end of life, newly found vulnerabilities are never patched, and hosting companies switch the old versions off one by one. The site will not break overnight, but when something does go wrong there is no fix to install. More often, an old site already has other problems that nobody has looked for.

How long does an upgrade take?

It depends on how much code there is and whether the site has payments, member accounts or third-party login. I log in to the server and assess it first. The report gives an estimate in working days and the reasoning behind it, and you decide after reading it. An estimate given before anyone has read the code is usually wrong.

Does the site go offline during the upgrade?

All changes are made on a staging host while the live site keeps running. Only the final switch touches production. I take a full backup first and agree the time with you in advance, then crawl the whole site again once it is live.

How do I know whether my site has been hacked before?

You usually cannot tell from the public pages. It takes logging in to the server and checking for suspicious files, unexpected accounts, altered settings and existing logs. Of the three sites described on this page, two showed traces of a backdoor planted in the past.

How do you price the work?

Assessment first, then a quote. The assessment counts the code, the places that will break after the upgrade and the features that need testing. If something outside the agreed scope turns up once work has started, I check with you before touching it. This page does not list fixed prices.

What do you need from me to start?

The site URL and the name of your hosting company are enough to start talking. Server access is only needed once you decide to go ahead with an assessment, and we will agree a safe way to hand it over then. Please do not send passwords, verification codes or customer data by email.

Send me the URL

Email three things to sharefood@gmail.com: the site URL, who hosts it, and what has been going wrong lately. I will reply with whether it is worth acting on, what kind of problem it looks like, and what the next step would be. Hold off on passwords and customer data for now.

Email me your URL