PHP2Shell in New Zealand: Is Your Website Affected? How to Check and Fix It

Your website could be running perfectly, with its CMS and plugins fully updated, while the server is still using a vulnerable PHP version.

That's the concern with PHP2Shell.

On 21 October 2026, the PHP project released emergency security patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which could allow attackers to run malicious code on affected servers without logging in.

The issue goes beyond WordPress. Businesses using Drupal, Joomla, Magento, Laravel or custom PHP applications could also be exposed.

New Zealand's National Cyber Security Centre (NCSC) has urged businesses to check their websites and online services. The vulnerabilities have also been added to the United States Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities catalogue.

If your website uses PHP, the priority is to confirm that your server has been patched.

Updating your CMS or plugins alone won't fix PHP2Shell.

Here's what New Zealand businesses need to know, how to check their PHP version and what to do next.

PHP2Shell: What Website Owners Should Do Right Now

TL;DR: PHP2Shell is a critical security issue affecting PHP installations used to serve web requests. Fixes were released on 21 October 2026, but businesses need to confirm that the patched software is actually running.

If someone else manages your hosting, contact them first.

Start with these four checks:

Which PHP versions are affected?

1. Identify which systems use PHP. Include your main website, customer portals, booking systems, APIs and separately hosted applications.
2. Confirm your PHP version. The first fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Some hosting providers may supply verified security patches for older packages.
3. Verify that both vulnerabilities are patched. Ask specifically about CVE-2026-109618 and CVE-2026-109619. The patched software must be running, not simply installed.
4. Check for suspicious activity. Ask your technical team to review unusual requests, server errors and unauthorised changes.

If an affected service cannot be patched immediately, a security specialist should assess whether access needs to be restricted or the service temporarily taken offline.

Latest PHP2Shell Security Updates

Several important developments have occurred since the vulnerabilities were disclosed.

CISA's catalogue is a useful indication of the urgency, although its federal remediation deadlines do not automatically apply to New Zealand businesses.

The takeaway: Even if your website appears to be working normally, an affected PHP installation should be checked and patched promptly.

Which PHP Versions Are Affected by PHP2Shell?

PHP2Shell affects multiple PHP release branches. The first official fixes for supported branches were released on 21 October 2026.

These are the first PHP2Shell fixes for the listed supported branches, not necessarily the latest available PHP releases.

Already using a fixed release? Confirm that it's the version actually serving your website.

Using managed hosting? Your provider may have applied the update already. Ask for written confirmation.

What if Your Website Uses an Older PHP Version?

An older version number doesn't always mean a server remains vulnerable.

Some operating system vendors, hosting providers and extended support services apply security fixes to existing PHP packages without changing the main version number.

Given the severity of PHP2Shell, the PHP security team also published minimal source backports for PHP 7.4, PHP 8.0 and PHP 8.1.

These backports provide a route for vendors and experienced administrators to address the vulnerabilities in older installations.

However, they do not mean those PHP branches have returned to normal upstream support.

For businesses using older versions, the safest approach is to:

• Confirm whether your hosting provider has supplied a verified security patch.
• Check that both PHP2Shell CVEs are covered.
• Establish whether the patched package is currently running.
• Plan an upgrade to a supported PHP version.
• Test older applications and integrations before deployment.

Important: PHP 8.2 reaches the end of its upstream security support on 31 December 2026. Businesses still using it should plan their next upgrade.

For local guidance, refer to the NCSC's official advisory covering both PHP2Shell vulnerabilities.

Understanding the PHP2Shell Vulnerability

PHP is a programming language that handles much of the work happening behind a website.

When someone logs into an account, submits an enquiry form or places an order online, PHP may be processing that request on the server.

PHP2Shell involves two weaknesses in how PHP manages memory and internal information while handling those requests.

Both vulnerabilities received a CVSS v4.0 severity score of 9.2 out of 10, placing them in the critical category.

