Does Your Website Run on PHP? Two Critical Flaws Need Fixing This Week

Two critical flaws in PHP, disclosed on 21 October 2026, let an attacker run their own code on a web server without logging in. The PHP project released emergency security updates the same day, and the US Cybersecurity and Infrastructure Security Agency (CISA) published an alert, Critical Vulnerabilities in PHP Require Immediate Patching, which it updated on 23 October.

PHP runs WordPress, WooCommerce, Laravel, Drupal, Magento and a great many custom business applications, including the APIs behind mobile apps. If your website, online store, customer portal or app backend is one of them, this article explains what the flaws are, what they could mean for your business, and the three things to do this week.

What happened, in plain terms

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619 and are known as php2shell. Both allow unauthenticated remote code execution. In business terms: an attacker sends a specially prepared web request to your site and can then run their own code on your server. They do not need a login, a stolen password or a member of staff to click a link.

A few details decide how seriously to take this.

• The flaws are in PHP, not in your application. WordPress, its plugins and your Laravel code can all be fully up to date and the site is still exposed, because the problem sits in the engine underneath. The PHP project's advisory notes that on Apache with mod_php, an unauthenticated request can trigger the attack before any application code runs, so login screens and security plugins never get a say.
• They are rated critical. Both carry a CVSS v4.0 score of 9.2 out of 10.
• They affect every common way of serving PHP. CISA lists all PHP installations serving web requests, including Apache with mod_php (which PHP considers the highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. Between them, those cover shared hosting, cPanel and Plesk servers, VPSs and cloud servers.

Is anyone exploiting it?

When CISA published its alert, it had not observed successful exploitation of these flaws. Since then, several security firms have reported attempts to exploit them against servers on the internet. An attempt is not a break-in, and there is no reason to assume your site has been compromised. But the attempts show where this is heading.

Attacks of this kind are automated. Nobody picks your company by name; programs scan the whole internet for servers that look like an unpatched PHP installation and try the exploit on every one they find. A ten-page website for a clinic in Nagpur is found by the same scan as a national retailer's store. Size and obscurity are no protection, and the gap between a flaw being published and the scanning starting is now measured in hours, not weeks.

What it could mean for your business

Running code on a web server is close to owning it. What an attacker does next depends on what the server holds and what it can reach, but these are the usual outcomes after flaws of this type.

• Customer and business data. The database holding customer names, phone numbers, addresses, orders, patient or student records can be copied. The configuration files on the same server, such as WordPress's wp-config.php or a Laravel .env file, usually hold the database password and the keys for payment gateways, SMS, email and cloud storage, which opens doors well beyond the website.
• Money. On an online store, the checkout page can be altered to capture card details or redirect payments. Invoices and payment links sent from a compromised portal can carry someone else's bank details.
• Reputation and search. Hidden spam pages, redirects to scam sites and malware warnings in Google and the browser can follow, and your email domain can be blocklisted if the server is used to send spam. Search rankings take far longer to recover than to lose.
• Operations. Files can be encrypted for ransom, along with any backups kept on the same server. The server can be quietly used for cryptocurrency mining, or recruited into a botnet that attacks others from your IP address.
• Legal duties. In India, CERT-In's directions require cyber incidents such as unauthorised access to systems to be reported within six hours of noticing them, and the Digital Personal Data Protection Act, 2023 requires personal data breaches to be reported to the Data Protection Board and to the people affected. Our security checklist for software vendors covers those duties in more detail.

Cleaning up after any of these costs many times what an update costs, in money, staff time and customer trust. That is the whole case for acting this week rather than next quarter.

Why many owners do not know they are exposed

Most business owners can tell you which WordPress theme or which developer built their site. Very few can tell you which PHP version it runs on, and there are good reasons for that.

• The PHP version is a server setting, chosen when the site was first built and rarely revisited.
• Updating WordPress, plugins or the application's code does not change it.
• The developer or agency who built the site may have moved on, and the hosting account may be in their name rather than yours.
• Managed hosts often apply PHP updates automatically. Budget shared plans and self-managed VPSs often do not.
• Old versions are still common because moving to a new major version can break old themes, plugins or custom code, so the upgrade kept getting postponed.

Three steps for this week

1. Find out which PHP version your site runs

Ask your developer or hosting provider for the exact version that serves your website, including the last number: "8.3.36", not just "8.3". You can send them this:

Which exact PHP version serves our website and any other web applications on our server? Does it include the fixes for CVE-2026-109618 and CVE-2026-109619 (php2shell)? If not, when will it be updated?

If you would rather check yourself:

• WordPress: in the admin area, go to Tools → Site Health → Info → Server. The PHP version is listed there.
• cPanel: look for "Select PHP Version" or "MultiPHP Manager".
• Plesk: open the domain and check its PHP settings.
• Laravel and custom applications: ask whoever manages the server. The version shown on the server's command line can differ from the one serving web pages, so ask for the web one.

If your server uses the PHP packages from its Linux distribution (Ubuntu, Debian, Red Hat and others), the version number may not match the list below even when the fix is installed, because distributions often apply fixes to their own builds. Your host should confirm the fix against the distribution's security notice.

Run this check for every PHP site and application you own, including the old campaign microsite, the staging copy and the admin portal on a subdomain. Forgotten sites on the same server are a common way in.

2. On PHP 8.2 to 8.5: update to the fixed release today

These are security releases within the same version line, so for most sites they change nothing visible. Take a backup, apply the update, make sure PHP and the web server are restarted so the new version is the one actually running, and check the version again. For many sites, this update is the whole fix.

If you cannot update today, CISA's advice is blunt: organisations that cannot update immediately should take PHP-based systems offline until they can be patched. CISA adds that a web application firewall may provide some protection in the meantime, and the PHP project lists configuration changes that reduce exposure to specific attack paths, while saying plainly that they do not make an installation safe. Treat those as measures for days, not as a fix.

3. On PHP 8.1 or older: there is no official fix

The PHP project no longer releases updates for PHP 8.1 and older, so there is no fixed release to install. Its security team did publish minimal source patches for 7.4, 8.0 and 8.1, and some Linux distributions and long-term-support vendors ship their own backported fixes. If your host applies one, it can buy you time. It is still a stopgap: these versions receive nothing else, and the next flaw may not get a patch at all.

CISA's guidance covers this case directly: "Organizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated."

That leaves two real options: upgrade to a supported PHP version, aiming for 8.3 or newer since 8.2 reaches end of life at the end of this year, or plan a move to a modern, supported stack. Old themes, plugins and code may need updating before an upgrade, and an old Laravel or CodeIgniter version may itself need upgrading first. While that work is planned, take offline what you can, put a firewall in front of what must stay up, and watch it closely.

Upgrade or move: how to decide

PHP itself is not the problem here. It runs a large share of the web, WordPress and Laravel are actively maintained, and the PHP project released fixes for every supported version alongside its advisory. The risk comes from versions that have dropped out of support and from servers nobody is responsible for updating. So the right answer depends on your site, not on the language.

A modern stack does not have to mean leaving PHP. For some systems the best destination is current PHP with current Laravel; for others it is a different platform. Our article on legacy system modernisation covers how to weigh wrapping, migrating and rewriting.

How SailRight can help

We offer a free PHP security and upgrade consultation for businesses whose website, store, portal or app backend runs on PHP. It has three parts.

1. Check. We find out which PHP version serves each of your sites and applications, how it is served, who controls the hosting and domain, and what is exposed to the internet, including forgotten subdomains, staging copies and admin panels. We also look for warning signs worth investigating, such as unfamiliar files or admin accounts.
2. Patch. If you are on PHP 8.2 to 8.5, we get the fixed release applied, with your host or directly on your server, after a backup, and confirm the new version is the one running.
3. Plan. If you are on PHP 8.1 or older, we give you a written plan: upgrade in place, or move to a modern, supported stack, with what each involves and an honest estimate.

For many sites the outcome is simple: the update was all that was needed, and we will tell you so. If your current developer or host can do the work, we will tell them exactly what to do. You are under no obligation to hire us for anything else.

Making an upgrade or move manageable

When a bigger change is needed, the aim is to make it as uneventful as possible for your team and your customers.

• Everything is tested on a staging copy first. Your live site keeps serving customers while the upgraded or rebuilt version is checked page by page.
• Your data comes with you. Content, users, customers and order history are migrated and checked against the original.
• Your search rankings are protected. Existing URLs are kept, or redirected to their new addresses, so links and Google rankings carry over.
• The switch is planned. It happens at a quiet time for your business, with a backup and a way back if something unexpected turns up.
• Everything ends up in your name. Code, hosting, domain and admin access belong to you, with documentation for whoever maintains it next.

We will not promise zero downtime or a fixed date before we have seen your site. What you get after the review is a clear plan, an honest estimate and a straight account of the risks. For larger rebuilds, see our web development and custom software services.

Keeping it from happening again

php2shell will not be the last critical PHP flaw. On 23 October the PHP project already flagged a separate, narrower issue that it will fix in its next regular release. The businesses that get through these calmly are the ones where updates are routine rather than an emergency.

• Name one person, inside the company or at your vendor, who is responsible for server updates, and ask them for a short monthly note.
• Know the end-of-life date of every PHP version you run. The PHP supported versions page lists them; 8.2 ends on 31 December 2026.
• Keep backups off the web server, and test a restore.
• Watch for unusual activity. CISA recommends monitoring for PHP processes launching shells or downloading tools.
• Keep the hosting, domain and code accounts in the company's name, a point our guide to choosing a software development company makes for every project.

Talk to us

If you are not sure which PHP version your website runs, or you already know it is an old one, that is exactly what the consultation is for. Book a free PHP security and upgrade consultation: write to info@sailright.tech with your website address and, if you know it, who hosts it. If you do not know, that is fine; finding out is part of the check.

Sources

• CISA, Critical Vulnerabilities in PHP Require Immediate Patching, 21 October 2026, updated 23 October 2026.
• The PHP project, security release announcements for PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and supported versions.

• Security
• PHP
• php2shell
• WordPress
• Laravel
• Patching
• Legacy upgrades