Oct 22, 2026

Is Your Website Affected by the New PHP Vulnerability? Check Now

Q: Is my business website actually at risk?

If it runs on PHP, which covers WordPress, WooCommerce, Magento, Drupal, Joomla, Laravel and most custom-built sites, then it is at risk until the server's PHP is updated and restarted. W3Techs puts PHP on 69.3% of sites whose server-side language is known. If your site was built on Shopify, Wix or Squarespace, the PHP flaw isn't yours to fix, because those platforms don't run your pages on PHP.

Q: Who is responsible for fixing this: me, my developer or my hosting company?

Whoever controls the server's PHP version. On shared hosting and managed WordPress hosting that is the host. On a VPS or dedicated server it is whoever administers the box, which is your developer, your agency or you. Plugin and theme authors can't fix it. Find out today which of those people owns the job, because in a lot of small businesses nobody is sure.

Q: Will updating WordPress, plugins or my theme fix the problem?

No. The bug is in PHP itself, one layer below WordPress. You can have every plugin on its newest release and still be fully exposed. Updating WordPress is still a good habit, it just isn't this fix.

Q: How urgent is this? Do I need to act today?

Yes, today, at least to the point of messaging your host or developer and getting a written answer. The flaws allow code execution without any login, the technical write-ups are public, and attempts have been reported. A patch that lands next week instead of this week is a real difference in exposure.

Q: Should I temporarily take my website offline?

For most businesses, no, not if your host can patch within a day or so. Taking a site offline costs sales and search visibility. It becomes reasonable when the server runs a PHP version that has no fix at all (5.4 to 7.3), when you hold sensitive data such as health or financial records, or when your host can't give you a patch date. A maintenance page, or putting the site behind a service such as Cloudflare while you wait, are the usual middle options.

Q: Will fixing this cause downtime or break my website?

Usually only a brief restart, often seconds. The risk of breakage rises if the jump is large. Moving from 8.3.35 to 8.3.36 is a security patch release and rarely changes behaviour. Moving from PHP 7.4 to 8.3 can break old plugins and custom code, so that one needs testing on a staging copy first. Ask for the patch release inside your current branch if you want the lowest-risk path.

Q: How do I know if my hosting company has already protected me?

Ask them to show you, not tell you. A good answer names the exact PHP version running on your account, the date it was updated, and confirms the PHP processes were restarted afterwards. A vague 'we're aware and working on it' is not protection. Section 10 below shows how to check the version yourself.

Q: What if my host says they're working on it?

Ask for a date and a time, and what they'll do for your site in the meantime. If they can't answer, ask whether you can switch to a patched PHP version from your control panel, or whether they can enable the temporary settings in section 9. If you get nothing concrete within a working day, start planning a move to a host that can answer. Put the question in writing so you have a record.

Q: Can hackers steal my customer data, orders or login details?

Anyone who can run code on your server can read the files your site can read. That normally includes your database password, which is stored in plain text in a config file such as wp-config.php, and through it your customer table, orders and hashed passwords. Separately, one of the two flaws can leak pieces of server memory, which may include session data from other visitors.

Home Blog Is Your Website Affected by the New PHP Vulnerability? Check Now

About The Author

Anuj Bajaj

Anuj Bajaj is the Co-Founder of SIB Infotech and a seasoned digital strategist with over 18 years of experience in website development, SEO, and performance marketing. He leads the agency’s content and digital growth initiatives, ensuring that every piece of content is both search-engine optimized and value-driven. Anuj believes in blending AI-powered efficiency with human creativity to deliver content that educates, converts, and builds authority.

A critical security flaw nicknamed PHP2Shell has put millions of websites at risk, including a lot of small and medium business sites. It sits in PHP itself, so updating WordPress or your plugins does nothing for it. Your server needs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a patched package from your host or Linux vendor), and the PHP processes have to be restarted afterwards. If you don't know who handles that for you, find out today.

Details of the flaws leaked before PHP's planned release date, so the project pulled its emergency patches forward and shipped them on 21 October 2026. The NSA and the UK's NCSC have both told organisations to patch. Cloudflare's CTO and the security firm watchTowr have reported exploitation attempts already.

This guide explains it in plain English. You'll find out what the flaw is, whether you're affected, what could go wrong for your business, exactly what to ask your host, and how to prove the fix is in. We've put copy-ready messages in section 7, and an FAQ near the end covers every question we saw people asking on X and in search.

