There is a number in Patchstack's current State of WordPress Security report that deserves a moment of silence: For the most intensively exploited vulnerabilities, the weighted median from public disclosure to first observed mass exploitation in 2025 was five hours. Not days. Hours (Patchstack, State of WordPress Security in 2026, February 2026).

If you're a company executive and don't respond within half a working day, you are statistically affected. Most companies can't do that – not from negligence, but because they have neither their own IT department nor the tools to even organize such a response.

... or: What is not alive cannot be killed.

— Steven Broschart

And this isn't about isolated cases: In 2025 alone, 11,334 new vulnerabilities were registered in the WordPress ecosystem, a 42 percent increase compared to the previous year (Patchstack, February 2026). Particularly alarming is the shift in the severity of these gaps: The number of vulnerabilities classified as highly exploitable increased 113 percent compared to the previous year – more critical gaps than in the two previous years combined (The Repository / Patchstack, March 2026). Over 90 percent of these gaps aren't in the WordPress core, which is well maintained, but in the plugins with which virtually every live website adorns itself.

This is the situation we find ourselves in. The response to it has been the same for years: patch faster, monitor better, add more security plugins, use more professional hosting.

These are all legitimate measures. They have just one drawback:

They manage the problem instead of reducing it.

And they cost money and attention that many companies simply don't have.

But there's another question that's rarely asked: Why exactly does the website of a bakery, a law firm, or a mid-sized industrial supplier need to function technically just like a complex web application? Why does a page that essentially displays text, images, and contact information need a database, a scripting language, and a plugin ecosystem with dozens of extensions?

What's Tightening Right Now

In April 2026, Anthropic introduced Claude Mythos, an AI model capable of automatically finding vulnerabilities in software and developing working attacks for them. In the vendor's own tests, this approach not only discovered thousands of previously unknown gaps in every major operating system and web browser – the system also found a 27-year-old vulnerability in OpenBSD, an operating system considered highly secure. Other research teams are observing the trend: Critical security vulnerabilities are increasingly being found by AI, not by humans (Help Net Security, April 2026).

This creates two significant shifts:

  • First: The quantity of discovered vulnerabilities won't increase linearly anymore, but in massive waves. Code that was considered tested and safe for decades must be re-examined for vulnerabilities.
  • Second: Attackers also have access to comparable tools when available. Anthropic already reported in November 2025 that a state-sponsored group used Claude Code in real attacks against approximately thirty targets (Anthropic, Threat Intelligence Report, November 2025).

For practical purposes, this means: The patch window isn't just narrowing, it's becoming structurally untenable.

When AI-driven discovery enters attackers' toolbox – which will happen within months – defenders must deal not with dozens but with thousands of new vulnerabilities per plugin generation, and mass exploitation measured not in hours but in minutes. Whoever faces this development with 'we'll patch faster' has already lost the race. There's only one option left: change the playing field.

How Did We Get Here?

In the early 2000s, websites consisted of static HTML files. When you wanted to change something, you'd upload a new file via FTP. It was cumbersome, especially for less technical users. A circumstance that first made the CMS wave possible.

With WordPress, TYPO3, Drupal, and Joomla, systems became available that allowed content to be edited through a browser interface. This was genuine progress because it decoupled editors from developers.

What few people discussed: This convenience came at a price. Static files became an architecture that required resources with every page request:

  • Query the database,
  • render templates,
  • load plugins,
  • assemble content,
  • deliver it.

And with each plugin that extended this architecture, not only functionality grew but also the attack surface. From a simple file that just delivered content, it became a permanently running application that processes data, executes code, and loads external extensions with every page request – and thus becomes fundamentally attackable.

This shift has a consequence that often gets overlooked in the debate:

Security shifted from being an architectural question to an operational one.

Since then it no longer depends on what the website can fundamentally do, but on how well it's maintained daily. Whoever does the maintenance is reasonably safe. Whoever doesn't becomes part of a statistic within five hours.

Two Security Modes

It's worth naming a distinction here that's almost never made in public discussion.

The Operational Security Mode: An application is potentially vulnerable, so it's permanently monitored, regularly updated, placed behind firewalls, and shielded by additional security tools. This works as long as discipline, personnel, and budget exist. It's the mode large enterprises with their own IT departments can sustain permanently.

For small and medium-sized businesses, it's a mode they can't really sustain – yet they're forced into it because they operate a WordPress site that structurally demands this effort.

The Structural Security Mode: Rather than hardening an application, you reduce the attack surface so there's less to harden. This isn't new – security professionals have been talking about attack surface reduction for decades. What was long missing was a practical way to apply this principle to the typical company website without employing a team of developers.

Exactly this has shifted in recent years.

What 'Static' Changes

The underlying principle is surprisingly simple. Instead of reassembling the website with every visitor request, it's created once in advance – as a collection of finished HTML files that the web server then merely delivers.

  • No database in operation.
  • No scripting language that needs to be executed.
  • No plugins injecting content in real time.

