Your Website Has Not Been Updated: Here Is What You Actually Risk

There is a phrase that IT professionals hear more than almost any other: "It works. Do not touch it." This mentality is everywhere in business. If the website is running, generating leads, processing orders, and not throwing errors, why risk changing anything? Why update?

The answer is simple: because attackers are updating. Every day, new vulnerabilities are discovered in the software your website runs on. When those vulnerabilities are published, attackers add them to their automated tools and start scanning every website on the internet for them. If your site is running the vulnerable version, it will be found. Not in months. In days, sometimes hours.

This article explains exactly what happens when websites are not maintained, why the "do not touch it" approach is a calculated risk that most businesses do not realize they are taking, and what a reasonable update strategy looks like.

What Gets Outdated and Why It Matters

CMS Core (WordPress, Joomla, Drupal, etc.)

Your content management system is the foundation of your website. When a CMS version reaches end-of-life, it stops receiving security patches. Any new vulnerability discovered in that version will never be fixed by the vendor. It is permanently exploitable.

WordPress releases major versions roughly every 4-6 months and security patches between major releases. As of this writing, WordPress 6.x is the current major branch. If your site runs WordPress 5.x or earlier, you are running software that may have unpatched vulnerabilities.

For detailed WordPress vulnerability analysis, see our article on WordPress vulnerabilities and what still breaks.

Server-Side Language (PHP, Node.js, Python)

The programming language running on your server has its own lifecycle. PHP, which powers the majority of CMS-based websites (WordPress, Joomla, Drupal, Magento), is particularly relevant:

PHP Version	Active Support Ended	Security Fixes Ended	Status
PHP 7.4	Nov 2021	Nov 2022	End of life. No security patches.
PHP 8.0	Nov 2022	Nov 2023	End of life. No security patches.
PHP 8.1	Nov 2023	Dec 2025	Security fixes only.
PHP 8.2	Dec 2024	Dec 2026	Security fixes only.
PHP 8.3	Dec 2025	Dec 2027	Active support.

If your website runs on PHP 7.4 (which a surprising number of Swiss business websites still do), you are running a version that has been unsupported for over two years. Every security vulnerability discovered in PHP 7.4 since November 2022 is permanently present on your server. The fixes exist in newer versions. They will never be backported to 7.4.

Plugins, Extensions, and Themes

Plugins are the number one attack vector in CMS-based websites. They are written by third-party developers with varying levels of security expertise. They have access to your database, your file system, and your users' data. And many of them are abandoned by their creators.

An abandoned plugin is one that no longer receives updates from its developer. The code sits on your server, still running, still accessible, but any vulnerability discovered in it will never be patched. It is a permanent open door.

Common signs of an abandoned plugin:

• Last update more than 12 months ago
• Compatibility not tested with recent CMS versions
• Support forum has unanswered questions for months
• Developer has moved on to other projects or stopped responding

WordPress alone has over 60,000 plugins in its repository, and thousands more are distributed outside it. Many have fewer than a hundred installations. When a vulnerability is found in a plugin used by 100 sites, the developer may not even bother to fix it. When it is found in a plugin used by millions (like Contact Form 7 or Yoast SEO), the fix comes quickly, but the race between the patch and the exploit begins.

Read more in our guide on plugin vulnerabilities in CMS systems.

How CVEs Get Published and Exploited

CVE stands for Common Vulnerabilities and Exposures. It is the standardized system for identifying and cataloging security vulnerabilities. When a vulnerability is discovered, it receives a CVE identifier (like CVE-2023-12345) and gets published in databases like the National Vulnerability Database (NVD) and vendor-specific databases like WPScan for WordPress.

The Typical Timeline

1. Discovery: A security researcher or attacker discovers a vulnerability in a piece of software.
2. Responsible disclosure (best case): The researcher contacts the software vendor privately. The vendor develops a patch. The patch is released simultaneously with the vulnerability disclosure. Users have the patch available from day one.
3. CVE publication: The vulnerability is assigned a CVE and published publicly with technical details.
4. Exploit development: Within hours to days of publication, someone (a security researcher, an attacker, or an automated tool) creates working exploit code. This code is often published on GitHub, Exploit-DB, or incorporated into penetration testing frameworks like Metasploit.
5. Mass scanning begins: Within days, automated scanners (operated by both security professionals and attackers) start scanning the internet for websites running the vulnerable version.
6. Exploitation at scale: Botnets add the exploit to their rotation. Every unpatched site is found and compromised automatically.

