A website is software. Half the PHP web has stopped getting security fixes.

---

QUICK ANSWER

About half of all websites built on PHP run a version its developers no longer patch, and that share rises to about two in three on 31 December 2026. Most flaws sit in plugins, not the core. Check your PHP version and plugin list this week. If nobody is named to do that every month, your site has no maintainer.

---

The website of a forty person engineering firm went live in 2019. A freelancer built it on WordPress, with a theme from a marketplace and twenty seven plugins, and then took a full time job elsewhere. The site still loads. The contact form still sends. The finance director, who inherited it, has not logged into the hosting panel in two years, because nothing looked wrong.

Nothing looking wrong is the problem. A website is not a brochure that was printed once. It is software, built from parts whose authors keep shipping fixes, or stop. When the fixes stop, the site keeps working. It simply stops being defended.

Half the PHP web runs a version that no longer gets security fixes

PHP runs WordPress and most small business sites. W3Techs finds it on 69.9% of the websites whose server language it can identify.

The PHP project publishes exactly when each version stops receiving security fixes. According to php.net, version 7.4 reached end of life on 28 November 2022, 8.0 on 26 November 2023, and 8.1 on 31 December 2025. After those dates, a newly found flaw in that version is never fixed.

Nobody publishes how many websites are still running those versions, so Elevates worked it out. Take W3Techs' version shares for 19 September 2026: 28.0% of PHP sites are on version 7, 7.8% on version 5, 0.1% on version 4. Of the 64.1% on version 8, W3Techs' breakdown puts 16.1% on 8.1 and 6.2% on 8.0. Add them up and about 50.2% of PHP websites run a version that no longer receives security fixes.

That is not a fringe of forgotten hobby sites. It is half of the most common way small businesses are put online.

On 31 December 2026, half becomes two in three

The support calendar does not pause. php.net lists security support for PHP 8.2 ending on 31 December 2026. W3Techs puts 28.9% of PHP 8 sites on 8.2 today.

If nobody moves, the share of PHP websites on an unsupported version rises from about 50% to about 68.7% on New Year's Day. Elevates' calculation again, same sources, same date.

Each of those dates was published years ahead. None of them was a surprise to anyone who was looking. The sites that crossed them simply had nobody looking.

The weak point is not WordPress. It is what gets bolted onto it

WordPress runs 40.2% of all websites, and it gets blamed for a lot. The blame lands in the wrong place.

Patchstack, a company that sells WordPress security, publishes an annual count of new vulnerabilities in the ecosystem. Its 2026 report found 11,334 new vulnerabilities in 2025, a 42% increase on 2024. Of those, 91% were in plugins and 9% in themes. The WordPress core had six, all low priority.

So the core is the most defended part of the site. The plugins are where the risk lives, and every plugin is a separate supplier. A contact form from one developer, a slider from another, a cookie banner from a third, a backup tool from a fourth. Each has its own release schedule, its own priorities, and its own chance of being abandoned by its author.

Twenty seven plugins is twenty seven suppliers. Most businesses could not name one of them.

Almost half of the holes are public before a fix exists

The comfortable assumption is that updating is enough: turn on automatic updates and the problem solves itself. The data says otherwise.

In the same report, Patchstack found that 46% of vulnerabilities did not receive a fix from the developer in time for public disclosure, up from 33% the year before. Its own conclusion: website owners "can't rely on plugin updates as a security measure."

Updating closes the holes that have a fix. It does nothing for a plugin whose author has gone quiet, and nothing for the days between a flaw going public and a patch shipping. For those, somebody has to decide: disable the plugin, replace it, or accept the risk with open eyes. An automatic update cannot make that decision. A person has to.

Attackers move in hours. Most owners move in quarters

The window between disclosure and attack is short. Patchstack found that roughly half of high impact vulnerabilities were exploited within 24 hours. Weighted by how intense the exploitation was, the median time to first exploit was five hours.

Now set that against how most businesses treat their website. The site is reviewed when someone complains, or when a redesign comes up, every few years. A five hour window and a three year review cycle do not meet.

The host is not the safety net either. Patchstack tested common defences, including web application firewalls and Cloudflare, against real exploits of WordPress vulnerabilities, and reports that they blocked 12% of the WordPress specific attacks. Treat that as a vendor's own test, since Patchstack sells the alternative. Even discounted heavily, it says the same thing: the hosting company's firewall is not maintenance.

"It still works" is not the same as "it is still maintained"

This is the sentence that keeps outdated sites online. The homepage loads, so the site must be fine.

An unpatched site looks exactly like a patched one, right up to the day it does not. What changes first is invisible: a spam page injected into a folder nobody browses, a redirect that only fires for visitors arriving from Google, a script added to the checkout. Search engines and browsers may notice before the owner does, and they respond by warning visitors away.

