Concise answer
On 21 October 2026, PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws that can let attackers run code on a server without logging in. If your website runs on WordPress or any other PHP software, ask your host or developer to confirm it is on one of these versions or a vendor-patched build. If the site must go offline while it is patched, it should return an HTTP 503 status, not a timeout, 404 or 500 error, so search rankings are protected.
A large share of Indian business websites run on PHP, usually without the owner knowing it. Most WordPress websites, WooCommerce stores, real-estate project sites, wedding and events websites, and many custom-built portals rely on PHP to generate every page.
That is why the October 2026 PHP security update matters to business owners, not just developers. You do not need to understand the technical details. You do need to know whether your website is affected, who is responsible for patching it, and how to avoid losing search visibility while the work is done.
What happened with the PHP vulnerabilities
PHP is the programming language that runs behind most WordPress websites and many other content management systems. On 20 October 2026, the PHP security team gave advance notice of an urgent release. The next day, it published fixes for two critical vulnerabilities, both rated 9.2 out of 10 on the CVSS v4.0 severity scale.
In plain language, the flaws can allow an attacker to run their own code on a web server without logging in. That is called unauthenticated remote code execution, and it is one of the most serious types of security problem. An attacker who achieves it could deface a website, steal customer or enquiry data, install malware, or use the server to attack others.
The official PHP advisory says every PHP installation that serves web requests is at risk, whichever server setup it uses. It considers the risk highest for servers using Apache with mod_php, a common setup on shared hosting.
| Detail | What it means |
|---|---|
| Fixed versions | PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 |
| Vulnerabilities | CVE-2026-109618 and CVE-2026-109619 |
| Severity | Critical, CVSS v4.0 score 9.2 |
| Affected setups | All PHP installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed |
| Older versions | PHP 8.1 and older no longer receive official updates; some hosts and Linux vendors provide backported fixes |
| Workarounds | Configuration changes reduce exposure but do not make a server safe; updating is the only complete fix |
According to Search Engine Roundtable, the issue has been nicknamed PHP2Shell and affects PHP versions from 5.4 through 8.5.11. The same report notes that some organisations, including government, school and hospital websites in Europe, took their sites offline as a precaution until patches were in place.
On 23 October, PHP also published a follow-up advisory recommending one additional configuration setting until its next regular release. Your developer or host should apply it alongside the update.
How to check whether your website is affected
Start by working out whether your website uses PHP at all, and who controls the server it runs on. That tells you who needs to act.
| Your website runs on | Uses PHP? | Who applies the patch |
|---|---|---|
| WordPress or WooCommerce | Yes | Your hosting provider or developer |
| Joomla, Drupal, Magento or OpenCart | Yes | Your hosting provider or developer |
| Custom site built with Laravel, CodeIgniter or core PHP | Yes | Your developer or server administrator |
| Shopify, Wix, Squarespace or Webflow | Not your responsibility | The platform manages its own servers |
| Next.js, React or Node.js | No | Not affected by this PHP issue, but Node.js has its own security updates |
Find your PHP version
If you use WordPress, log in and go to Tools → Site Health → Info → Server. The PHP version is listed there. Most hosting control panels, such as cPanel or hPanel, also show the PHP version in their PHP settings section.
Look for the full version number, not just the first two parts. A website on PHP 8.3.36 is patched; a website on PHP 8.3.35 is not, unless the host has applied its own fix. If the panel only shows "8.3", ask your host for the exact version.
Do not rely on the version number alone
Some hosts and Linux vendors patch PHP without changing to the official version number. Their build may show an older number but still include the fix. Equally, a website on PHP 8.1 or older will not receive official updates at all. In both cases, the only reliable answer comes from your host or developer confirming in writing that the server is protected.
Check every website you own
Many businesses have more than one PHP website: an old microsite, a campaign landing page, a staging copy, or a site for a previous project. Old and forgotten websites are often the least updated and the easiest to attack. Make a list of every domain and subdomain you own and check each one.
Patching safely: what to ask your developer or host
On shared and managed hosting, the host usually updates PHP for you. On a VPS, cloud server, or dedicated server, your developer or server administrator is usually responsible. If you are not sure which applies to you, ask both.
Send these questions today and ask for written answers:
- Which PHP version is each of our websites running, including the full version number?
- Has the server been updated to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to a vendor build that includes the 21 October fixes?
- If not, when will it be done, and will the website need to go offline?
- Was a full backup of files and database taken before the update?
- Has the follow-up setting from PHP's 23 October advisory been applied?
- Have you checked the website, forms and checkout after the update?
- If we are on PHP 8.1 or older, what is the plan to move to a supported version?
Update first, test straight after
A patch within the same PHP version, for example from 8.3.35 to 8.3.36, rarely breaks a website. It should still be followed by a quick check of the homepage, key pages, forms, logins and checkout.
Moving to a newer major version is different. Going from PHP 7.4 or 8.0 to 8.3, for example, can break older themes, plugins or custom code. That move should be tested on a staging copy of the website first. Do not let it delay protection: ask your host whether a backported fix is available for your current version while the upgrade is prepared.
Treat workarounds as temporary
PHP's advisory lists configuration changes that reduce exposure if an update cannot happen immediately. PHP is clear that they do not make a server safe. If your host offers a workaround, accept it as a stopgap and agree a date for the real update.
Plan for PHP 8.2 reaching end of life
PHP 8.2 stops receiving security fixes on 31 December 2026. If your website is on PHP 8.2, this patch protects you for now, but you should plan an upgrade to PHP 8.3 or newer before the end of the year.
Taking a site down without hurting SEO: the 503 rule
Most hosts can patch PHP without any downtime. If your website does need to go offline while it is secured, how it goes offline matters for search rankings.
Google's John Mueller addressed this directly on 21 October. He advised site owners to "use HTTP 503 instead of letting responses time out / 404 / 500". He added that this can be done outside PHP, by pointing DNS elsewhere or using a CDN, which matters when PHP itself is switched off.
A 503 status code tells search engines the website is temporarily unavailable and they should come back later. Other responses send a different, more damaging signal.
| What visitors and Google receive | What it signals | SEO risk |
|---|---|---|
| 503 Service Unavailable | Temporary downtime; check again later | Low for short outages |
| Timeout or no response | The server is unreliable | Can slow crawling and cause pages to drop if it continues |
| 500 Internal Server Error | Something is broken | Can cause pages to drop if it continues |
| 404 or 410 | The page no longer exists | Pages can be removed from search results |
| A noindex tag or robots.txt blocking everything | Do not index this website | Pages and URLs can be removed from search results |
Keep the 503 short
Google's guidance on temporarily disabling a website says a 503 is suitable for urgent downtime of one to two days. For anything longer, it recommends keeping an indexable placeholder home page online instead. In practice, PHP patching should take minutes or hours, not days.
Set it up correctly
- Serve the 503 from the web server, CDN or hosting panel, not from PHP, so it works even while PHP is stopped.
- Add a Retry-After header with your best estimate of when the website will be back.
- Keep the maintenance page simple: static HTML, a short message, expected return time, and a phone number or WhatsApp link for urgent enquiries.
- Never return a 503 for robots.txt. Google treats that as a signal to stop crawling the whole website.
- Do not use the Search Console removals tool, a noindex tag, or a robots.txt block to hide the website during maintenance. These are the same mistakes that cause traffic loss after a website redesign or migration.
Check what your maintenance page actually returns
Some WordPress "coming soon" or maintenance plugins show a friendly page but return a 200 status, which tells Google the maintenance message is your real content. Ask your developer to confirm the status code with a header-checking tool before and during downtime.
Why website maintenance plans matter
The PHP update is a reminder that a website is never finished once it launches. The software underneath it keeps changing, and security fixes arrive on the attackers' timetable, not yours.
This is not only a PHP problem. On the same day, 21 October 2026, Node.js published its own security releases for its 22.x, 24.x and 26.x release lines. The highest-severity issues were rated high, including a flaw in its Brotli decompression code that could lead to remote code execution. Node.js also notes that end-of-life versions are always affected when a security release happens. Websites built with Next.js or Node.js need the same attention as WordPress websites.
What breaks without a maintenance plan
Without a named owner, urgent updates fall between the business, the original developer, and the host. Each assumes someone else is handling it. Meanwhile, the website keeps running outdated PHP, plugins, or Node.js versions until something goes wrong.
For WordPress websites in particular, the core software is only part of the risk. Outdated or abandoned plugins and themes are one of the most common routes into WordPress websites, so they need the same regular updates as PHP itself.
What a good maintenance plan covers
- Monitoring security advisories for PHP, Node.js, WordPress, plugins and other dependencies.
- Applying critical patches within an agreed response time, with routine updates on a regular schedule.
- Automatic daily backups stored away from the main server, with restores tested occasionally.
- Uptime and status-code monitoring, so a broken update or unexpected 500 error is caught quickly.
- A staging copy of the website for testing major updates before they go live.
- Documented access to hosting, domain, DNS and CDN accounts, held in the business's own name.
- A clear plan for supported versions, such as moving off PHP 8.2 before its end of life.
For many small businesses, real-estate developers and ecommerce brands in India, website maintenance costs far less than recovering from a hacked website, lost enquiries, or a drop in search visibility.
If you are not sure who is responsible for your website's updates, or you want a second opinion on whether it is protected, our analytics and ongoing support team can check your PHP version, hosting setup and backups, and put a maintenance plan in place. For WordPress websites, our WordPress development team also handles security, performance and upgrades to supported PHP versions.
A post-patch checklist
Once your host or developer confirms the update, run through this list. Most items take a few minutes, and the first two need your developer.
Confirm the fix
- The PHP version is 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the host has confirmed in writing that its build includes the 21 October fixes.
- The setting from PHP's 23 October follow-up advisory has been applied or ruled out.
- Every website, subdomain and staging copy you own has been checked, not just the main one.
Check the website works
- The homepage, service or project pages, and blog load normally on mobile and desktop.
- Enquiry forms, site-visit or booking forms, and WhatsApp or click-to-call buttons work and reach the right inbox or CRM.
- For ecommerce, a test order completes through cart, checkout and payment.
- Admin and customer logins work.
Check search and tracking
- Key pages return a 200 status code, not 503, 500 or 404.
- Any maintenance page or 503 response has been removed.
- robots.txt allows crawling, and no noindex tag was added during maintenance.
- Google Search Console shows no new spike in server errors over the following days.
- Analytics and conversion tracking are recording visits and leads.
Check for signs of compromise
- No unknown administrator accounts have appeared in WordPress or the hosting panel.
- No unexpected files, redirects, pop-ups or spam pages have appeared.
- Passwords for hosting, WordPress admin, database and FTP are changed if there is any doubt.
- A clean backup taken after patching is stored safely.
If anything on this list looks wrong, treat it as a possible security incident and get your developer or host involved straight away.
A quick summary
- On 21 October 2026, PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical remote code execution flaws.
- Most WordPress, WooCommerce and other PHP websites are affected until the server is updated.
- Check your full PHP version, then ask your host or developer to confirm the fix in writing.
- PHP 8.1 and older no longer get official updates; plan an upgrade, and move off PHP 8.2 before 31 December 2026.
- If the website must go offline, serve an HTTP 503 with a Retry-After header for hours, not days.
- Node.js shipped its own security releases the same day, so ongoing maintenance matters on every stack.
Frequently asked questions
Is my WordPress website affected by the PHP security update?
Almost certainly, unless your host has already updated PHP. WordPress runs on PHP, so any WordPress or WooCommerce website is affected until the server runs PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, or a vendor build with the fixes. Updating WordPress itself does not fix this; the server's PHP must be updated.
How do I check my website's PHP version?
In WordPress, go to Tools → Site Health → Info → Server. In most hosting control panels, the PHP version appears in the PHP settings section. Check the full version number, such as 8.3.36, and ask your host to confirm whether their build includes the October 2026 fixes.
Will updating PHP break my website?
A patch within the same version, such as 8.3.35 to 8.3.36, rarely causes problems. Upgrading from an old version such as PHP 7.4 to PHP 8.3 can break outdated themes, plugins or custom code, so it should be tested on a staging copy first. Take a backup before any update.
Does taking my website offline hurt SEO?
Short downtime does little harm if the website returns an HTTP 503 status code. Google's John Mueller recommended a 503 instead of timeouts, 404 or 500 errors. Google's documentation suggests a 503 for urgent downtime of one to two days at most; longer outages need a different approach.
What is an HTTP 503 status code?
A 503 Service Unavailable response tells browsers and search engines that a website is temporarily down and will return. It can include a Retry-After header saying when to check again. Search engines treat it differently from errors that suggest a page is broken or gone.
My website uses Shopify or Wix. Do I need to do anything?
No action is needed for this PHP issue on hosted platforms such as Shopify, Wix, Squarespace or Webflow, because the platform manages its own servers. You should still check any separate PHP websites you own, such as an old WordPress blog or campaign microsite.
Is a Next.js or Node.js website affected?
Not by these PHP vulnerabilities. However, Node.js released its own security fixes on 21 October 2026 for its 22.x, 24.x and 26.x release lines, including high-severity issues. Ask your developer to confirm your Node.js version is updated.
What should a website maintenance plan include?
A good plan covers security monitoring, timely patching of PHP, Node.js, CMS and plugins, daily off-site backups, uptime monitoring, a staging environment for testing, and a clear response time for critical issues. It should also name who is responsible for each part of the website.