What PHP2Shell actually is

PHP is the programming language that runs a huge share of the web. When a visitor opens a page on a PHP site, the server hands the request to PHP, PHP runs the site's code, and the result goes back to the visitor. PHP2Shell is two bugs in that engine, not in WordPress, not in a plugin, and not in code your developer wrote.

They have official names: CVE-2026-109618 and CVE-2026-109619. Each scores 9.2 out of 10 (Critical) on the CVSS v4.0 scale, and each can let a stranger on the internet run commands on your server without logging in.

The name comes from where that ends up. Once an attacker can run commands, they can open a command shell on the machine, hence "PHP2Shell".

The two bugs, lightly

CVE-2026-109618 is a memory-corruption bug. If PHP runs out of memory part-way through handling a request, it can leave half-built data behind and then treat that data as if it were complete during clean-up. Attackers can steer that into code execution. Wiz also reports that this one can leak the contents of the server process's memory, which an attacker can read back through the PHPSESSID session cookie.

CVE-2026-109619 is a stale-state bug. PHP can keep information from a request that crashed with a fatal error, and later code trips over it. Because a PHP worker handles many visitors one after another, what one request leaves behind can matter to the next. This one touches PHP's fatal-error backtraces and OPcache, the speed-up cache most servers have switched on.

Timeline

19 Aug 2026

Wiz researchers find the flaws.

20 and 21 Aug

Wiz gets working remote code execution against Drupal, then WordPress.

24 Aug

Reported to the PHP project. PHP acknowledges it on 21 September.

20 Oct

PHP warns administrators that emergency patches are coming.

21 Oct, 03:02 UTC

Cloudflare's WAF rules go live.

21 Oct, 14:00 UTC

PHP releases fixes, a day earlier than planned, after the leak.

What it could do to your business

Run code on your server, and you can do whatever your website can do. That's the whole problem. Here is what that has meant in earlier cases where web servers fell to this kind of flaw:

Customer data theft.

Your site's database password sits in a config file the site must be able to read, so an attacker who runs code can read it too. After that they can pull customer names, emails, addresses, order histories and password hashes.

Defacement or full takeover.

They can swap your homepage, create their own administrator login, or lock you out.

Malware and ransomware.

Compromised sites get used to host malware, redirect visitors to scams, or send spam. Two earlier PHP bugs, CVE-2024-4577 and CVE-2019-11043, are both on CISA's Known Exploited Vulnerabilities list, and ransomware crews have used them.

Payment skimming.

Card details typed on a hosted checkout like Stripe's don't touch your server, but an attacker who controls your pages can alter the checkout to capture them.

Reputation damage.

Google flags infected sites, browsers show warnings, and customers who get a breach email don't forget it.

Legal and compliance trouble.

Under GDPR you have 72 hours to tell the regulator once you know personal data was exposed. India's CERT-In directions, in force since 2022, require reporting certain incidents within six hours. Take advice from a lawyer, because the details vary by country and sector.

Downtime and lost sales.

Cleaning an infected site often means taking it down for a day or more. Reports in The Hill and The National described some government services pulled offline during the scramble.

The part owners tend to underestimate is this one: a site that looks fine may already be compromised. Attackers who get in want to stay in. A hidden admin account or a backdoor file doesn't change what your homepage looks like.

Is anyone exploiting it yet?

Treat it as yes. The picture as of 22 October: Cloudflare's CTO and watchTowr reported attempts, and the detailed write-ups became public within hours of the leak. PHP said that when it released the patches it hadn't found a functional public exploit, and we couldn't find the flaws on CISA's Known Exploited Vulnerabilities list. Nobody has published evidence of mass compromise. Those caveats are real, but it would be foolish to take comfort from them. When a bug of this size has a public description, scanners start probing within days.

Which sites are affected

Any website that runs on PHP and serves pages through a web server. That list covers WordPress and WooCommerce, Magento, Drupal, Joomla, PrestaShop, Laravel and Symfony apps, phpBB, Nextcloud, and every custom PHP site an agency ever built for you.

The affected code goes back to PHP 5.4.0, released in 2012, and the upload-progress feature that PHP's mitigation advice centres on has been on by default since then. By server type, mod_php under Apache carries the highest risk, but PHP-FPM, php-cgi, FrankenPHP and LiteSpeed setups are all affected too. Shared hosting, managed WordPress hosting, VPS and dedicated servers are all exposed until the host or administrator patches.