CVE-2026-109618: Memory Corruption During Error Handling

PHP can run out of memory while processing a request.

Under certain conditions, that error interrupts the normal handling of internal data.

When PHP tries to clean things up, it may treat information that wasn't properly initialised as valid.

An attacker could potentially exploit this behaviour to execute malicious code.

CVE-2026-109619: Unsafe Information Retained Between Requests

Web servers often reuse PHP worker processes to handle multiple requests.

This vulnerability can leave internal information from an earlier request in an unsafe state.

When the worker handles another request, that leftover information may be used incorrectly.

Again, the potential outcome is remote code execution.

In practical terms, a successful attack could allow someone to run commands on your server without having a legitimate account.

Why Website Security Plugins May Not Protect You

The vulnerabilities sit within PHP itself, beneath the content management system.

Some attack paths can be triggered before WordPress or another application has started running its own code.

A security plugin operating inside the website may therefore have no opportunity to stop the attack.

Apache servers using mod_php have been identified as particularly exposed.

Other configurations, including PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, also require the relevant updates.

This is why a WordPress security plugin or an up-to-date CMS should not be treated as proof that the server is protected.

Why PHP2Shell Puts Business Websites at Risk

An attacker who exploits PHP2Shell may be able to access server files, run unauthorised commands or interfere with your website.

Depending on the server configuration and permissions, that could mean:

• Accessing sensitive customer or business information.
• Changing website files or adding malicious scripts.
• Redirecting visitors to unfamiliar websites.
• Interrupting bookings, purchases or other online services.
• Attempting to access connected applications.

Take an online retailer whose website shares infrastructure with an inventory system or customer database.

If an attacker gains access to the web server, other systems could also be at risk, depending on how they're connected and secured.

Has PHP2Shell Been Exploited?

Yes. There is evidence of real-world exploitation attempts.

Amazon Threat Intelligence reported detecting an exploitation attempt on 17 October 2026, four days before the patches were publicly released.

The NCSC has also acknowledged reports of active exploitation.
On 26 October 2026, CISA added both CVEs to its Known Exploited Vulnerabilities catalogue.

This means businesses should prioritise patching and reviewing potentially affected systems.

However, these reports don't establish that any particular business website has been compromised.

That requires an investigation.

AI-assisted research also played a role in uncovering PHP2Shell. Researchers used AI tools to analyse PHP's internal code and investigate potential weaknesses.

The speed of these developments makes one thing especially important: knowing which software your business relies on and who is responsible for keeping it updated.

Does PHP2Shell Affect WordPress and Other CMS Platforms?

Yes. WordPress websites can be affected, but this isn't a vulnerability in WordPress core.

WordPress confirmed that no core update is required specifically for PHP2Shell.

The security fix needs to happen in PHP.

The same principle applies to other PHP-based platforms.

The complication is that a business may have more than one PHP installation.

Your WordPress marketing site might be patched while a separately hosted booking system is still running an affected version.

A JavaScript-based frontend could also rely on a PHP application in the background.

Your technical team needs to know which systems use PHP, where they're hosted and who maintains them.

This is something we consider when planning website development and integrations at Flight.

When different suppliers manage your CMS, hosting and integrations, it's worth being clear about who handles security updates.

How to Check Your PHP Version and Patch Status

You don't need to understand server configuration to start checking your website.

But someone with access to your hosting environment will need to verify the result.

Step 1: Find Your PHP Version

For WordPress, log into your dashboard and go to:

Tools → Site Health → Info → Server

You'll usually find the PHP version listed there.

You may also find it in cPanel or your hosting provider's dashboard.

If you're using Drupal, Magento or a custom application, ask your hosting provider or developer to confirm the version.

Make sure they're checking the PHP installation handling live website traffic.

A server can have a different version installed for command-line tasks.

Step 2: Confirm That Both Security Fixes Are Installed

Compare your PHP version with the fixed releases listed earlier.

