PHP issues affecting hospitality systems and why Taybl stayed online

If your booking system was unavailable this week, you may have heard that a security issue in PHP was responsible.

Two newly disclosed vulnerabilities, CVE-2026-109618 and CVE-2026-109619 — together widely referred to as “PHP2Shell” — prompted organisations around the world to patch systems urgently or temporarily take services offline. Hospitality platforms were among those affected. Third-party status reporting listed Collins, Tonic, Soda and DesignMyNight as unavailable, while a related Access service incident was explicitly labelled “PHP”.

Taybl remained available throughout. That was not because any software is immune from security vulnerabilities. It was because Taybl does not use PHP, so the affected component was not present anywhere in our application stack.

What happened?

PHP is a programming language used behind many websites and business applications. On 21 October 2026, fixes were released for two critical flaws in PHP’s handling of computer memory.

In simple terms, both vulnerabilities could allow an attacker to send a specially constructed request to a vulnerable server and, under the right conditions, run their own code without first logging in. That is known as unauthenticated remote code execution, and it is one of the most serious classes of software vulnerability.

The flaws were rated 9.2 out of 10 under CVSS v4.0. They affected supported PHP releases as well as older, end-of-life versions. UK National Cyber Security Centre guidance advised organisations to update immediately and to consider taking vulnerable services offline where fixes or temporary mitigations could not be applied quickly.

For a booking platform, that creates a difficult but necessary choice: continue operating while exposed to a critical risk, or temporarily withdraw the service while it is assessed and patched. Taking a service offline in those circumstances is a precaution, not evidence that it has been hacked.

Why systems such as Access Collins were disrupted

Public status reporting connected the temporary unavailability of some Access services with the PHP vulnerability, and third-party monitoring listed Collins among the unavailable products.

The important distinction is that there is no public evidence that Collins was compromised. The disruption appears to have been part of the response to the newly disclosed risk.

Nor would it be accurate to say that this incident only affected “old PHP”. The vulnerable code existed in the PHP runtime itself and affected current releases too. However, a large or long-established application can be harder to update at short notice. Older dependencies, tightly coupled components, custom hosting and limited automated testing can all make an emergency runtime upgrade slower and riskier. End-of-life PHP versions add another problem: they no longer receive normal upstream security releases and must be migrated to a supported branch.

That is the broader lesson from this incident. The age of a product alone does not decide whether it is secure. What matters is whether its architecture, dependencies and deployment process allow the team behind it to identify exposure, test a fix and release it safely at speed.

Why Taybl was not affected

Taybl is built on a modern TypeScript and Node.js stack, using Next.js and React, with PostgreSQL for data storage. PHP is not part of the platform, so CVE-2026-109618 and CVE-2026-109619 did not apply to Taybl.

That difference removed this particular risk, but the language choice is only part of the story. Taybl is a modern, actively maintained platform. Its architecture and development process are designed around frequent updates, automated checks and small, controlled deployments. That means dependencies can be kept current without waiting for a major rewrite or infrequent release window.

We should also be clear: using modern technology does not mean vulnerabilities can never arise. Node.js, Next.js and every other widely used technology require continual maintenance. Good security comes from knowing what you run, keeping it supported, monitoring new advisories and having a reliable way to test and deploy changes.

Modern software should be maintainable software

Hospitality operators rely on their booking system at the moments their venues are busiest. If it becomes unavailable, the impact is immediate: guests cannot book, teams lose visibility and revenue can be put at risk.

No responsible software provider can promise that a vulnerability will never be discovered. What providers can control is how much legacy complexity they carry, how closely they track their dependencies and how quickly they can respond when the wider technology landscape changes.

Taybl was unaffected by these PHP vulnerabilities because PHP is not in our stack. More importantly, we are building Taybl so it remains straightforward to maintain, update and secure as it grows.

That is what a modern hospitality platform should do: keep the technology current, keep the operational risk low and let venues concentrate on looking after their guests.