Common mistake

Updating WordPress, your theme or your plugins does not fix this. Those updates change code that runs on top of PHP. The flaw lives in PHP, one layer underneath. You can be fully up to date on everything you can see in the dashboard and still be vulnerable.

What isn't affected

Platforms that don't run your pages on PHP aren't hit by this flaw. Shopify, Wix and Squarespace storefronts fall in that group. Watch for the side attachments, though: a WordPress blog on a subdomain, a booking plugin on a separate server, or an old microsite your agency forgot about all count. If it runs PHP and is reachable from the internet, it's in scope.

Who's responsible for fixing it?

Whoever controls the server's PHP version. On shared and managed hosting, that's your host. On a VPS or dedicated server you rent, it's whoever administers it: your developer, your agency, or you. Plugin makers and theme authors can't touch it. Settle this question first, because plenty of small businesses discover during an incident that each party assumed the other one handled it.

Your setup	Who patches PHP	What you do
Shared hosting (cPanel, Plesk)	Host	Ask for the version, date and restart. Check whether you can pick a fixed PHP version in your control panel.
Managed WordPress host	Host	Ask the same questions. Most managed hosts publish a status note.
VPS or dedicated, managed by an agency	Agency	Send them the developer template in section 7 and ask for a written report.
VPS or dedicated, self-managed	You	Follow sections 5, 6 and 10. Patch and restart today.
Docker or Kubernetes	Whoever builds the image	Rebuild from a fresh base image, redeploy, verify inside the container.

The numbers behind the noise

PHP is under a bigger part of the web than most owners realise. W3Techs reports PHP on 69.3% of all sites whose server-side language it can identify, and WordPress alone on 40.2% of all websites (as of 1 October 2026). You may have seen "75 to 80% of the web" in some coverage. We couldn't trace that to a source, so we use W3Techs' figure.

PHP sites by major version (W3Techs, 22 Oct 2026)

PHP 8.x

65.3%

PHP 7.x

26.9%

PHP 5.x

7.7%

PHP 4.x

0.1%

Of sites running PHP, 65.3% are on 8.x, 26.9% on 7.x, 7.7% on 5.x and 0.1% on 4.x. Only some 8.x installs are on a fixed release, since the fixes arrived on 21 October. Source: W3Techs.

How many of those are exposed to the internet and still unpatched is harder to pin down, and the estimates disagree. VirusTotal's 21 October scan found about 5.1 million IP addresses serving PHP, around 3.8 million of them with an open port, and only about 1.1 million willing to reveal a version. That means roughly four in five hide their version, which is good practice, but it also means nobody can tell you precisely how many are vulnerable. Tenable's FAQ cites two other counts: about 1.3 million exposed hosts (Cutler) and about 1.9 million through Shodan (Poley). A figure of 22 million exposed instances is circulating on X, and we couldn't find a source for it, so we don't use it.

Hosts that reveal their PHP version, by branch (VirusTotal, 21 Oct 2026)

PHP 5.4 to 8.1 (end of life) 758K

PHP 8.2 to 8.5 272K

PHP 5.2 and 5.3 88K

About 1.1 million hosts disclose a version. Roughly 758,000 sit on end-of-life branches 5.4 to 8.1 (PHP 7.4 alone is about 187,000, PHP 5.4 about 119,000), and another 88,000 on 5.2 or 5.3. About 272,000 run 8.2 to 8.5, but a host on 8.3.35 is still unpatched. About 85,000 were on the 24 September releases, one security update behind. Figures in thousands. Source: VirusTotal blog.

The same VirusTotal data counted about 538,000 WordPress hosts, 141,000 Laravel and 107,000 Nextcloud, with about 920,000 PHP hosts in the US. If you want one takeaway from the charts: the biggest single pool of exposed servers is running a version that will never get an official fix.

How bad is it compared with Heartbleed?

We'd say bigger in reach. Heartbleed in 2014 leaked memory from servers running a vulnerable OpenSSL. PHP2Shell can run code, and PHP runs under a far larger slice of the web than a single OpenSSL version did. Against that, success isn't automatic: the flaws depend on specific conditions, and PHP saw no working public exploit when it shipped. Call it a drop-everything patch, but not proof that every PHP site is already breached.

What a slow response costs

