PHP security vulnerability: is your WordPress site affected?

Over the past two days "PHP" has been all over the news. In the Netherlands, DigiD, the login citizens use for government services, went offline. Some Finnish government sites were taken down as a precaution. In the US, the FBI and NSA told organisations to take their servers offline if they can't patch. In Turkey, the Presidency's Cyber Security Directorate launched a nationwide scan.

In this article we explain what happened without drowning you in technical detail. Then, step by step, we cover how a tour operator can tell whether their site is affected, what to do today, and how to be better prepared next time.

First, the basics: what is PHP?

PHP is a programming language that runs behind the scenes of websites. When a visitor opens your site, the code that builds the page, turns your contact form into an email or saves a booking to the database is very often written in PHP.

Even if you've never heard of it, you probably use it somewhere. WordPress, WooCommerce, Joomla, Drupal and many off-the-shelf booking plugins all run on PHP. According to the FBI, around 70% of websites worldwide use PHP.

What happened?

On 20–21 October 2026 the PHP team released emergency updates for two critical security flaws. They are tracked as CVE-2026-109618 and CVE-2026-109619 and together are known as "PHP2Shell". Both scored 9.2 out of 10 for severity.

Here's why it's serious: under certain conditions these flaws let an attacker run any code they want on your server, over the internet, without a username or password. In security terms this is called remote code execution (RCE). Put simply, someone can get through your front door without needing the key.

According to Qualys, one flaw comes from data being left half-finished when the server runs out of memory, and the other from freed memory being read again by the next visitor's request after an error. Researchers also showed that data such as passwords, session details and API keys could be leaked from server memory.

Anadolu Agency reports that the flaws were found in August by a security firm called Calif with the help of AI. Fixes were prepared quietly over about two months, but the news leaked to the press a day before the patches came out.

Why is this such a big deal?

• The scale is huge: Palo Alto Networks found more than 22.6 million internet-facing systems that are potentially vulnerable.
• Old versions are everywhere: Qualys data shows that 71% of PHP installs with a known version run releases that are no longer supported and don't get regular patches.
• Attacks have started: Cloudflare reported attack traffic targeting these flaws, and code that can be used to exploit them is already out there.
• Patching is slow: in the first 12 hours after disclosure, only about 199,000 of the 167 million installs Qualys tracks had been updated.

That's why governments took sites offline. Until a system is patched, the safest option is to close the door an attacker could walk through. In Turkey, the Cyber Security Directorate sent urgent notices to public institutions and urged private companies to check their PHP setups. It said no issues affecting services were found on e-Devlet, the national government portal.

What could this mean for a tour operator?

What an attacker can do once inside depends on what your site holds. The most likely scenarios:

• Customer data leaks: names, phone numbers, emails and passport details from booking forms. Depending on where you and your guests are, data protection rules such as GDPR may require you to report it.
• Stolen passwords and keys: your database password and the API keys for your payment provider, channel manager or email service.
• Harmful content on your site: hidden spam pages or code that redirects visitors elsewhere. If Google spots it, your site may show up with a warning and months of SEO work can suffer.
• Your server used for other things: crypto mining, sending spam or attacking other sites.
• Lost sales: if you have to take the site offline as a precaution, you can't take bookings, even in peak season.

Is your site affected? Check the version first

The first step is finding out whether your site runs on PHP and which version. On WordPress, go to Tools → Site Health → Info → Server in the admin panel to see the PHP version. Your hosting panel (cPanel, Plesk and so on) usually shows it under "PHP Version" too.

These are the versions that fix the flaws:

• On PHP 8.5: 8.5.12 or newer
• On PHP 8.4: 8.4.27 or newer
• On PHP 8.3: 8.3.36 or newer
• On PHP 8.2: 8.2.35 or newer
• On PHP 8.1 or older: there's no regular official update. Unless your host has applied a special patch, you need to move to a newer version.