Three costs follow a compromise, and the repair is the smallest of them. The first is the time the site spent serving someone else's purposes before anyone noticed. The second is trust: a client who sees a browser warning on your domain does not read the explanation. The third is legal. If the site holds personal data, a breach can trigger notification duties under Article 33 of the GDPR, which runs to 72 hours once you are aware of it.

None of those costs appears on the invoice for the website. All of them are paid by the business that owns it.

What you can check this afternoon without paying anyone

Most of the first pass is free, and you can do it yourself.

• Find your PHP version. Your hosting control panel shows it, usually under a heading like PHP settings or software. If it starts with 7, or is 8.0 or 8.1, it no longer gets security fixes. If it is 8.2, it stops on 31 December 2026.
• Count your plugins. In the WordPress admin, open the plugins page. Write down how many are installed, and how many are active.
• Delete what is inactive. An inactive plugin still sits on the server, and its code can still be reached. If nobody can say why it is there, remove it.
• Check each active plugin's last update. The plugin directory shows when each one was last updated. A plugin untouched for a year or more is a plugin to replace.
• Turn on automatic updates for minor releases, and check that backups actually run and can be restored. A backup nobody has restored is a hope, not a backup.
• Write down who has admin access. Remove accounts for people who have left.

For many small sites that is an afternoon, and it closes a large share of the easy risk. Do it even if you never speak to an agency.

Where the afternoon ends

The free pass has a ceiling, and it is reached quickly.

Moving from PHP 7.4 to 8.3 is not a switch in the hosting panel. Code written for the old version can break on the new one: a theme that uses functions the new version removed, a plugin that was never updated for it. On an old site, flipping the switch often produces a blank page. So the upgrade gets postponed, and the site stays on the version that no longer gets fixes. That is how half the PHP web got where it is.

The same applies to an abandoned plugin that does something the business relies on, like the booking form or the member area. Replacing it means rebuilding that feature, testing it, and moving its data. That is engineering work, and no checklist covers it.

And the checklist has to be done again next month, and the month after. The afternoon fixes today. It does not make anyone responsible for tomorrow.

What a maintained website looks like, month by month

Maintenance sounds vague, which is why it gets skipped. It is not vague. It is a short routine with a calendar, and it fits on one page.

Every month: apply updates to the core, the theme and every plugin, on a copy of the site first when the update is a major one. Read the security advisories for the plugins actually installed, not the whole ecosystem. Check that last night's backup exists and is complete.

Every quarter: restore a backup onto a test copy and confirm the site works from it. Review who has admin access. Look again at every plugin that has not been updated in six months, and decide whether it stays.

Every year: check the PHP support calendar and plan the next version move before the deadline, not after it. Renew the domain and certificates with a named person watching, not a card that may have expired. Ask whether each plugin still earns its place, because the cheapest plugin to secure is the one that is not installed.

On any advisory with no fix: decide within a day whether to disable, replace or accept. Write the decision down with a date.

None of this is exotic. It is the same discipline any business already applies to its accounts or its vehicles: a schedule, a named person, and a record. What is missing on most sites is not the knowledge. It is the name next to the task.

Software needs an owner, not a launch date

The real gap is not technical. It is that nobody owns the site's running.

Websites are usually sold as a project: a design, a build, a launch, an invoice. The running is treated as an afterthought, or as a hosting fee. But the launch is the day the software starts to age. Every month after it, a supplier somewhere ships a fix or stops shipping them, and somebody has to notice.

That is how Elevates prices a site: the build once, and the running monthly, with a named person responsible for updates, backups and access. The build is never reopened to pay for maintenance, and maintenance is never hidden inside the build. Its own site, elevates.it, is built without a plugin layer at all: the pages are compiled from code Elevates controls, so there are fewer suppliers to watch in the first place.

For a site like the one in the engineering firm, the honest assessment usually lands in one of two places. Sometimes it is an afternoon of cleaning, a PHP upgrade that goes through, and a monthly routine that the firm can run itself or hand to someone. That costs nothing but attention, and it is the outcome to hope for. Sometimes the theme and half the plugins cannot survive the upgrade, and the choice is between rebuilding with fewer moving parts or paying every month to keep an old stack alive on borrowed time. Either way, it should be a decision made on purpose, with the dates in front of you.

The question to ask this week

Ask whoever looks after your website one question: what PHP version does the site run, and when does it stop getting security fixes?

If the answer comes back quickly, with a date and a plan, your site has a maintainer. If the question gets passed around, or the answer is "it is fine, it works", then it has a launch date and nothing since. Elevates can run the check with you and tell you which of the two outcomes you are in.