IBM's 2026 Cost of a Data Breach report puts the global average breach at $4.99 million, up 12%, and the US average at $11.5 million. Those numbers come mostly from large companies, so don't read them as a quote for a ten-person business. The finding that does scale down is speed: breaches that took more than 200 days to identify and contain averaged $5.65 million, against $4.32 million for the faster ones, and the overall average time was 247 days.

Average breach cost by time to contain (IBM, 2026)

Under 200 days $4.32M

Over 200 days $5.65M

Bars start at zero. Source: IBM Cost of a Data Breach Report 2026, as reported on ibm.com.

A quick self-check

Three questions get you most of the way:

1 Is your site built on WordPress, Magento, Drupal, Joomla, Laravel or another PHP platform? If you're not sure, ask your developer, or open the site's source code and look for wp-content in the page.

2 Who manages your hosting? You'll find them on your hosting invoice, or in your domain's DNS records if you set it up through someone else.

3 Has that person confirmed in writing that the PHP version is a fixed one, and that PHP was restarted after the update?

If you can't answer the third one with a yes, you aren't protected yet.

The fixed versions

PHP branch	Fixed in	Status
8.5	`8.5.12`	Fixed upstream, 21 Oct 2026
8.4	`8.4.27`	Fixed upstream
8.3	`8.3.36`	Fixed upstream
8.2	`8.2.35`	Fixed upstream; security support ends 31 Dec 2026
8.1, 8.0, 7.4	No tagged release	Minimal source-only backports on separate branches. Use a vendor build or upgrade.
5.4 to 7.3	None	No upstream fix

Put plainly: you want PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or any newer release on the same branch, or a package from your host or Linux vendor that carries the fix under its own number. Your host may show a number that looks lower and still be patched, so ask, don't guess.

How to check your PHP version properly

Typing php -v into a terminal tells you about the command-line PHP, which may not be the one serving your website. Check the web-facing one:

On shared or managed hosting, open your control panel's PHP selector (it's called "Select PHP Version" or "MultiPHP Manager" in cPanel). Note that it shows a branch such as 8.3, not the patch number, so you still need your host to confirm the exact release.
On a server you manage with PHP-FPM, run php-fpm -v, or the versioned name such as php-fpm8.3 -v.
With Apache and mod_php, run apachectl -M and look for a php_module line, then check the installed package version.
In Docker, run docker exec <container> php -v against the container that's serving traffic, not against the host.

Don't leave a phpinfo() page on a public site to check this. It hands attackers a map of your server.

Ubuntu package versions

Linux vendors patch under their own version numbers. For Ubuntu, Canonical's notice USN-8948-1 lists these fixed packages:

Ubuntu release	Package	Fixed in
14.04 Trusty	`php5`	`5.5.9+dfsg-1ubuntu4.29+esm18`
16.04 Xenial	`php7.0`	`7.0.33-0ubuntu0.16.04.16+esm22`
18.04 Bionic	`php7.2`	`7.2.24-0ubuntu0.18.04.17+esm14`
20.04 Focal	`php7.4`	`7.4.3-4ubuntu2.29+esm5`
22.04 Jammy	`php8.1`	`8.1.2-1ubuntu2.28`
24.04 Noble	`php8.3`	`8.3.6-0ubuntu0.24.04.13`
26.04 Resolute	`php8.5`	`8.5.4-0ubuntu1.5`
26.10 Stonking	`php8.5`	`8.5.9-0ubuntu2.1`

List what you have installed with apt list '?installed ?name(^php[0-9.]+$)'. For Debian, Red Hat, AlmaLinux and others, use their security trackers for CVE-2026-109618 and CVE-2026-109619, because those builds keep the old version number with a patched changelog. Ubuntu's old releases (14.04 to 20.04) need Ubuntu Pro for the extended-support fix, which is what the "esm" label means.

What to do today

1 Contact your host or developer now. Don't wait for a newsletter. Use the templates in section 7 and ask for a written answer.

2 Get the exact PHP version and the restart time. "We've updated" isn't enough. You want a version number, a timestamp, and confirmation the PHP processes were restarted.

3 Know who owns the patch. If nobody does, that is your actual emergency, and it's worth fixing before the next flaw arrives.

4 Take a fresh backup. Keep a copy offline or on another account. If the site has been tampered with, you'll want both the backup and a copy of the current state for investigation.

5 Look for signs of compromise. New administrator users, modified files, odd scheduled tasks, repeated 500 errors. Details below.

