PHP Security Vulnerabilities: What UK Businesses Need to Know

Start with the software, not the headline

A website can look simple while relying on several layers of software. The browser displays a page, but a web server may first run application code, retrieve information from a database and assemble the response. PHP is one language used for that server-side work. It can power a complete content management system or a small function such as an enquiry handler.

That distinction matters when a security warning arrives. “Our website is not WordPress” does not establish that PHP is absent. Equally, having WordPress does not establish that a website has been compromised. The useful questions concern the actual runtime, the provider’s patch status and the parts of the service exposed to requests. Business owners need a clear answer from the people managing those systems, rather than a judgement based on the logo on the administration screen.

What the October 2026 notices confirm

Checked on 28 October 2026, the UK NCSC notice identifies CVE-2026-109618 and CVE-2026-109619 as PHP memory-handling issues that can permit unauthenticated remote code execution under certain conditions. One concerns cleanup after an out-of-memory condition; the other concerns internal state remaining after memory has been freed. These are runtime issues, not proof that every hosted application was attacked.

The PHP announcement of 21 October lists fixes in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Its subsequent notices cover a specific session-upload configuration and updated Windows packages. A host must assess the installed branch, vendor patches and applicable follow-up guidance. This dated summary is not a substitute for the current advisory or confirmation from your provider.

Why a version number is only the starting point

A control panel may show a broad PHP version without identifying the exact package installed. Some hosting environments also obtain security fixes through their operating-system or long-term-support vendor. Ask the provider to confirm remediation for the named vulnerabilities, including any relevant backported patches. Do not assume a successful application update proves that the underlying runtime was updated too.

The practical output should be an attributable answer: which service was checked, who is responsible, whether remediation is complete and what remains outstanding. If someone recommends a temporary measure, ask how it relates to the official guidance and when the complete fix will be applied. Avoid copying isolated configuration changes from a social post. Settings can interact with the application and the wider hosting environment; the administrator should test the agreed change and confirm its effect.

WordPress, Drupal, Joomla and custom PHP

WordPress, Drupal and Joomla can all be deployed on PHP-based infrastructure, while bespoke applications may use PHP without a public CMS interface. Their application code, extensions, permissions and hosting arrangements differ. Those differences matter for application security, but a runtime vulnerability can sit beneath them. Exposure cannot be assessed simply by counting plugins or checking whether a login page is visible.

A WordPress maintenance service might handle core and plugin updates while a separate host manages PHP. A custom application may have a developer responsible for its code but nobody explicitly assigned to server upgrades. A CMS with very few extensions still needs maintained infrastructure. Ask for responsibilities across both layers, then confirm that the people involved have coordinated their work. This avoids the common gap where each supplier believes the other has completed the update.

Updates should be a routine, not a rescue exercise

Security maintenance is easier when there is an inventory and a documented process before an urgent notice appears. Know who hosts the website, who can change runtime versions, which applications or handlers exist and where backups are kept. Record the contact route for urgent support without storing passwords in a shared article or email thread.

A maintenance arrangement should distinguish routine updates from emergency changes. It should explain testing, rollback, communication and completion checks. A successful deployment needs more than an update notification: essential journeys should still work afterwards. For a service business that can mean checking its main pages, navigation and enquiry delivery. The extent of testing depends on the site, but a clear owner prevents a technically completed patch leaving an unnoticed functional problem behind.

Backups and incident response have different jobs

A backup supports recovery; it does not establish that a live site is secure. Its usefulness depends on what is included, whether the copy is protected and whether restoration has been tested. A database backup alone may not contain uploaded files or server configuration. A folder copied onto the same account may share the same access risks as the website itself.

If compromise is suspected, tell the hosting provider or incident specialist promptly. Preserve relevant information and follow their advice about logs, access and recovery. Restoring a backup without addressing the cause can recreate the vulnerable condition. This article is awareness guidance, not an incident-response procedure. The appropriate action depends on the deployment and the evidence available, including whether other services share the account or infrastructure.

What static-first actually changes

A static-first service website can deliver ordinary public content as prepared HTML. It may not need a database, a theme engine or an extension system to explain a company’s services. Removing components that are not required can reduce the number of application dependencies to administer. It can also make the delivery path easier to understand when reviewing performance or troubleshooting a page.