One note: some Linux distributions ship the fix while keeping the old version number. So a lower number doesn't always mean your site is definitely vulnerable. That's why the most reliable step is to ask your hosting provider directly.

What to do today

• Email your hosting provider and ask: "Has the PHP on my server been updated against PHP2Shell (CVE-2026-109618 and CVE-2026-109619)?" "We added a firewall rule" on its own isn't enough. Make sure PHP itself has been updated.
• Know that a WordPress update won't fix this: the flaw isn't in WordPress but in the PHP running underneath it. Plugin or theme updates, security plugins and maintenance mode don't protect you, because the attack can run before WordPress even loads.
• If you run your own server (VPS): update the PHP packages, then restart PHP-FPM or Apache. A server that hasn't been restarted keeps running the old, vulnerable code. On Docker, pull the new image and recreate your containers.
• If you're on an old version: take a full backup stored off the server, then move to PHP 8.3 or 8.4. Afterwards, test the home page, tour pages, contact form and booking steps one by one.
• If you can't patch right away: putting the site behind a firewall such as Cloudflare gives you some temporary protection. If you have a technical team, they can apply PHP's recommended interim settings (for example session.upload_progress.enabled=0). These aren't a full fix, they only buy time.

Has someone already got in? Signs to check

Once you've patched, it's worth checking whether anyone got in before the gap was closed:

• Are there administrator accounts in WordPress that you don't recognise?
• Is there a plugin installed that you didn't install?
• Are there .php files in wp-content/uploads, the folder where your images live? There shouldn't be any PHP files there.
• When you search site:yourdomain.com on Google, do pages show up that you never wrote?
• Is there a warning under "Security issues" in Google Search Console?
• Has your host sent any warnings about malware, spam or unusual resource use?

If you spot any of these, ask your host to scan the server and restore a clean backup from before the suspicious activity. Then change every password and API key: WordPress, hosting, database, email, and payment or channel integrations. If customer data may have leaked, talk to a legal adviser about your obligations.

Looking ahead: lasting precautions

PHP2Shell won't be the last flaw. The real question is how prepared you'll be next time. The habits we recommend:

• Stay on a supported version: software that's out of support doesn't get patches. Today, PHP 8.3 or 8.4 is a good choice.
• Make someone responsible for updates: who updates your site, and how often? There should be a clear answer. Managed hosting or a maintenance agreement is an easy way to put this in writing.
• Know what you have: your main site, old campaign pages, test installs, forgotten subdomains… Keep a list of all of them, with the server and version each one runs on. Attackers love forgotten sites.
• Remove what you don't need: delete unused plugins, themes and old sites. Every extra piece is one more door a flaw could open.
• Put your site behind a firewall: a service like Cloudflare becomes your first line of defence when a new flaw is announced, until you can patch.
• Keep passwords and keys separate: don't write API keys into your code, give each service only the access it needs, and change keys regularly.
• Keep backups off the server and test restoring them: a backup you've never restored is a backup you can't be sure will work.
• Monitor your site: uptime checks, Search Console alerts and file-change warnings let you spot a problem before your guests do.
• Write a short incident plan: decide in advance who to call, how to take the site offline temporarily and how to tell customers if something goes wrong.

The bigger picture: flaws are being found faster

The most striking part of this story is that the flaws were found with the help of AI. The same tools are available to people with bad intentions. From now on, flaws will be found faster, and exploited faster too.

That means the days of "we'll update when we get round to it" are over. For a tour operator, a website is no longer just a shop window. It's a business tool that takes bookings and holds customer data, so keeping it secure is part of keeping your business running.

At Monotim we build sites on a modern setup that isn't directly affected by this kind of server-language flaw. But no technology stays safe forever. What really makes the difference is keeping an eye on the site and being able to act quickly when something goes wrong.

If you're not sure whether your site is affected by PHP2Shell, or your host hasn't given you a clear answer, we can take a look together.