6 If patching will take time, ask about temporary measures. Section 9 lists them, and a maintenance page or taking the site offline is on the table if your host can't give you a date.

Signs that someone has already tried

Wiz lists three things worth looking for in server logs from 19 August onward: unusual multipart requests followed by memory-limit errors or runs of HTTP 500 responses, oversized or malformed PHPSESSID values in response cookies, and PHP workers crashing and respawning. On WordPress you can also run these through WP-CLI if your host or developer gives you access:

wp user list --role=administrator
wp core verify-checksums
wp plugin verify-checksums --all
find /var/www -name '*.php' -mtime -7 -not -path '*/cache/*'

The first lists every administrator, so look for names you don't recognise. The next two compare WordPress and plugin files against the official copies. The last lists PHP files changed in the past week, and any new PHP file inside wp-content/uploads is almost never legitimate. A clean result is reassuring, but not proof. A successful exploit can be quiet.

Questions for your host or developer

Send these as written. Specific questions get specific answers, and a vague reply tells you something too.

Which PHP version and handler serve my site right now?
Is it a build that fixes CVE-2026-109618 and CVE-2026-109619, and what's the exact version?
When was it applied, and were all PHP processes restarted?
If it isn't patched, what's the date and time, and what's protecting me until then?
Have you seen exploitation attempts against my account since 19 August?
Can someone reach my server directly, or only through your firewall or CDN?
Do I have old, staging or forgotten copies of the site running older PHP anywhere?
If you find signs of compromise, how fast will you tell me and what's your clean-up process?

Message to your hosting provider

Subject: Urgent: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) for [your-domain.com]

Hi [Host name],

Please confirm in writing, today if you can:

Which PHP version and handler (mod_php, PHP-FPM, LiteSpeed, other) is serving [your-domain.com] right now?
Has that PHP been updated to a build that fixes CVE-2026-109618 and CVE-2026-109619? What is the exact version?
When was the update applied, and were all PHP processes restarted afterwards?
If it isn't patched yet, what is the date and time it will be, and what protection is in place until then?
Can you see any exploitation attempts against my account in your logs since 19 August?
Is my site's origin reachable directly, or only through your firewall or CDN?

Thanks,
[Name], [Business], [phone]

Message to your developer or agency

Subject: PHP2Shell: please check [your-domain.com] and send me a short report

Hi [Developer name],

PHP2Shell is a critical PHP core flaw (CVE-2026-109618 and CVE-2026-109619). Updating plugins won't fix it, it needs the server's PHP patched and restarted.

Could you tell me by [time/date]:

Who manages the server's PHP for [your-domain.com], you or the host?
What PHP version runs the live site, and is it 8.5.12, 8.4.27, 8.3.36, 8.2.35 or newer, or a vendor build with the fix?
Were PHP-FPM or Apache restarted after the update?
Are there staging, old or forgotten copies of the site on other servers running older PHP?
Please check admin users, recently modified PHP files, cron jobs and error logs for anything odd since 19 August.
If we can't patch today, which temporary settings from php.net's notice can we apply, and what's the risk of each?
Please take a fresh backup before you change anything and tell me where it's stored.

Thanks,
[Name]

If the reply is "we're working on it"

That's an acknowledgement, not an answer. Ask for a time, and ask what they will do for your site in the meantime. If there's no concrete date within one working day, ask whether you can switch to a patched PHP version yourself from the control panel, or whether the temporary settings in section 9 can be applied to your account. If you still get nothing, begin planning a move to a host that answers questions quickly. Keep every message, because a clear record helps if a regulator asks later.

If your site was compromised

It's a realistic possibility with a flaw like this, so it's worth knowing the plan before you need it. The usual sequence:

Contain it. Put up a maintenance page or take the site offline. If your host supports it, isolate the account from the network.
Keep evidence. Copy the files, database and logs before cleaning anything. You may need them for insurance, a regulator, or a forensic firm.
Patch before you restore. Restoring a backup onto an unpatched server just hands the attacker the same door. Update and restart PHP first.
Rebuild from known-good. Restore from a backup that predates any suspicious activity, or rebuild from clean copies of WordPress, plugins and themes and re-import only your content. Don't trust files you merely scanned and deleted.
Rotate every secret. Database password, WordPress salts, API keys (including payment, email and SMS), SSH keys, FTP and admin passwords. Anything stored on the server should be treated as read by the attacker.
Force password resets. For admins first, then customers if their data was in reach.
Check connected systems. Mail on the same hosting account, backups stored on the same server, and any other site sharing the account.