That is an architectural advantage only where it fits the requirements. It does not remove the web server, the hosting account, domain management or every dynamic feature. A booking integration, analytics script or contact handler still needs attention. Our bespoke HTML versus WordPress page explains the wider trade-offs, including publishing arrangements. Changing architecture should follow a requirements review rather than be sold as a universal reaction to one advisory.

Why static HTML is not a security guarantee

An attacker does not need a CMS to cause damage. Stolen hosting credentials can permit file changes. An unsafe third-party script can affect visitors. A vulnerable form handler can expose a server-side path even when the surrounding page is static. Misconfigured access, forgotten test folders and poorly managed accounts can also undermine an otherwise careful build.

The right aim is a manageable set of dependencies with appropriate protection, not the claim that a technology is immune. Agree access controls and account ownership, review unused services and define how updates are requested. If a supplier says a static website needs no maintenance at all, ask which responsibilities they are excluding. Content accuracy, external links, certificates, hosting software and form behaviour can change after launch even when the HTML files remain identical.

Our contact forms still require maintained software

TradeWorks uses static public content where suitable and server-side functionality where it is needed. A contact form is a useful example: the page can be HTML while a PHP handler validates the request and arranges delivery. The handler, its mail library and its runtime remain part of the website’s maintenance responsibilities. Calling the overall site static-first does not exempt them from PHP guidance.

Form protection is also broader than a spam challenge. Input handling, response behaviour, operational limits and mail configuration deserve review. A successful on-screen message should be supported by a working delivery path. We preserve and test agreed functionality when planning a rebuild, rather than assume that replacing the visible design has resolved the technical work. Our website development service includes those conversations when defining the scope.

Questions worth sending to your host

• Which PHP installations serve this website and any associated test sites?
• Have the October advisories and subsequent applicable notices been assessed?
• Which patched package or supported branch is installed, and when was remediation completed?
• Who maintains application code, extensions and server software?
• Were essential forms and integrations checked after the change?
• What should we do if suspicious activity or a delivery problem appears?

Keep the reply with your maintenance records. The aim is not to demand a particular brand of hosting or prescribe an unfamiliar server setting. It is to obtain a specific, understandable account of what has been checked. A provider should be able to distinguish a completed update from a change still awaiting testing or confirmation.

A practical example: a small service company

Consider a drainage business with service pages, a small project gallery and one enquiry form. It does not publish daily and has no customer login. Its current site might be improved through better maintenance and a leaner theme. Alternatively, a planned static-first rebuild could remove CMS components it no longer needs. The decision depends on editing arrangements, the existing content and the cost of maintaining either option.

Now consider a care organisation with several contributors updating detailed information. Independent publishing and approval workflows may be central requirements. Removing the CMS without a suitable replacement could create operational problems. Security is one factor in either review, but the sensible recommendation joins security responsibilities with how the business actually works. The strongest proposal explains what will change, what will remain and who will look after each part.

What to record after an update

Ask for a short completion note rather than a collection of screenshots that nobody can interpret later. It can identify the affected website, the change made, the person responsible and the checks completed. If an exception remains, it should have an owner and a next action. Recording that information makes the next maintenance conversation easier and prevents an old support message being mistaken for evidence about the current deployment.

Keep records proportionate. A small website does not need an elaborate governance platform to document its hosting arrangements and essential functions. It does need a reliable place for the information and a way to reach the responsible people. Review the record when suppliers change, the website is rebuilt or a new integration is introduced. The maintenance boundary should evolve with the website rather than remain frozen in the original proposal.

Include forgotten test sites in the conversation

A live website may not be the only installation on an account. An old mobile site, staging folder or abandoned demonstration can still depend on server software even when it receives little attention. Ask which environments are in scope for maintenance and whether unused copies can be retired through a controlled process. Avoid deleting files simply because their purpose is unclear; establish ownership, backups and any remaining redirects first.

Choose a reasoned next step

If you are unsure what your website runs on, start with an inventory and a conversation with your host. If the existing site meets your needs, maintenance improvements may be enough. If unnecessary complexity is making every change expensive or unreliable, a wider review can establish whether a different foundation is justified.

TradeWorks can review the public experience, the documented requirements and the agreed technical scope before recommending optimisation or a rebuild. We do not assume all WordPress sites need replacing, and we do not treat an advisory as proof of compromise. Request a website review to discuss the sensible options for your business. Leave passwords and sensitive information out of the initial enquiry; any further access should be arranged through an appropriate process.