The window between patch availability and mass exploitation is shrinking. In 2020, it was typically weeks. In 2023, it is often days. For high-profile vulnerabilities (Log4Shell, Spring4Shell, MOVEit), it is hours.

Patch Tuesday and the Weekly Race

Microsoft releases patches on the second Tuesday of each month (Patch Tuesday). Other vendors follow similar schedules. This creates a predictable rhythm: patches are released, attackers reverse-engineer them to understand the vulnerability, and exploits follow within days.

For web applications, the cycle is less structured. WordPress and its plugins release updates whenever they are ready. A critical security patch might come on any day. If you are not monitoring for updates and applying them promptly, you are in the window of exploitation.

The "It Works, Do Not Touch It" Mentality

This approach is not irrational. It comes from experience. Updates have broken things before. A WordPress update that changes the editor breaks the editing workflow. A PHP update that deprecates a function breaks a plugin that relied on it. A theme update that changes a template overwrites custom modifications.

Business owners have learned, through painful experience, that updates can cause problems. So they stop updating. The website keeps working. Months pass. Years pass. And they never see the vulnerability scanners that probe their site daily because those scanners do not show up as errors in the website.

The Update Paradox

Here is the paradox every business owner faces:

• Updating can break things. Some updates change functionality, deprecate features, or introduce compatibility issues. This causes immediate, visible pain.
• Not updating eventually breaks things worse. An unpatched vulnerability leads to a compromise. The compromise leads to downtime, data loss, SEO damage, and legal liability. This causes delayed, severe pain.

The difference is visibility. A broken website after an update is immediately obvious. Everyone notices. The developer gets a call. It gets fixed. The total impact is usually hours to days of disruption and a few hundred francs in developer time.

A compromise from an unpatched vulnerability may not be visible for months. When it is finally discovered, the damage is exponentially worse. Customer data has been stolen. SEO spam has been injected for weeks. Google has blacklisted the site. The recovery costs tens of thousands of francs and takes months.

Updating is the lower-risk option. Always.

Why Agencies Avoid Updates

If updating is so clearly the right approach, why do so many web agencies in Ticino and across Switzerland not do it? Several structural reasons:

No Maintenance Contract

The most common reason. The agency built the website, delivered it, sent the final invoice, and moved on to the next project. There is no ongoing contract that includes maintenance. Updates are nobody's responsibility.

When the client asks for an update a year later, the agency quotes a few hours of work. The client balks at the cost for something they do not understand the value of. The update does not happen.

Fear of Breaking Custom Work

Many agencies build websites with custom code: custom themes, custom plugins, custom modifications to CMS core files (which is itself a bad practice). This custom code often depends on specific versions of the CMS and its APIs. An update to the CMS can break the custom code.

The agency knows this. They know that updating WordPress from 5.9 to 6.0 might break the custom page builder they built. They would need to test and fix the compatibility issues, which takes time they are not being paid for. So they advise the client not to update, or simply do not bring up the topic.

No Testing Environment

Professional software development uses staging environments: a copy of the production site where updates are tested before being applied to the live site. Most agency-built websites do not have staging environments. Updates are either applied directly to production (risky) or not applied at all (riskier in the long term).

Lack of Security Awareness

Not all agencies understand the security implications of outdated software. They see updates as feature improvements, not security necessities. If the current version works and the client has not requested the new features, why update?

This is a knowledge gap, not malice. But the result is the same: the client's website becomes increasingly vulnerable over time.

Real Timeline: From Disclosure to Exploit

Here is a real-world example of how quickly a vulnerability goes from disclosure to mass exploitation:

Day	Event
Day 0	Security researcher discovers a critical SQL injection vulnerability in a popular WordPress plugin (installed on 200,000+ sites).
Day 1	Researcher reports the vulnerability to the plugin developer through responsible disclosure.
Day 7	Plugin developer releases a patched version. CVE is published. WordPress.org sends update notifications to sites using the plugin.
Day 8	Security blogs publish details of the vulnerability. Proof-of-concept exploit code appears on GitHub.
Day 9	WPScan adds the vulnerability to its database. Automated WordPress scanners start checking for the vulnerable version.
Day 10-14	Mass exploitation begins. Botnets scan every WordPress site they can find. Sites that have not updated are compromised.
Day 30+	Long-tail exploitation continues. The vulnerability is now in every scanner's arsenal. Sites that never update will be compromised indefinitely.

The window of safety after a vulnerability is published is measured in days. If your site does not get updated within that window, the probability of compromise approaches certainty.

Automated vs. Manual Updates

Automated Updates

WordPress supports automatic updates for minor releases (security patches) and, optionally, for major releases and plugins. The advantage is speed: security patches are applied within hours of release, closing the vulnerability window. The disadvantage is that automated updates can break things without anyone testing the result.

For most small business websites, automatic minor updates are a reasonable default. The risk of a minor update breaking something is low, and the risk of not patching a security vulnerability is high.

Manual Updates with a Staging Environment

For business-critical websites (e-commerce, web applications, sites with complex custom functionality), the ideal approach is:

1. Maintain a staging environment that mirrors production.
2. Apply updates to the staging environment first.
3. Test key functionality: forms, checkout, user accounts, custom features.
4. If everything works, apply the same updates to production.
5. If something breaks, fix it on staging before touching production.

This approach requires a maintenance contract with your developer or agency, a staging environment (which costs a modest amount for hosting), and a process for regular update cycles (weekly or biweekly).

The Minimum Viable Approach

If you cannot do staged updates, at minimum:

• Enable automatic security updates for your CMS core.
• Take a full backup (files + database) before any update.
• Update plugins monthly. Check the changelog before updating to understand what changed.
• Remove plugins you are not using. A deactivated plugin is still on your server and still vulnerable.
• Monitor your site after updates. Check key pages and functionality.

The Hidden Cost of Not Updating

Beyond the direct security risk, not updating your website has other consequences:

• Performance degradation: Newer versions of CMS software, PHP, and plugins often include performance improvements. Running old versions means running slower code.
• Compatibility issues compound: The longer you wait to update, the bigger the jump. Going from WordPress 5.0 to 5.1 is a small change. Going from 5.0 to 6.4 is a massive one that requires more testing, more fixes, and more cost. The same applies to PHP: jumping from 7.4 to 8.3 requires significant code changes.
• SEO impact: Google considers page speed in its ranking algorithm. Older software is slower. Also, if Google detects your site is running software with known vulnerabilities, it may flag your site in search results.
• Browser compatibility: Modern browsers drop support for older standards. A website built on a 2018 framework may not render correctly in 2025 browsers.
• Hosting support: Hosting providers eventually drop support for old PHP versions. When your host upgrades to a PHP version your old site cannot run on, your site goes offline until it is updated (often at emergency rates).

What You Should Do Now

1. Check your software versions. What CMS version are you running? What PHP version? What plugins? When were they last updated? If you do not know, ask your developer or agency. If they do not know, that itself is a problem.
2. Establish a maintenance contract. Someone needs to be responsible for updates. Whether it is your agency, a freelancer, or your internal IT person, there must be a named individual with a defined responsibility and a regular schedule.
3. Prioritize security updates. Security patches should be applied within 48 hours of release. Feature updates can wait for the next maintenance window. Understand the difference.
4. Remove what you do not use. Every unused plugin, theme, and test page is dead weight and dead weight with potential vulnerabilities. Remove it.
5. Set up monitoring. Google Search Console, uptime monitoring, and file integrity monitoring will alert you if something goes wrong after an update or if a compromise occurs.
6. Get a security assessment. If your site has not been updated in over a year, you likely have existing vulnerabilities. Get them identified and fixed before starting a regular update cycle. Contact our team for a website security audit.

The "it works, do not touch it" approach works until it does not. And when it stops working, the cost is orders of magnitude higher than what regular maintenance would have been. Updates are not optional maintenance. They are how you keep your digital infrastructure functional and secure.