Website & app security
PHP security update: what business website owners should check.
A website can look perfectly normal while the software behind it needs an urgent security update. The PHP vulnerabilities disclosed on 21 October 2026 are a reminder to check what runs your website, who maintains it and how problems are handled. Here is what business owners need to know, alongside practical examples of the precautions behind Zero Labs’ development work.
What happened on 21 October?
The PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. PHP is software that runs on a server to power websites and applications. The flaws can allow an attacker to run code without logging in. They were publicly disclosed and patched on 21 October; that is different from saying they were first discovered that day.
The initial fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The advisory covers PHP installations handling web requests and identifies Apache with mod_php as the highest risk. Hosting and operating-system suppliers may provide their own patched packages, so ask your provider to confirm the fix for your actual installation. Check the current advisory for subsequent updates.
Does my business website use PHP?
Ask your host or developer to check the website and any connected tools, including older installations and test environments. ENISA warns that products can include PHP behind the scenes even when that is not obvious to the owner. A page address without “.php” is not proof that the software is absent.
The useful answer identifies the affected services, their patch status and the person responsible. A reassuring screenshot of your homepage does not establish that the underlying software has been updated. Equally, this alert does not mean that every website has been compromised.
What should you ask your host today?
Send a focused request: “Please confirm whether our website or related services use PHP, whether the fixes for CVE-2026-109618 and CVE-2026-109619 are applied, and when this was verified. If anything remains exposed, please explain the immediate protection and update plan.” Keep their response with your website records.
The UK National Cyber Security Centre recommends identifying PHP systems, prioritising those exposed to the internet and applying the security update. If patching is delayed, follow the current vendor mitigation advice; the NCSC says to consider taking systems offline when those mitigations cannot be applied promptly. It also recommends assessing for signs of compromise where systems cannot be updated or disabled immediately, with specialist assistance when needed.
Once the provider has completed the update, agree checks for the customer journeys your business depends on: contact forms, bookings, logins or purchases. A patch confirmation and a working customer journey answer different questions. Record both, rather than assuming that a successful update proves everything still works.
How do we build precautions into a Zero Labs website?
At Zero Labs, the development decisions behind a website matter as much as its appearance. Our own website is a useful concrete example: its public pages are prepared as static documents, while the enquiry service runs separately. These pages can be served without running PHP for each visit. We choose the architecture around each project’s content, accounts and integrations.
The enquiry code checks incoming data on the server, sets limits on submitted content and treats submitted text as text when building notification emails. The email-provider credential is read from the server environment rather than placed in the browser code. That keeps the email service’s access details out of the public interface and puts validation where a visitor cannot simply switch it off in their browser.
OWASP’s development guidance supports checking data on the server and managing secrets separately from application source. Each layer has a job: form checks deal with submitted information, while software updates fix vulnerabilities in the underlying platform. Development experience shows up in these practical decisions, alongside the design a visitor sees.
What changes when you need a custom app?
A business website that explains services has different needs from a customer portal that stores private records. For an app brief, we start with the people using it, the information involved and the actions each person should be allowed to take. The useful questions come before selecting a framework: does this need an account, what data must it retain, and which external systems must it reach?
Consider a hypothetical booking portal. A customer should only see their own appointments; a staff account may need a wider view. Hiding a button in the interface would not enforce that distinction. The server needs to check whether the signed-in person is allowed to perform the requested action. Access checks, integration permissions and failure behaviour belong in the development scope and acceptance checks.
Our custom application service covers workflow planning, integrations, testing and launch support. Any ongoing maintenance or monitoring needs a clear agreement: which parts the host manages, which parts need developer updates, who receives alerts and how support is arranged. A launch should leave the owner with understandable responsibilities.
Should a PHP alert make you rebuild your website?
Begin with the urgent patch decision. A rebuild is a separate business decision and should not delay fixing an exposed installation. Ask whether the current platform can be maintained reliably, whether essential features still work and whether the support arrangement is clear.
A focused improvement may be enough when the platform remains suitable. A wider redesign becomes a more useful conversation when the existing system cannot be maintained sensibly, relies on abandoned components or no longer meets the business’s needs. The proposal should explain those findings and the future maintenance responsibilities, rather than presenting a new technology as a guarantee of security.
Five questions to take into your next website brief
1. What software and hosted services will the website depend on, and who keeps each part updated?
2. What customer information will it collect, and who should be able to access it?
3. How will forms, account permissions and external integrations be checked before launch?
4. What is the backup and recovery arrangement, and how will we know a restore works?
5. Who should we contact about a security alert, and what maintenance is included after handover?
For businesses in Stoke-on-Trent, Staffordshire and Cheshire, these are useful questions whether you are commissioning a first website or improving an established one. Zero Labs is based in Stoke-on-Trent and works remotely across the UK. Share your current website or app idea and we can discuss a development scope that covers the practical details behind the design.
Take the next step.
Explore the related services and guides to plan your next step.