The latest PHP security crisis presents an uncomfortable question for anyone responsible for a website: if a site exists primarily to serve one organization, one business, or one publisher, why should its owners continue to depend on a general-purpose content management system when maintaining that system may cost more than building and operating something simpler?
On October 21, 2026, the PHP development team released security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both could permit unauthenticated remote code execution on affected systems. Government cybersecurity agencies and technology providers urged administrators to identify affected PHP installations and apply the available fixes promptly. The risk is especially serious for certain Apache configurations, where exploitation can occur before application-level code executes. These are vulnerabilities in PHP itself, not simply defects in WordPress or Drupal. See the official PHP security release archive and the Canadian Centre for Cyber Security advisory.
This distinction matters. Neither WordPress nor Drupal created these vulnerabilities, and moving to another application framework would not eliminate the possibility of critical security defects. Nevertheless, the incident exposes a larger architectural question: whether the convenience of a mature CMS still outweighs the cost of its dependencies, extensions, maintenance requirements, and security exposure for every category of website.
The answer is not that everyone should abandon PHP. It is that the economics of web development have changed enough to justify reconsidering the default choice.
The problem with treating a CMS as the default
WordPress and Drupal solve genuine problems. They provide established publishing workflows, administrative interfaces, access controls, extensibility, and ecosystems of developers and third-party components. For organizations with multiple editors, complicated publishing requirements, established integrations, and large collections of existing content, these capabilities can represent substantial savings.
The difficulty begins when the same architecture is adopted for a much simpler purpose.
A personal website, company information site, technical publication, or small business website might need only a handful of content types, a contact form, search, and an administrative mechanism for publishing updates. Installing a general-purpose CMS introduces capabilities that may never be used, but the software still has to be updated, monitored, configured, and defended.
The security implications extend beyond the CMS's own source code. A typical installation depends on an operating system, a web server, PHP, a database, the CMS core, themes, plugins, and sometimes additional services. Each component has its own maintenance schedule and failure modes.
The recent PHP vulnerabilities illustrate the consequences of this dependency structure. A defect in the underlying runtime can affect otherwise unrelated applications simultaneously. A carefully written WordPress installation and a carefully written Drupal installation may both be exposed because they share the same vulnerable execution environment.
The joint statement from European cybersecurity authorities advised organizations to identify PHP-based applications, coordinate with hosting and service providers, and apply the released security updates, prioritizing internet-facing systems. Where remediation is not feasible, temporarily isolating exposed systems may be necessary.
That is sensible incident response. It is not, however, a complete answer to the architectural question. A site owner must also ask why the system requires this particular collection of dependencies in the first place.
Custom development and institutional knowledge
One argument for established CMS platforms is that their code has been examined by large communities, maintained by experienced developers, and deployed across millions of websites. This is a meaningful advantage. A widely used platform can benefit from extensive testing, rapid vulnerability reporting, and established remediation procedures.
Custom development does not automatically offer better security. A developer who writes a replacement CMS without sufficient experience may introduce authentication flaws, insecure database queries, inadequate input validation, or an unreliable update process. Reimplementing mature functionality unnecessarily can make a system less secure rather than more secure.
But there is another consideration: institutional knowledge.
A custom application designed for a single site can be built around a clearly defined set of requirements. Its owner can know precisely which routes exist, which database tables matter, which services are exposed, which permissions are required, and which components are necessary for operation. If the application has a narrow scope, the amount of software that must be understood can be substantially smaller than that of a general-purpose CMS installation.
This knowledge is particularly valuable during an incident. When a security advisory appears, the operator can identify whether the affected component exists, whether it is reachable, and what operational consequences an update might have. When a patch is required, a smaller and better-understood application may be easier to test and redeploy.
There is an important qualification: the likelihood of superior institutional knowledge is not determined by whether software is custom-built. It depends on whether someone actually documents, understands, and maintains it. A bespoke application abandoned by its original developer can become an opaque liability. Conversely, a professionally managed CMS with a tested update process can be exceptionally well understood.
The meaningful comparison is therefore not custom code versus community code. It is a deliberately limited system with accountable ownership versus a system whose complexity exceeds the owner's capacity to maintain it.
For a single-site project, the former is increasingly attainable.
AI changes the cost of building a website
Historically, the strongest argument against custom development for a small website was economic. Even a relatively simple application required developers to implement administrative functions, content storage, authentication, validation, templates, and supporting infrastructure. The initial expense could easily exceed the cost of adopting an established CMS.
AI-assisted development changes this calculation.
A competent developer can now use AI tools to accelerate routine implementation, generate tests, document interfaces, scaffold database operations, and identify potential defects. Tasks that once consumed a substantial portion of a small project's budget can require considerably less manual effort.
The important word is competent. AI-generated software still requires architectural decisions, testing, security review, and ongoing maintenance. Models can generate plausible but incorrect code, overlook edge cases, and introduce subtle security weaknesses. A large codebase generated quickly is not necessarily a maintainable one.
The greatest opportunity lies in constrained applications. If the requirements are explicit and the scope is small, AI can help implement a deliberately limited system without reproducing every feature of a general-purpose CMS.
For example, a technical publication might require a content editor, article storage, category management, image uploads, and a publishing workflow. Instead of installing a large platform and removing unnecessary functionality, its owner could implement precisely those features using a different language, framework, or static-site architecture.
The resulting application might have fewer dependencies, a smaller administrative attack surface, and less code to maintain. It might also have a more predictable deployment process.
However, the choice of language alone does not guarantee any of these benefits. A poorly designed application in Go, Python, JavaScript, or another language can be just as vulnerable to application-level mistakes. Every runtime and framework has its own security advisories and upgrade requirements.
AI makes custom development more economically plausible; it does not make secure development automatic.
Comparing the real costs
The decision should be based on total cost of ownership rather than the price of initial development.
Three costs deserve particular attention: the expected cost of compromise, the cost of maintaining the existing system, and the cost of replacing it.
1. The proportional cost of a compromise
A successful compromise can cost far more than the affected software's replacement value. Expenses may include incident investigation, restoration, lost revenue, emergency consultancy, recovery of corrupted data, customer notification, and reputational damage. In some circumstances, legal and regulatory obligations add further costs.
For a personal website, a compromise might be limited to spam pages, malicious redirects, or a temporary outage. For a business application, the same initial intrusion could expose customer information, compromise credentials, or provide a foothold for attacks against other systems.
The consequences depend on the site's purpose, its privileges, the data it stores, the isolation of its infrastructure, and the attacker's objectives. A PHP vulnerability does not imply that every affected website will be compromised, and a vulnerability's severity score is not a prediction of the financial loss associated with exploitation.
Nevertheless, unauthenticated remote code execution is a serious risk because it can give an attacker a route to execute commands without first obtaining legitimate application credentials.
The appropriate financial model is expected loss: the probability of a damaging incident multiplied by its potential cost, considered alongside the effectiveness of preventive and recovery controls. Neither the probability nor the financial impact can be established from the vulnerability announcement alone.
2. The cost of patching
Patching is often the least expensive option, particularly when the hosting provider manages the runtime and the application uses supported software.
An administrator might need to update PHP, restart relevant services, verify the installed version, test the site, and inspect logs. A well-maintained installation with automated deployment and a staging environment could require little more than a routine maintenance window.
Other installations are substantially harder to update. They may depend on abandoned plugins, unsupported PHP versions, obsolete operating systems, custom modifications, or themes that break when dependencies change. An update that takes minutes on one server can require hours of testing and troubleshooting on another.
The direct price of a patch therefore understates its operational cost. Someone must identify the affected systems, obtain the update, verify compatibility, deploy it, and confirm that the service still works.
The October 2026 incident also highlights the distinction between application maintenance and runtime maintenance. Updating WordPress or Drupal does not necessarily update the PHP interpreter underneath it. Equally, installing a patched PHP package does not establish that the website has no other vulnerabilities.
A functioning maintenance process must cover both layers.
3. The cost of replacement
Rebuilding a site using a different language or AI-assisted development is not free. Existing content must be migrated, URLs preserved, integrations recreated, authentication tested, and operational procedures established. A replacement may also need features that its owner initially overlooked.
For a complex Drupal deployment with extensive editorial permissions, workflows, and integrations, replacement could be an expensive and risky undertaking. For a modest site with a few content types and little interactive functionality, it might be straightforward.
This is where AI-assisted development has the potential to change the proportional cost. If a replacement that once required several weeks of implementation can be produced in days, the financial case for retaining an unnecessarily complicated system weakens.
But initial implementation is only one part of the calculation. A replacement must be maintained throughout its lifetime. The relevant question is whether the new system reduces the combined cost of development, routine maintenance, security remediation, and eventual migration.
A new application that saves a few hours during development but requires specialized expertise for every future update may simply exchange one form of technical debt for another.
An illustrative cost comparison
Consider a small, independently operated website. The following figures are hypothetical planning estimates, not industry averages or quotations. They illustrate how different decisions can produce different economic outcomes.
Assume that an existing CMS installation requires several hours of routine maintenance annually, while a constrained replacement requires more initial work but less recurring maintenance. Actual costs will vary considerably with local labor rates, application complexity, and the owner's technical expertise.
OptionInitial or immediate effortOngoing burdenPrincipal risk Patch an existing, healthy CMS2–8 hoursRegular updates and compatibility checksContinued dependency exposure Repair a fragile or outdated CMS1–5+ working daysPotentially high troubleshooting costLegacy dependencies Replace with a constrained custom site3–15+ working daysFramework, runtime, and application maintenanceImplementation defects Rebuild using AI-assisted developmentPotentially fewer implementation hoursIndependent testing and ongoing maintenance remain necessaryIncorrect generated code and overlooked requirementsThese ranges are deliberately broad. They are not predictions for every site, and the AI-assisted option is not a separate security category: AI can accelerate either CMS customization or custom application development.
The financial comparison becomes more useful when labor costs are assigned to these scenarios. At an illustrative rate of $75 per hour, an eight-hour maintenance event costs $600 in labor, while 40 hours of rebuilding costs $3,000. A replacement requiring 120 hours costs $9,000 before any additional infrastructure, migration, or contingency expenses.
Those amounts are not inherently large or small. Their significance depends on the site's expected remaining lifetime, the cost of maintaining the existing installation, and the consequences of a compromise.
A one-time rebuild may be justified if it eliminates recurring expenses and reduces operational complexity over several years. It is unlikely to be justified solely because a critical vulnerability has appeared in a runtime that can be patched promptly.
The distinction is between an immediate incident response and a long-term architectural decision. Confusing the two can lead to expensive migrations that deliver little additional security.
Why abandoning PHP is not the immediate answer
There is a temptation to interpret the latest vulnerabilities as evidence that PHP itself should be abandoned. That conclusion goes further than the evidence supports.
The defects are serious, and the fact that vulnerabilities exist in the runtime rather than a particular CMS makes them relevant to a broad range of PHP applications. But a critical defect in one widely deployed runtime does not establish that other languages are categorically safer.
Alternative runtimes can also have vulnerabilities that permit remote code execution, memory disclosure, or privilege escalation. Their ecosystems may have different maintenance practices, deployment models, and exposure profiles, but none is immune to defects.
Nor does moving away from PHP eliminate the need for patch management. A custom application still depends on its operating system, libraries, database, web server, and deployment infrastructure. A static site can substantially reduce the exposed server-side application surface, but its hosting account, build pipeline, dependencies, and administrative credentials still require protection.
The stronger argument for changing technologies is not that another language cannot fail. It is that the replacement can be designed to expose fewer services, run less code, require fewer privileges, and depend on fewer independently maintained components.
That is a defensible architectural objective, irrespective of the chosen language.
What WordPress and Drupal operators should do now
The immediate response to the October 21 PHP disclosures should be practical, not ideological.
First, identify every internet-facing PHP installation, including runtimes embedded in containers, control panels, appliances, and hosting products. Confirm the installed version rather than assuming the hosting provider has already applied the fix.
Second, install the appropriate vendor-supported security update. The PHP release announcement lists patched versions including 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Administrators using distribution packages should verify the relevant vendor's advisory and package status. Unsupported versions require particular attention because the upstream project may no longer provide routine fixes. See the PHP security release archive and the Ubuntu security notice.
Third, where immediate remediation is impossible, assess whether the application should be isolated from public access until it can be updated. This may be disruptive, but leaving a potentially exploitable system exposed is not a neutral decision.
Fourth, investigate whether the site has already been compromised. Updating the runtime closes the known vulnerability; it does not remove an attacker's persistence mechanisms or reverse damage that may already have occurred. Relevant logs, unexpected processes, modified files, new accounts, and suspicious outbound connections deserve attention. The Canadian Centre for Cyber Security advisory provides further remediation guidance.
Finally, use the incident to evaluate the existing architecture. If the installation is difficult to patch because of obsolete extensions or undocumented modifications, that is evidence of a maintenance problem worth addressing regardless of whether the current vulnerability is successfully exploited.
The case for a different default
WordPress and Drupal remain reasonable choices when their capabilities justify their complexity. A publishing organization with multiple contributors, complex editorial workflows, and substantial integration requirements may be better served by an established CMS than by a custom replacement.
The situation is different for a single-site project whose needs are modest and well understood. Such a site may not need a general-purpose CMS at all. A static-site generator, a narrowly scoped custom application, or a lightweight publishing system could offer a better balance of functionality, operational simplicity, and long-term maintainability.
AI-assisted development strengthens that case by lowering some of the labor costs that previously made custom implementations unattractive. It does not remove the requirement for engineering judgment, testing, documentation, and ongoing support.
The decisive issue is therefore not whether PHP is dangerous or whether WordPress and Drupal have outlived their usefulness. It is whether the capabilities provided by a particular platform are worth the cost and risk of maintaining its full dependency chain.
For many existing installations, the correct response to the current crisis is simply to patch, verify, and continue operating. For a site already burdened by abandoned extensions, excessive complexity, and fragile upgrades, the same incident may be a useful reason to reconsider the architecture.
The web does not need to replace every established CMS. It does need to stop treating the CMS as the automatic answer to every publishing problem.
The better default is to choose the smallest system that satisfies the actual requirements, can be understood by the people responsible for it, and can be maintained reliably over its expected lifetime. Sometimes that will be WordPress or Drupal. Increasingly, particularly for single-site projects, it may be something much smaller.
Sources and further reading
PHP: Official release archive and security updates — upstream release information and fixed PHP versions.
European Union Agency for Cybersecurity (ENISA): Joint statement on critical PHP vulnerabilities — response recommendations published October 21, 2026.
Canadian Centre for Cyber Security: Critical vulnerabilities impacting PHP, CVE-2026-109618 and CVE-2026-109619 — affected versions, remediation, and monitoring guidance.
Ubuntu Security Notice USN-8948-1: PHP vulnerabilities — distribution-specific security information.
Google Cloud: Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 — vulnerability background and deployment guidance.
Note on estimates: The labor-hour and dollar figures in the cost comparison are illustrative assumptions for scenario analysis, not measured industry averages. The article's architectural recommendations are analysis, not claims that custom-developed applications are inherently more secure.
All articles