If the server uses a vendor-maintained package, ask for confirmation that both vulnerabilities have been addressed.

Specifically, ask whether the installed PHP package includes fixes for:

• CVE-2026-109618
• CVE-2026-109619

For older versions, your provider should identify the relevant vendor security update or backported patch.

A version number alone may not confirm the security status of a vendor-maintained installation.

Step 3: Confirm PHP Has Been Restarted

Installing a security update is not always the same as running the updated software.

Some PHP processes continue using previously loaded software until they're restarted or replaced.

Depending on the server configuration, your technical team may need to restart PHP-FPM, replace PHP workers, reload the relevant web services or redeploy affected containers.

The exact process depends on your hosting environment.

Your provider should then verify the PHP runtime serving live requests.

This is particularly important for businesses using multiple servers, containers or load-balanced hosting.

Step 4: Check Connected Applications

Don't stop with the main website.

Check whether you have separately hosted:

• Customer portals
• Booking platforms
• Ecommerce applications
• APIs and integrations
• Internal business applications
• Containerised PHP services

Containers need attention too.

If an application includes its own PHP runtime inside a container image, updating the host server won't automatically fix it.

If nobody has a complete list of these systems, ask your technical team to create one.

It should record the hosting provider, PHP version, patch status and person responsible for each application.

Step 5: Verify the Website Still Works

A patched server is only part of a successful update.

Once the technical team has confirmed the fix, test the website functions your customers rely on.

Submit an enquiry form. Log into a customer account. Try a booking or checkout.

Check whether payments and third-party integrations still work.

Your content team should also confirm they can access the CMS and publish updates.

A homepage can load perfectly while a contact form quietly stops sending leads.

That's the sort of issue you want to catch before customers do.

Need Help Checking Your PHP Patch Status?

Not sure which PHP version your website uses or whether the security update has been applied?

Request a free PHP patch check from Flight Digital.

We can help you understand what needs verifying, identify the relevant technical contacts and discuss the next steps for your website.

For suspected compromise or active security incidents, a qualified cybersecurity specialist should lead the investigation.

Request a Free PHP Patch Check

What to Ask Your Hosting Provider About PHP2Shell

f someone else manages your hosting, ask for confirmation of the specific PHP2Shell fixes rather than submitting a general support request about website security.

Your provider should be able to answer:

1. Have CVE-2026-109618 and CVE-2026-109619 both been patched?
2. Which PHP version or vendor package is installed?
3. When was the update completed?
4. Have the relevant PHP services been restarted or replaced?
5. Has the live PHP runtime been verified?
6. Does the patch cover every PHP application hosted under our account?
7. Has any suspicious activity been identified?

If they can't answer, ask for the request to be escalated to their infrastructure or security team.

Email template for your hosting provider

Subject: Urgent PHP2Shell Security Patch Confirmation

Hi team,

We're reviewing our website following the PHP2Shell security advisory.

Could you confirm whether our hosting environment has been patched for CVE-2026-109618 and CVE-2026-109619?

Please include the PHP version or vendor patch installed, when the update was completed and whether the live PHP services have been checked.

Have you identified any suspicious activity, and is there anything we need to do on our side?

Thanks!

Keep their response with your website maintenance records. It'll be useful the next time a security issue affects your hosting environment.

How to Fix the PHP2Shell Vulnerability

The complete fix is to update PHP to a patched release or install a verified vendor-supported security package.

How that happens depends on your hosting arrangement.

For managed websites, the provider will usually handle the server update. Businesses managing their own infrastructure will need their technical teams to deploy the patch.

Before updating

Check that you have recent backups of your website files, database and important configurations.

For more complex websites, arrange compatibility testing where practical.

Your developer should know which applications and integrations need checking after the update.

If your website relies on an older PHP version or custom code, Flight's PHP upgrade services can help assess compatibility, update legacy code and test important functionality before deployment.

