What the PHP Security Crisis Teaches Us About AI Website Development

What happened in the October 2026 PHP security release?

On October 21, 2026, the PHP project released fixes for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Under certain conditions, they can allow unauthenticated remote code execution, meaning an attacker may be able to run code on an affected server without first signing in. The official PHP advisory identifies PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as fixed releases and directs users to their vendors for appropriate packages or backported fixes.

The UK National Cyber Security Centre’s guidance calls for organizations to identify PHP installations, including within third-party products, and apply relevant updates. That is an immediate operational task. A longer-term platform review should follow confirmation of the current environment’s status.

Being affected by a vulnerability does not establish that a particular website was compromised. The distinction matters when communicating with clients, customers and internal teams.

For more background, The Branded Agency’s explanation of the PHP vulnerabilities and their implications for WordPress covers the incident in greater depth. Here, I want to consider what businesses should expect from the people delivering their next website.

What does this have to do with AI-assisted website development?

The connection is more substantial than the fact that both subjects involve software. In its account of the security release, the PHP Foundation describes AI-assisted security research and using AI to help validate and group reports. It also explains the difficult engineering decisions involved in fixing deeply rooted problems while considering compatibility and performance.

The Foundation writes that “a person makes every call and works on every patch.” That observation is useful for anyone commissioning software. Tools can contribute to finding a problem or proposing a change; someone still needs to judge the result and accept responsibility for putting it into use.

My interpretation is that an agency’s value should include making those decisions understandable. A client should know what has been built, what has been checked, which questions remain open and who will act when something changes. The PHP account supports that discussion; it does not establish that AI wrote the vulnerable code.

Confidence needs evidence

A 2023 study by researchers affiliated with Stanford and UC San Diego examined 47 participants completing five security-related programming tasks. Participants with access to the AI assistant tested produced insecure solutions more often on four tasks and were more likely to believe their work was secure.

The limits belong beside the finding: the study used an older model, codex-davinci-002, and constrained tasks. Recruitment included students at two large US universities and professional programmers from four companies. It does not measure today’s coding agents or the security of production websites. Its relevance here is the need to distinguish confidence in a result from evidence that it meets the project’s requirements.

What should a business receive when its website goes live?

A useful handover should make the website understandable to the people who will operate it. I would organize it around six questions. The answers can be concise, but they need to name the people, accounts and documents involved.

These are proposed delivery expectations. NIST’s Secure Software Development Framework provides a broader basis for discussing secure development and supplier responsibilities. It treats security practices as work that belongs throughout the software lifecycle and gives purchasers a vocabulary for conversations with suppliers.

The level of detail should match the project. A small marketing website and a customer application with sensitive data will need different arrangements. In either case, “the agency handles it” should be translated into named responsibilities, a scope of work and a way to contact the right person.

Commercial ownership also deserves a clear answer. The agreement should explain what the client owns, what it licenses and what depends on a provider’s subscription. That gives the business a practical understanding of what can be transferred if its needs or suppliers change.

For an existing website, an assessment can help define what the next brief must preserve or improve. Our companion guide on what to audit before approving a website rebuild explores that planning stage. A public-facing brand or website audit serves a different purpose from an investigation of suspected compromise.

How should responsibilities be divided between the platform, agency and client?

The answer should be recorded for the actual project. A provider may manage parts of the infrastructure; an agency may maintain custom functionality; a client may control user accounts and content. Confirm the boundaries in the service documentation and agreement, then make the handoffs between those parties explicit.

I would start with the actions that matter to the business. For an enquiry website, that might mean publishing content, submitting a form, receiving the lead in the CRM and notifying the right person. Work backwards from those actions to identify the systems and owners involved.

A practical example: the enquiry that never reaches the CRM

Consider a hypothetical website built with AI assistance. It has a hosted front end, a custom form handler and a connection to the company’s CRM. A visitor sees a successful submission message, but the lead does not arrive because the CRM connection has expired.

A clear operating agreement would identify who monitors failed deliveries, who can renew the connection, where the relevant records are kept and who confirms that a test enquiry reaches the correct destination. The client’s marketing contact may confirm the business outcome while the developer verifies the integration.

The handover should make that sequence understandable before anyone has to reconstruct it under pressure. This example illustrates an operational responsibility; it is not a claim about a client result or the PHP vulnerabilities.

The cost of that ongoing work belongs in the buying decision. The Branded Agency’s guide to WordPress maintenance costs considers the operating commitment. Its Webflow and WordPress enterprise comparison provides a separate platform discussion once requirements are clear.

If Webflow is the right fit for the website, the project should still define who manages publishing permissions, custom code, connected services and recovery procedures. A migration also needs its own plan; our WordPress-to-Webflow migration guide addresses that implementation stage.

How can AI improve the work after the first build?

There are useful ways to apply AI beyond producing the initial pages. I would look for work where it helps a team make the system easier to understand and maintain, while keeping an appropriate review step.

Documentation: Draft explanations of components and integrations, then have the developer check them against the actual implementation.

Testing: Suggest cases for important journeys, including failures and unusual inputs. Run the relevant tests and inspect the results.

Change review: Help summarize a proposed change and the areas it may affect, so the reviewer can concentrate on consequential decisions.

Investigation: Assist with interpreting suitably redacted logs or reproducing an issue in a controlled environment, within the project’s approved access and data rules.

These are possible uses, not promises about a particular tool. Their value depends on the task, the information available and the quality of the checks around the output. The person approving a change should be able to explain what evidence supports that decision.

For a client, the useful record is straightforward: what changed, why it changed, what was checked, who approved it and how the previous state could be restored if needed. That record also helps the next person who works on the website.

This is where I see a meaningful opportunity for an AI-first agency. We can design the delivery process so that documentation, review and handover receive attention alongside the visible experience. The business should leave the project with a clearer understanding of the system it now depends on.

What should you ask your agency before approving the project?

I would bring these questions into the scoping conversation:

Which parts of this website will require ongoing work, and who will own each part?

What does your review process cover when AI is used, and how will the relevant results be recorded?

Which accounts and subscriptions will the business need to control directly?

What support is included after launch, and what requires a separate agreement?

How will you demonstrate that critical customer journeys work, including delivery to connected systems?

What documentation and access would another qualified team need to take over?

The answers should be specific enough to become part of the project scope. “Ongoing support” is useful only when both parties understand the services, contact arrangements and limits it describes.

My related Agency Review Guide article on the PHP security crisis and migration decisions provides another perspective for buyers considering a change. The decision here starts earlier: agreeing what a complete delivery will mean for your business.

I would judge an AI-assisted website project by the experience it creates and by how well the business can operate it afterwards. A clear handover makes future decisions easier, gives the next team useful context and puts responsibility where everyone can see it.

Planning a website or application? Start a conversation with Evil Villain about the experience you want to create and what your team will need to operate it after launch.