The consequence is a categorical shift in the security problem. A vulnerable component can only be attacked if it's actually reachable.

  • Who doesn't run a database can't suffer SQL injection.
  • Who doesn't execute PHP can't have a PHP vulnerability.
  • Who doesn't load plugins can't be infected by a compromised plugin.

This sounds almost trivial, and technically it is – but strategically it's a completely different way of thinking: not protection through additional controls, but through deliberate reduction of complexity.

Here comes an argument that's usually overlooked in discussions: Even if the tool used to create the website is technically imperfect – say, because it was partly developed with AI assistance and contains security weaknesses – it remains in the background. It only runs when someone deliberately changes content. It's not publicly reachable. And if it were ever compromised, the consequence would be a corrupted build environment, not a compromised live website with everything connected to it.

This separation between building and operating is what makes the static architecture so robust. What's reachable on the internet isn't the tool, but only its result. And a finished HTML document has no server-side runtime environment through which an attacker could dynamically penetrate the system.

Remarkably, Patchstack explicitly warns in its current report that the spread of AI-assisted code creation – what goes by the term vibe coding – is intensifying the vulnerability problem in the classic plugin ecosystem because developers publish code they themselves can no longer fully review (Patchstack, State of WordPress Security in 2026).

In the static model, this argument loses its edge. Not because the code would be better, but because it's not in the hot path.

Three Positive Side Effects

The static architecture doesn't just solve the security problem. It brings three additional effects that are special features in the classic CMS model but practically come free here.

1. Staging as Default State

If you operate a classic CMS site and need a test environment before making changes, you have to set one up:

  • a second database,
  • a second server,
  • synchronization routines,
  • a plugin or service.

In the static model, this isn't necessary. The build environment is the staging environment. Whatever is created there can be reviewed, corrected, and reworked as much as needed before anything goes public. What was an operational add-on becomes an architectural default state.

2. Performance

A static file delivered directly from a server or content delivery network isn't just a bit faster than a dynamically generated page. Time-to-First-Byte values (the time for a server to start sending data packets in response to a request) in the low double-digit millisecond range are no exception but the norm. Classic CMS systems barely achieve comparable values even with aggressively configured caching – which itself requires maintenance and fails in edge cases.

This isn't just a technical detail. Established studies from Google and major online retailers have shown for years that every additional second of load time measurably costs conversions, dwell time, and interaction. In B2B, bounce rates increase sharply above three seconds of load time.

3. Visibility

Google has rated load speed and stability as ranking signals since introducing Core Web Vitals. Less discussed but technically well documented is the importance of these factors for AI systems. AI crawlers like GPTBot, ClaudeBot, or PerplexityBot often work primarily based on initially delivered HTML and operate within tight time windows of just a few seconds, beyond which they skip a page.

A dynamic page with:

  • long load times,
  • client-side loaded content,
  • or complex rendering processes

runs the risk of not being captured at all or only partially – regardless of how high quality its content is. Static HTML meets these requirements almost automatically. This isn't a guarantee of being cited in AI responses – that still depends on:

  • content,
  • authority,
  • and relevance.

But it is the technical prerequisite for it.

What isn't captured can't be cited.

These three effects change the cost calculation. A classic CMS doesn't just require:

  • security maintenance,
  • but also performance tuning,
  • separate staging setups,
  • and SEO effort.

In the static model, these requirements are already built into the architecture. This isn't necessarily an argument for every website – but it is an argument that's often missing from the discussion because it doesn't fit the 'feature versus feature' schema but emerges one level deeper.

Why This Becomes Feasible Now

Static site generators aren't new. Tools like Jekyll or Eleventy have existed for over a decade in some cases and have long been used in tech-savvy circles. What has changed isn't the concept but the accessibility.

Until now, these tools required:

  • command line knowledge,
  • familiarity with version control,
  • and often special hosting setups.

No problem for developers. For a mid-sized company's marketing director, though, a hurdle that was rarely overcome in practice. AI-driven tools change this equation. What once required setting up a build pipeline and writing custom templates can now increasingly be configured through dialog. Platforms are emerging that make the static model so accessible that it's usable without developer knowledge:

  • with migration assistants,
  • migrated WordPress content,
  • and editorial interfaces that barely fall short of the comfort of classic CMS.

This development is still in its infancy. But it lowers the threshold at which the static architecture becomes a realistic option. The real point, therefore, isn't:

that suddenly a new technical innovation solves the security problem.

Rather:

that a long-known architectural answer finally becomes practically accessible to a target audience that couldn't use it before.

Where Static Pages Fit – and Where They Don't

No, static documents aren't a universal solution. As soon as a website needs truly dynamic functions:

  • login areas,
  • real-time data,
  • complex searches,
  • transactional processes,
  • personalized content,