Backups provide a recovery option if a deployment fails, but they don't prevent exploitation.

A backup created after a successful attack may also contain malicious changes.

Apply the patch and verify the live server

Update every affected PHP installation.

For supported versions, install the relevant fixed release or later security update.

If you're using an older version maintained by a hosting or operating system vendor, confirm that its security package addresses both PHP2Shell vulnerabilities.

Don't assume that updating the main website automatically updates every connected application.

Restart PHP and Verify the Live Server

Once the new software is installed, relevant services and PHP workers may need restarting or replacing.

Then verify the live runtime.

That means confirming that the software handling actual website requests contains the fix, rather than relying only on an installation report or command-line version check.

For websites running across several servers or containers, each affected instance needs checking.

Test the functions your customers use

A successful server update doesn't necessarily mean everything on your website is working.

Test your:

• Enquiry forms and lead notifications
• Customer login and account functions
• Ecommerce checkout and payments
• Booking and appointment systems
• CMS editing and publishing
• APIs and third-party integrations

Once testing is complete, record the patch version, deployment date and anything that still needs attention.

Temporary Protections While Waiting for a PHP Patch

Sometimes an update can't happen straight away.

Your hosting provider might be preparing patches across multiple servers, or an important application may need compatibility testing.

During that gap, temporary protections may reduce the risk.

Important: Temporary mitigations are not a fix.

They may block particular attack methods, but they do not remove the vulnerabilities in PHP.

Apply the security patch as soon as possible.

Can a firewall help?

A web application firewall (WAF) can filter certain suspicious requests before they reach PHP.

AWS has published PHP2Shell mitigation guidance covering known attack patterns.

These protections depend on correct configuration.

They may not cover every exploit path, especially if traffic can reach the server without passing through the firewall.

What about PHP configuration changes?

The PHP project has documented settings that can reduce particular attack paths.

One example is session.upload_progress.enabled=0, which disables functionality involved in a known exploitation path for CVE-2026-109619.

That change does not fix CVE-2026-109618 or provide complete protection against the other vulnerability.

Other potential controls involve memory handling and request limits.

These need careful assessment because changing them can affect legitimate website functions or introduce resource problems.

Some protections must also be applied at the PHP or server configuration level.

Changing settings inside application code may be too late to prevent the vulnerable behaviour.

Your hosting provider or system administrator should assess and verify any temporary changes.

Should you take the website offline?

Signs Your PHP Server May Have Been Compromised

The NCSC recommends considering this option when immediate patching isn't possible.

Taking a business website offline isn't ideal, particularly when it handles enquiries or sales.

But keeping an exposed server online could create far greater problems.

The decision should be based on the actual security risk and the protections available.

Signs Your PHP Server May Have Been Compromised

A compromised website won't always look broken.

Visitors might still be able to browse pages, submit forms and complete purchases while suspicious activity is happening behind the scenes.

After patching, ask your hosting provider or security specialist to review relevant activity dating back to at least 17 October 2026, the earliest attempted exploitation reported by Amazon Threat Intelligence.

A single error or unusual request doesn't prove PHP2Shell was exploited.

Investigators need to examine the timing and other evidence.

If you suspect someone gained access, preserve the relevant logs and files.

Don't immediately delete suspicious material or rebuild the server before a qualified incident response specialist has assessed what happened.

A security specialist needs to confirm whether access was gained, what was affected and what needs fixing before the system can safely return to normal.

Can PHP2Shell Affect Your Website's SEO?

PHP2Shell isn't a Google ranking factor.

The SEO problems arise when an attack or emergency maintenance affects the website.

An attacker might change content or create malicious redirects.

Taking the site offline could also leave important pages temporarily unavailable to Google.

A short outage isn't necessarily a problem for rankings.

Persistent errors or prolonged downtime, however, can affect crawling and indexing.

Use HTTP 503 during short maintenance periods

If your website needs to go offline temporarily, Google recommends returning HTTP 503 Service Unavailable.

