UK accommodation operators · Website security
PHP security warning: check your holiday let booking website
A booking page can keep working while its server software needs a security fix. After the NCSC’s 21 October PHP warning, ask the people running your website and booking system to confirm the fix, then check the guest journey.
Ask the host to confirm the fix in the running website.
Check whether the warning reaches your website
The National Cyber Security Centre warning published on 21 October urges urgent mitigation for CVE-2026-109618 and CVE-2026-109619. Fixes are already available. The official PHP advisory identifies patched upstream versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
PHP is software used to run websites, including WordPress. If you operate your own accommodation website, ask whether it uses PHP and whether the warning applies to the service that guests reach. A page can continue showing photographs, prices and dates while an underlying security issue remains unresolved. Its appearance is not a useful patch check.
This warning does not establish that your website has been compromised. It gives you a reason to obtain a clear answer from the provider responsible for the software, rather than assume that a familiar website needs no attention.
Find the people responsible for both services
The person who designed the website may not run its hosting. Check the hosting account or support agreement and establish who can maintain the server software. Ask that provider to assess the warning against your actual site. A designer can help make the introduction, but a forwarded message is not confirmation that the work is complete.
Your booking engine may run on another company’s service, even when it appears inside your own website. Ask that provider separately whether its part of the booking journey is affected and what action it has taken. If one company runs both, ask it to confirm both responsibilities.
Our direct booking guide explains how a website, availability and checkout need to work together. Apply the same thinking here. Know who maintains each service before deciding that an answer about the main website covers the booking system too.
Ask what is running, not what is available
Ask the host to confirm that both vulnerabilities are fixed in the web service actually running your site, with the package identifier and time the fix took effect. An available update or a download announcement does not establish that your service is using it. Keep the answer with the provider’s support reference.
Distributions and long term support vendors may backport a fix into a package with a different identifier. The host should explain that evidence rather than leave you to judge it from an upstream version number alone. You do not necessarily need to move every site to the newest PHP branch. PHP 8.1 and older lack normal upstream support, and a vendor backport does not restore that support.
In WordPress, Tools > Site Health > Info > Server can help identify the runtime version to ask about. It is not a vulnerability audit or proof that a vendor build contains this fix. A generic recommendation for PHP 8.3 or higher is insufficient for this particular warning.
Arrange the fix with a usable recovery plan
Ask the provider to explain its backup and recovery arrangements and check compatibility with the website and booking integration. WordPress’s PHP update guidance supports involving the host, keeping a backup and considering compatibility. Use the current PHP advisory for this incident’s fixes rather than treating generic version guidance as a security confirmation.
WordPress core, plugin and theme updates are separate from the hosting runtime. Ask who handles each part, but do not assume that updating a plugin has patched PHP. Equally, a runtime fix does not settle every other maintenance issue. Agree the work and an appropriate recovery route with the people who can carry it out.
Keep existing guest bookings and real availability intact. Any recovery needs to account for bookings received since a backup was taken. Avoid replacing current reservation records with an older copy just to make a website work again.
Check the guest journey through the agreed route
After the provider confirms the work, use its sanctioned test method to check the website and booking connection. Start with the property page, then follow date selection, guest numbers, the total price and the route towards checkout. Check on a phone as well as a larger screen. A loading homepage tells you little about the steps that follow.
Agree any payment or reservation test with the provider first. Use its supported test environment or test mode where available. Do not create a real reservation or trigger a surprise charge to see what happens. Ask how the confirmation and availability changes can be checked safely, keeping live dates available to genuine guests.
Use the blank record to retain the provider’s confirmation, the agreed booking check and anything unresolved. Keep guest names, contact details and booking references out of public scanners or unfamiliar tools. Those details are not needed to ask whether a hosting package has been fixed.
Get a clear response when the fix is uncertain
PHP says temporary mitigations are incomplete. NCSC advises considering taking a system offline if it cannot be patched or mitigated. Ask the host to handle that technical assessment and explain the next action and timing. Do not try unfamiliar server settings to keep an uncertain service open.
If a booking route has to pause, agree how guests can contact the business and how existing bookings will continue to be handled. Use an established contact route. Avoid moving guest records or payment collection into a new tool as an improvised replacement.
A patch confirmation does not establish that no compromise occurred. If the provider identifies suspicious activity or you have other reason to suspect an incident, obtain competent incident response help and preserve relevant records.