A company’s website is usually the least guarded thing it owns and the most visible. It is often built by an agency, hosted by someone else and updated rarely, but it talks to the same database, email system and cloud account as the rest of the business. Seven in ten websites whose software can be identified run PHP, the language behind WordPress, Drupal, Joomla and Magento. This blog’s arithmetic from W3Techs’ figures is that about half of those sites run a version of PHP that no longer receives security fixes, and on 1 January 2027 PHP 8.2 joins them.

This piece explains why PHP sites are where most website attacks land, what a website reveals about its owner before anyone breaks in, what a break-in exposes beyond the site itself, and what Indian companies and government departments should do about it. It describes categories of weakness and the fixes for them, not methods of attack.

Half of PHP websites run an unpatched version

W3Techs measures sites whose language it can detect; major-version shares are from 22 August 2026 and PHP 8 minor-version shares from 29 June 2026, so the minor-version rows are approximate. Linux distributions such as Debian, Ubuntu and Red Hat backport fixes to some older versions, so a site on an old version number is not always unpatched; but a site still on PHP 5 or 7 almost always is.

About 53% of PHP sites are on versions the PHP project no longer fixes, which is about 37% of all websites whose language W3Techs can identify. PHP 7 alone, whose last branch lost support in November 2022, still runs on 29% of PHP sites. Because PHP 8.2, the most used version, reaches the end of its security fixes on 31 December 2026, the unpatched share rises to about 72% at the turn of the year unless sites upgrade.

There is an irony in these numbers. W3Techs can count a site’s PHP version largely because the site announces it, in a response header that PHP sends by default. That header is the first thing anyone looking for a vulnerable site reads.

The language is rarely the hole; the add-ons are

Most PHP websites are not written from scratch; they are a content-management system plus plugins and themes from many small developers. WordPress alone runs about 40% of all websites. Patchstack, a WordPress security firm, counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than in 2024, and 91% of them were in plugins, 9% in themes and only a handful in WordPress itself. It judged about 36% serious enough to need emergency protection rules. For the most heavily attacked flaws, the median time from public disclosure to mass exploitation was about five hours.

That timing matters more than the count. A company that patches its website monthly, or whenever its agency next visits, is exposed for weeks to flaws that automated scanners begin trying within hours. The attacker does not need to choose a target; scanners try every site that matches.

What a website gives away before it is hacked

None of these needs a break-in. Each is something an ordinary visitor’s browser could request, and each tells an outsider either which door to try or what lies behind it. The most damaging are files that should never have been in the public web folder at all: a configuration file holding the database password and cloud keys, or a backup of the customer database left behind after a migration.

What a hacked website exposes beyond itself

The common thread is that the website is connected to more than the website. A PHP application has to hold credentials to do its job: to its database, to send email, to take payments, to store files in the cloud. Whoever controls the application holds those credentials too. That turns a defaced page into a breach of customer records, a payment-card theft or a foothold into the company network. It also exposes things a company may not think of as secret: staff names and email addresses, the vendors and agencies it uses, internal server names, and the cloud accounts it runs.

The Indian government cases show a quieter cost. The hijacked sites did not look hacked to the people running them. Search engines were shown betting pages and visitors arriving from search were redirected, while administrators saw an ordinary page. TechCrunch found about 50 such links on government domains in May 2024; the same pattern was reported across more than 100 domains, including ministries, a High Court and tax and police portals, in June 2026.

The Indian picture

CERT-In, the national computer emergency response team, handled about 29.44 lakh cyber-security incidents in 2025. The last year for which a breakdown was found, 2022, included 19,793 website defacements, and central and state government websites hacked numbered 59, 42 and 50 in 2020, 2021 and 2022. Government sites must pass a security audit by NIC, STQC or a CERT-In-empanelled auditor before they go live under the Guidelines for Indian Government Websites, but the betting cases show that a clearance at launch says little about a site several years and many plugin updates later.

For companies the stakes are rising. The Digital Personal Data Protection Act provides for penalties of up to Rs 250 crore for failing to take reasonable security safeguards, and its Rules, notified in November 2025, phase in most obligations over 18 months. CERT-In’s 2022 directions already require incidents to be reported within six hours. A leaked configuration file from a forgotten marketing site counts as a breach as much as an attack on the core systems.

What companies should do

• Know what you run. List every public website and subdomain, including old campaign and agency-built sites, with its PHP, CMS and plugin versions and who is responsible for patching it.
• Get onto supported versions. Move off PHP 7 and 8.0–8.1 now, and plan the PHP 8.2 upgrade before 31 December 2026; remove plugins that are not used or no longer maintained.
• Patch in hours, not months. Turn on automatic security updates for the CMS and plugins, or buy a service that applies protection rules on disclosure.
• Keep secrets out of the web folder. Store credentials in a secrets manager or outside the web root, give the website only the access it needs, and rotate any key that has ever been in a public folder.
• Say less. Switch off version headers and detailed errors, delete diagnostic pages, and put admin panels behind a VPN or allow-list.
• Look at your site as Google does. Monitor search results for your domain for unexpected pages, since cloaked spam is designed to be invisible to administrators.

What would fix this

• CERT-In should publish yearly counts of website compromises by sector and by cause (unsupported software, plugin flaw, leaked credential), as it did for defacements, so the scale of the problem is measured.
• Government websites should be re-audited after major changes and at least yearly, not only before launch, and the audit should check the PHP and CMS versions against their end-of-support dates.
• NIC and state IT departments should run a shared inventory of every government web property with its software versions, so that unsupported PHP can be found and replaced centrally.
• The Data Protection Board should say in its guidance that running public-facing software past its end of security support is a failure of reasonable security safeguards.

These are proposals from this blog, not recommendations any agency has adopted.

What this piece could not establish

W3Techs’ version figures cover only sites that reveal a version, mix dates from June and August 2026, and cannot see distribution backports, so the 53% figure is an estimate of exposure, not a count of vulnerable sites. No figure was found for the share of Indian websites, or Indian government websites, running unsupported PHP; this blog did not scan any third-party site to find out. The cause of the Indian betting compromises has not been published; the CMS explanation is a researcher’s suggestion. CERT-In’s defacement breakdown was found only for 2022. Patchstack’s figures come from its 2026 report as summarised on its site and in news coverage.

Sources and caveats

About this article: Researched, written and edited by Umashankar Triplicane Dwarakanathan, with AI research assistance; every figure is meant to trace to the primary source cited. See the Editorial Policy for how sourcing, AI use and corrections work.