When to involve professionals

Bring in a specialist if customer personal data may have been accessed, if you take card payments, if you find a backdoor and can't be sure you've removed it, or if the site is central to revenue. In the UK, NCSC recommends using providers from its assured cyber incident response scheme. NCSC also asks organisations to check for backdoors after patching, since a patch closes the door but doesn't remove someone who's already inside.

What to tell customers

Say what happened, what data was involved, what you've done, and what they should do (change passwords, watch for phishing, check statements). Don't speculate about causes, and don't blame your host in public before you know the facts. If personal data was exposed, the clock on regulator notice starts when you become aware, 72 hours under GDPR and six hours for CERT-In-reportable incidents in India, so involve a lawyer early. If you were patched, saw no signs of intrusion, and no data was accessed, you generally don't need to notify customers. This isn't legal advice.

Stopgaps while you wait

These come from PHP's own announcement. They reduce risk for people who can't patch immediately, and they don't fix anything.

Set memory_limit=-1 through php_admin_value. This one looks backwards, since it removes the memory ceiling. The attack leans on PHP running out of memory mid-request, so removing the ceiling takes that trigger away. The catch is that a runaway script can now eat all the server's memory, so pair it with a limit set outside PHP.

Limit memory with cgroups or container limits. PHP says to use these rather than RLIMIT_AS or RLIMIT_DATA.

Lower post_max_size. PHP suggests values like 8M or 32M. It shrinks the size of request an attacker can send.

Turn off the upload-progress feature. Set session.upload_progress.enabled=0 in php.ini or your pool configuration, not with ini_set() or .user.ini, which don't work for this. Then restart every PHP worker.

On PHP 8.5, set fatal_error_backtraces=0. That closes off the path behind CVE-2026-109619.

Use a WAF in front of the site. Cloudflare turned on protection at 03:02 UTC on 21 October. It only covers traffic that passes through Cloudflare, so make sure your origin server accepts connections only from Cloudflare's addresses.

Don't mistake these for a fix

Each of these closes one route. A WAF works on signatures and can miss variants, and settings only help where you can change them. Shared-hosting customers usually can't edit these at all, so ask your host. Patch and restart as soon as you can.

Confirming the fix took

You should see a version number, a time, and a restart. Walk through this once the update is done:

1 Find out which PHP actually serves your site. Ask your host, or check your control panel's PHP selector. On a server you administer, check the web SAPI with php-fpm -v or apachectl -M, not only the php command.

2 Compare the version with a fixed one. On upstream PHP you want 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer on the same branch. On distribution packages, compare against your vendor's security notice instead.

3 Confirm the processes were restarted. A package upgrade alone doesn't replace running workers. Check PHP-FPM or Apache start times with ps -o lstart,cmd and make sure they're later than the update.

4 Check for signs of tampering. Review administrator accounts, recently changed PHP files, scheduled tasks, and your error logs for memory-limit errors and repeated 500 responses since 19 August.

5 Get the confirmation in writing. Ask your host or developer to email the PHP version, the update time and the restart time, and keep the message with your records.

If you run the server yourself, compare process start times against the update time:

ps -o lstart,cmd -C php-fpm8.3
sudo needrestart -r l

The first command shows when PHP-FPM workers started, which must be after you applied the update. The second, on Debian-family systems, lists services still running outdated libraries. Change php-fpm8.3 to match your version.

Your checklist

Web-facing PHP version is a fixed release or a vendor build with the fix.
PHP-FPM or Apache was restarted after the update, and start times prove it.
Docker images were rebuilt and old containers are gone.
Staging, old and forgotten copies of the site are patched or switched off.
No unfamiliar admins, odd files or suspicious logs since 19 August.
Written confirmation from your host or developer saved with your records.

One more scenario worth naming. If your server applies updates automatically, as Ubuntu's unattended-upgrades does within about 24 hours, the package may be installed but the workers may still be running the old code in memory. That's the gap people miss.

Longer-term lessons

This week it's PHP. Next time it will be something else, and the shape of the problem will be the same: a flaw below your website, announced publicly, with a window of days to act.