the purely static architecture reaches its limits.

At this point, though, hybrid models can emerge: the static core is supplemented with selective dynamic components – also through specialized third-party providers:

  • search runs externally,
  • form processing does too,
  • authentication as well.

This doesn't eliminate the security problem. It distributes it. But: Specialized providers usually have significantly more resources and expertise than a mid-sized company that actually sells pumps or accounting software and shouldn't be patching WordPress plugins permanently.

When does it make sense to use static pages? Clearly, for:

  • corporate websites,
  • portfolios,
  • documentation,
  • blogs,
  • or product presentations,

the static architecture is in many cases the structurally superior choice. For full-fledged web applications with user accounts, transactions, and complex interaction, it isn't.

'But It's Just Our Website'

At this point, discussions with decision-makers almost always produce the same objection: Even if the security situation is as bad as it is – wouldn't it be acceptable if the company website went down for a few hours or days? Is an architecture decision really worth the effort for a risk of this magnitude?

The question sounds reasonable. But it rests on two assumptions that rarely hold in practice – and answering them shifts the picture fundamentally.

The first assumption: The damage from a successful attack is downtime. That's the exception, not the rule. Most compromised SMB websites don't go offline – they stay online and keep working. They just show their visitors:

  • malicious code,
  • redirect search queries to phishing pages,
  • send spam in the company's name,
  • host content for criminals.

The owner often notices nothing for months. The incident usually only becomes apparent when Google marks the domain as dangerous, when the host forwards a complaint, or when a business partner calls because their antivirus has blocked the website.

The actual damage then isn't two days of downtime but weeks to months of trust and visibility loss – and an SEO reset that takes far longer to repair than it took to occur. Once you're removed from Google's index, you're not fighting for reach but for readmission.

The second assumption is more serious: The website is an isolated system. That's rarely true either. WordPress installations are typically connected:

  • to the CRM,
  • to the newsletter system,
  • to the mail server,
  • sometimes to inventory management,

often through shared credentials and on a server hosting other services.

A compromised website therefore isn't usually the target of an attack but its entry point. This is precisely the anatomy of most SMB ransomware incidents: Entry through a neglected web plugin, weeks of undetected presence in the network, finally encrypted business data and a ransom demand that retrospectively reorders the 'is it worth the effort?' calculation.

The numbers are clear: Exploited software vulnerabilities have been the most common entry vector for ransomware attacks for three consecutive years – responsible for 32 percent of all incidents worldwide (Sophos, State of Ransomware 2025, based on 3,400 affected organizations). And the Verizon Data Breach Investigations Report 2025 shows:

88 percent of all breaches recorded at SMBs involve ransomware – compared to 39 percent at large enterprises.

Mid-sized businesses aren't less at risk than large corporations; they're disproportionately at risk.

Then come the legal consequences that inevitably follow once personal data is affected – through a contact form, an application form, or newsletter registration:

  • GDPR reporting obligations within 72 hours,
  • notification obligations to affected parties,
  • possible regulatory proceedings,
  • in any case administrative burden from lawyers, data protection authorities, and external forensics.

Even if the financial damage remains manageable in individual cases, the organizational burden consumes weeks of work time – usually from people who can't fulfill their actual tasks during that period.

The question isn't whether a few days of downtime would be bearable. They would be. The question is whether a system compromised for months without detection, serving as a bridgehead into your own network, would also be bearable.

In most cases, the answer is: no. And the probability of this exact scenario occurring isn't zero – measured against current threat statistics, it's in the low single-digit percentage range per year, with rising tendency. Whoever calculates this risk against supposedly saved maintenance effort is calculating the wrong balance sheet.

Architecture Is a Strategic Decision

What remains is a simple but uncomfortable realization. Website security is usually treated in public perception as an operational question:

  • which plugins,
  • which updates,
  • which backups,
  • which security tool.

For many companies, this makes it essentially unsolvable because they lack the means to permanently meet these operational requirements.

But it's simultaneously an architectural question. And at this level, there is an answer that has been technically available for years but long wasn't accessible – and that becomes practical to the extent that AI-driven tools lower the barriers.

A website that essentially displays content doesn't need to run like an application.

And what doesn't need to run can't be attacked.

This isn't a new invention. It's a return to a principle that was standard a generation ago – and that has become nearly invisible in the CMS enthusiasm of the past twenty years.

For most small and medium-sized businesses, the question of whether a website really needs:

  • a database,
  • a scripting language,
  • and a plugin ecosystem

would probably be the most important digital decision of the coming years.

Not least because it doesn't solve the security problem by responding to it better – but by reducing the preconditions under which it arises in the first place. And in a threat landscape where the median to mass exploitation is five hours, and AI-driven attackers will further tighten this situation in the coming months, it might be the only decision that remains genuinely sustainable for many businesses.