This tells Google that the interruption is temporary.

For an urgent shutdown lasting one or two days, a static maintenance page returning 503 is generally appropriate.

It should explain the interruption and give customers another way to contact the business.

If PHP needs to be disabled, the maintenance page should be served without invoking the vulnerable application.

Google advises against keeping an entire website offline for longer periods.

For extended closures, its guidance discusses using an indexable homepage placeholder returning HTTP 200.

Any such page must be served from a safe environment.

What should happen during maintenance?

Your hosting or development team should make sure:

• Temporarily unavailable pages return HTTP 503.
• The maintenance page uses static HTML.
• A Retry-After header is included where appropriate.
• robots.txt remains accessible without unnecessary crawl restrictions.
• No accidental noindex directives are added.
• Normal HTTP responses are restored when the website reopens.

Avoid using permanent redirects or 404 errors simply to display a maintenance message.

Check Google Search Console after the website reopens

Once the security team has confirmed the website is safe, review the pages responsible for traffic, enquiries and revenue.

Focus on four areas.

Page Indexing and URL Inspection

Check whether important pages remain accessible and indexable. Look for new server errors, exclusions or unexpected indexing directives.

Crawl Stats

Review server responses and host availability. Temporary 503 errors during maintenance may be expected. Continued errors after reopening need investigation.

Search Performance

Compare clicks, impressions and average positions before and after the outage.

Use GA4 alongside Search Console to understand any changes in organic visits, enquiries and conversions.

Security Issues and Redirects

Check for warnings about compromised content. Confirm that important URLs still resolve correctly and your XML sitemaps remain accessible.

If the incident or maintenance caused indexing problems, Flight Digital's technical SEO team can help assess the effects on crawling, indexation and organic search performance once the website is secure.

What New Zealand Businesses Should Review After Patching

The immediate concern is closing the vulnerabilities.

Once that's done, it's worth checking whether your business is prepared for the next critical software update.

Start with responsibility.

Who maintains the PHP runtime?

Who manages the CMS?

Who checks the hosting environment?

And who gets contacted if something goes wrong outside normal business hours?

Those responsibilities aren't always covered by the same supplier.

A business may have a WordPress maintenance agreement but no clear owner for server updates.

Another might have several applications hosted by different providers.

Neither arrangement is necessarily a problem, provided everyone knows what they're responsible for.

Your Website Maintenance Checklist

After PHP2Shell, make sure you have:

• A record of the software and PHP versions used across your systems.
• Confirmation that the required security patches were applied.
• Working backups and a tested recovery process.
• Regular server and website monitoring.
• A clear contact for urgent technical issues.
• A process for testing important website functions after updates.
• A plan for replacing unsupported software.

If you're planning a website rebuild or CMS migration, these requirements should be considered during development.

Our Headless CMS SEO checklist covers other technical considerations, including crawlability, URLs, metadata and how development decisions affect search performance.

A different CMS won't automatically solve security maintenance.

Whatever technology your business uses, someone still needs to look after it.

Keeping Your Website Secure, Functional and Visible

A vulnerable PHP installation isn't something customers can see. But if it leads to downtime, failed enquiries or a compromised website, they'll feel the impact.

The same goes for updates that aren't properly tested.

A security patch might fix the underlying server issue while accidentally breaking a booking form or interrupting an important integration.

Before signing off on the update, test the parts of the website your customers rely on.

At Flight, we don't stop at checking whether a website is back online. We also look at whether its key pages are accessible, enquiry forms are working and Google can still crawl the content.

Our development and SEO teams can help businesses review their website setup, plan technical improvements and investigate issues affecting functionality, crawling and organic performance.

If your website needs specialist cybersecurity investigation, that work should be handled by a qualified security professional.

Need a clearer picture of your website's technical health?

Talk to Flight Digital about your website, the systems supporting it and how to keep your digital experience performing.