"Update your plugins" isn't a security plan. Plugins are one layer of at least four. The PHP engine, the web server, the operating system and the hosting account sit underneath, and someone has to look after each.
Write down who owns what. One page: who patches PHP, who patches the operating system, who watches security notices, and how to reach each of them on a weekend. Most delays in this kind of incident are people working out whose job it is.
Review your hosting. If your host took days to say anything about a critical flaw, that's useful information about the next one. Managed hosts that patch within hours cost more for a reason.
Get off end-of-life PHP. About 758,000 internet-facing hosts that reveal their version run branches that no longer get fixes. PHP 8.2 itself loses security support on 31 December 2026, so put its replacement in your plan now.
Keep backups somewhere the site can't reach. Test restoring one every few months. A backup you've never restored is a hope.
Keep a one-page response plan. Who decides to take the site offline, who talks to customers, who calls the lawyer, who holds the passwords. Ten minutes of writing saves hours on the day.
Subscribe to alerts. Your host's status page, PHP.net's news feed, and the NCSC or CISA alert emails cost nothing.

What to do next

Message your host or developer using the templates above, and don't stop until you have a version number and a restart time in writing. If the answer is vague, escalate. If the site holds customer data, run through the compromise checks as well.

Want a second pair of eyes on your site?

SIB Infotech, a web development and hosting team in Mumbai, can check which PHP version each of your domains is really running, review your hosting setup, look for signs of tampering, and handle the patch and restart for you. Send us your domain list and we'll tell you where you stand.

Contact SIB Infotech

If this helped, forward it to another business owner who has a website and a hosting account they haven't thought about in a while.

Sources

Frequently Asked Questions

Common Questions & Answers

Is PHP2Shell being actively exploited?

Treat it as yes. Cloudflare's CTO and watchTowr both reported exploitation attempts, and the details leaked before the planned release date. PHP's own team said that at release time it had found no functional public proof-of-concept, and as of 22 October 2026 we couldn't find the flaws on CISA's Known Exploited Vulnerabilities list. Nobody has published proof of mass compromise either. None of that is a reason to wait. Scanners don't need a polished exploit to start probing.

Is my business website actually at risk?

Who is responsible for fixing this: me, my developer or my hosting company?

Will updating WordPress, plugins or my theme fix the problem?

How urgent is this? Do I need to act today?

Should I temporarily take my website offline?

Will fixing this cause downtime or break my website?

How do I know if my hosting company has already protected me?

What if my host says they're working on it?

Can hackers steal my customer data, orders or login details?

Does this affect my email, payments or other connected tools?

Is my site still safe if it looks normal and nothing has happened yet?

What happens if my site gets hacked because of this?

Do I need to tell my customers or staff?

Could this lead to legal or compliance problems for my business?

How much could this cost me if something goes wrong?

Once it's fixed, how do I confirm everything is actually safe?

What is PHP2Shell and which CVEs does it cover?

Which PHP versions are vulnerable and which are fixed?

How do I check my actual PHP version, since the command line and the website can differ?

Does this affect WordPress, Magento, Drupal, Joomla, Laravel and shared hosting?

What are the temporary mitigations if I can't patch right away?

How do I update PHP, and do I need to restart anything afterwards?

Is there a risk of memory disclosure or credential theft without full code execution?

How do I detect whether someone already tried to exploit me?

What about PHP 8.1 and older, or other end-of-life versions?

Are Docker and container images affected, and how do I update them?

Does Cloudflare or a WAF fully cover me?

How serious is this compared with Heartbleed or other big flaws?

Can the exploit work without an upload form or authentication?

What are the fixed package versions for Ubuntu, Debian and RHEL?

After patching, how do I verify the running workers are on the fixed version?

Rated 4.8 by Clients on Every Major Review Platform

Our 4.8 average client rating is built on delivering the results we promise. From SEO rankings and lead generation to web development and paid marketing, our clients across 40+ countries have shared their experience publicly.

4.8

Digital Marketing and SEO Agency Reviews about SIB Infotech

Rupesh Maniar

Real Value Finloan Services Pvt. Ltd.

SIB Infotech has designed website for our company. We are very happy with outcome. They are not only professional but also putting their heart into work. We will always refer them for quality work and perfect price.

Reviewed From

Tima Elhajj

CEO & Founder, Tima Media

The client loved the platform that the SIB Infotech team developed for them, especially the calculator function. The company appreciated the team's high level of professionalism, communication, and care on the project. They are happy and willing to work with the team again.