PHP2Shell: Is Your NZ Business Website Affected?

Developing story. This post reflects publicly available information as of 23 October 2026 (NZT)

On 21 October 2026, PHP released emergency fixes for two critical vulnerabilities in the programming language that W3Techs says runs 70.5% of websites whose server-side language it can identify (August 2026). The flaws, collectively named PHP2Shell, can let an attacker take control of a web server without logging in. Insurance Business NZ reported that both carry a severity rating of 9.2 out of 10.

The NCSC issued an alert the same day, advising New Zealand organisations to apply the fix as soon as possible and to investigate affected systems for signs of compromise. In the agency's words: "The NCSC is aware of reports of active exploitation."

For most NZ businesses, PHP is not something anyone thinks about. It sits underneath the company website, the WordPress site an agency built three years ago, the online booking system and the client portal. That is the problem PHP2Shell exposes. The systems most likely to be affected are often the ones nobody in the business is actively responsible for.

The timing makes it more pressing. Amazon Threat Intelligence reported seeing a PHP2Shell exploitation attempt on 17 October, four days before the flaws were publicly disclosed. A website patched promptly this week may still have been exposed before a patch existed.

This post covers what PHP2Shell is, why it matters for NZ businesses, who is responsible for fixing it, and what to check once the patch is applied.

What Is PHP2Shell?

PHP2Shell is the name given to two critical vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619. PHP is the server-side language that builds web pages each time someone visits them, pulling content, product listings, account details and login screens from a database and sending the result to the browser. It underpins WordPress, Drupal, Magento and a large share of the hosting platforms NZ businesses use.

Both flaws allow unauthenticated remote code execution. In plain terms, an attacker can send a request to a vulnerable web server and run their own commands on it, without needing a username or password. Once that access exists, the attacker can alter or deface the website, steal the data it handles, plant tools for later use, or use the server as a stepping stone into other connected systems.

The flaws sit in PHP itself rather than in any individual website's code. A site built carefully by a competent developer is still exposed if the PHP version underneath it hasn't been updated.

How the Disclosure Unfolded

The timeline matters, because it explains why the usual window for patching was so short.

• August 2026: Security firms Calif and Wiz identified the flaws using frontier AI models and reported them to the PHP security team under coordinated disclosure.

• 17 October: Amazon Threat Intelligence recorded an exploitation attempt against its honeypot network, four days before public disclosure.

• 20 October: Technical details leaked online ahead of the planned release date.

• 21 October, 14:00 UTC: PHP brought its release forward and published fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. In New Zealand, that was the early hours of Thursday 22 October.

• 22 October: The NCSC published its alert and advised immediate patching. Cyber agencies in Australia, Singapore, the Netherlands, the UK and the US issued their own warnings over the same two days.

Sansec reported that the underlying bugs are present in every unpatched version of PHP since 5.4. Wiz has described them as having sat in PHP's code for decades.

Why Does PHP2Shell Matter for NZ Businesses?

The NCSC has noted that PHP is used by New Zealand organisations in a significant number of websites and web services. Three factors turn PHP2Shell into a business risk for the companies running those sites.

Business websites hold more than they used to

A decade ago, a small business website was largely a digital brochure. Today it is often a working business system. Clinics and service businesses take bookings online, law firms and accountancies run client portals, and most businesses collect personal information through enquiry or application forms. Retailers process orders and payments through e-commerce stores.

Each of those functions connects the website to something else: a CRM, an email marketing platform, a payment gateway, a practice management system. Those connections rely on stored passwords, tokens and API keys. A compromised web server can expose all of them.

The memory disclosure risk

Remote code execution has dominated the coverage, but it isn't the only impact. Wiz demonstrated that an attacker could read the PHP process's memory, including passwords, tokens and API keys belonging to other visitors' requests, without running any code at all.

This matters because it leaves very little trace from the outside. A website can stay online, function normally and show no sign of disruption while credentials are read from memory. The businesses that patched quickly and never lost availability are, as Insurance Business NZ noted, often the least likely to review their logs.

Older PHP versions have no simple fix

Official fixed releases exist only for PHP 8.2 to 8.5. Sansec reported that the PHP security team has published source patches for versions 7.4, 8.0 and 8.1, and some Linux distributions have backported fixes, but sites on older releases have no simple update to install.

W3Techs data from August 2026 shows 62.5% of PHP websites run version 8. The remainder are on older versions with no official fixed release. For businesses whose websites haven't been actively maintained since launch, the fix may involve a full upgrade project.

Who Is Responsible for Patching Your Website?

This is the question PHP2Shell forces most NZ businesses to answer, and many can't answer it quickly. The responsibility depends on how the website is hosted, and in many SMEs that arrangement was set up years ago by someone who is no longer involved.

Shared hosting - The website sits on a hosting provider's server alongside other customers' sites. The provider manages PHP and is responsible for applying the update. Insurance Business NZ noted that businesses in this position depend entirely on their provider to patch.

Managed WordPress or managed hosting - The provider typically manages PHP versions and applies security updates, often automatically. It is still worth confirming that the update has been applied and that services were restarted.

A cloud or virtual server - If the website runs on a server the business rents and administers, whoever administers it is responsible. That might be an internal staff member, the original developer or an IT provider. This is the arrangement most likely to have no clear owner.

An on-premises server - Websites hosted on the business's own infrastructure fall to the internal IT team or the IT provider that manages that infrastructure.

A fully hosted website builder - Platforms that run the servers on the customer's behalf handle the underlying software, including PHP where they use it.

The ownership problem

In many SMEs, the website sits outside the IT arrangement entirely. Marketing commissions the site, an agency or freelancer builds it, and the IT provider manages laptops, email, Microsoft 365 and the network. Each party can be doing its job well while the web server falls between them.

This is the same pattern the NCSC's post-incident analysis identifies across basic security controls. The control exists in principle, but nobody owns its ongoing maintenance.

Insurance Business NZ's advice to businesses following the disclosure was direct: find out who manages PHP on your website and get written confirmation that it has been updated. That written confirmation serves two purposes. It verifies the fix, and it creates a record if an insurer, regulator or client asks later.

What Should NZ Businesses Do Right Now?

The NCSC's guidance is to patch immediately and investigate for compromise. For a business that doesn't manage its own web servers, that translates into five specific actions.

Confirm which PHP version the website runs - The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or a vendor-patched equivalent supplied by the hosting provider or Linux distribution. Anything else should be treated as vulnerable.

Confirm the update was applied and services restarted - watchTowr's guidance is to restart every PHP worker after installing the update so the fix takes effect across the environment. An update installed without a restart may leave the vulnerable code running.

Investigate from 17 October onwards - Amazon Threat Intelligence advises starting investigations from the earliest known exploitation attempt. A server patched on 22 October still had at least five days of exposure before the fix existed.

Plan for older versions - Sites running PHP 8.1 or earlier need a specific plan from whoever manages them. Where an affected service can't be updated straight away, the NCSC recommends considering temporarily disabling public access to it.

Document the outcome - Record who confirmed the update, when it was applied and what checks were run. That record is what an insurer or regulator will ask for if something surfaces later.

A message to send your host or developer

Most SME owners won't be checking servers themselves. What they can do is ask the right questions of whoever is responsible. The following can be sent as is:

Hi [name],

Following the NCSC alert on the PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619), can you please confirm in writing:

1. Which PHP version our website runs, and whether it has been updated to a fixed release
2. When the update was applied, and whether PHP services were restarted afterwards
3. Whether you have checked for signs of unauthorised access from 17 October onwards
4. If we are on an older PHP version, what you recommend we do next

Thanks, [your name]

The response is informative in itself. A prompt, specific answer indicates the website is actively maintained. A vague answer, or none at all, indicates it probably isn't.

Does Patching Mean Your Website Wasn't Compromised?

A patch closes the vulnerability. It provides no information about what happened while the vulnerability was open.

The exposure window for PHP2Shell started before most businesses had any opportunity to act. Exploitation attempts were recorded on 17 October, and proof-of-concept exploit code circulated publicly on 20 and 21 October, while fixes were still being finalised. A business that patched within hours of the release still had a period of exposure it couldn't have prevented.

This is the dwell time problem in a specific form. As we covered in our post on how long your business was exposed before anyone noticed, the period between initial access and detection is where most of the damage in a cyber incident happens. An attacker who gained access to a web server before the patch was applied keeps that access after the patch, unless someone finds it and removes it.

What a compromised server looks like

Security firm Huntress has published guidance on the signs to look for on a PHP server that may have been exploited:

• Web shells - Unexpected files in the website's directories, which give an attacker a way back in

• New files in the web root - Anything added that nobody on the website team recognises

• Scheduled tasks and cron jobs - Automated jobs set up to run attacker commands or re-establish access

• New accounts - User accounts on the server or in the website's admin area that nobody created

If any of these are found, Huntress advises isolating the server and preserving the web server and PHP logs before anything is cleaned up. Those logs are the evidence an incident response investigation relies on.

Credentials are the longer-term risk

The memory disclosure flaw means credentials may have been exposed even where no files were changed. Where there is any doubt, the website's credentials should be rotated: administrator logins, database passwords and the API keys that connect the site to payment providers, CRMs and email platforms.

Stolen credentials rarely stay on the system they were taken from. A password harvested from a website admin area is often tried against Microsoft 365, cloud platforms and other business systems, particularly where staff reuse passwords. That is the activity continuous monitoring is designed to catch. NSP's Managed Detection and Response service watches identity, email, endpoint and cloud activity around the clock, so a login using stolen credentials is investigated when it happens instead of being discovered weeks later.

How Widespread Is PHP2Shell Exploitation?

As of 23 October 2026. 

The security industry's assessment is still forming, and the early reporting points in two directions.

The case for urgency - Amazon Threat Intelligence states that PHP2Shell is now being broadly exploited in the wild, with attempts coming from multiple actors using different payloads and anonymised infrastructure. SecurityWeek reported that watchTowr is observing broad exploitation attempts, and that VulnCheck recorded at least one attempt to deploy a web shell. Cloudflare, Patchstack and Hadrian all reported attack activity on or before release day.

The case for measured concern - Sansec revised its view on 22 October. It now assesses mass exploitation as less likely than initially expected, because a successful attack needs specific knowledge of the target server and specific conditions on it, and the public exploits don't work against a default PHP installation. watchTowr also noted that the proof-of-concept code it had seen circulating did not achieve remote code execution. Sansec's advice remains to update regardless.

The NCSC position - The NCSC is aware of reports of active exploitation and has advised New Zealand organisations to apply the fix as soon as possible and to investigate for compromise.

At the time of writing, we have not seen a public report of a New Zealand organisation being compromised through PHP2Shell.

For a business deciding what to do, the disagreement changes very little. Both assessments end with the same instruction: update PHP, confirm the update, and check for signs of access. The difference between the two views is how many organisations will be caught out. The way to avoid being one of them is the same either way.

What Are the Privacy Act and Cyber Insurance Implications?

PHP2Shell is a technical vulnerability, but the consequences of a compromise land in legal and financial territory.

The Privacy Act 2020

Under the Privacy Act 2020, a privacy breach that has caused or is likely to cause serious harm must be notified to the Office of the Privacy Commissioner and to affected individuals as soon as practicable. Any website that handles customer logins, bookings, enquiries, applications or payments processes personal information as part of its normal operation.

Insurance Business NZ highlighted a specific point about this incident: a server that leaked session data could create a notifiable breach even if the website never went down. That shifts how a website incident should be assessed. The question becomes what information passed through the server during the exposure window and whether it could have been read, in addition to whether anything visibly broke.

The Privacy Commissioner's recent enforcement action following the December 2025 patient portal breach, including Compliance Notices issued for failures against security requirements, shows that the regulator examines what safeguards were in place at the time of an incident. A documented record of when PHP was patched and what checks were run forms part of that picture.

Cyber insurance

For businesses with cyber cover, three points from Insurance Business NZ's coverage are worth acting on now.

Check for an insurer alert - Some insurers notify policyholders when a major vulnerability is disclosed, and may set expectations about response.

Expect questions about patch speed - Underwriters may want to know how quickly a client patched once a fix was available. The written confirmation from your host is the evidence.

Report anything suspicious promptly - Where a server left unpatched shows signs of compromise, the incident should be reported to the insurer early. Late notification can complicate a claim.

Businesses that took their website offline as a precaution should not assume the lost trading is covered. Whether a policy responds to a voluntary shutdown depends on its wording and waiting period, and few policies cover it explicitly. Websites hosted on a provider's shared servers raise a further question: if the provider's outage causes the loss, contingent business interruption cover applies, which isn't standard and often carries a sub-limit. For most businesses, a short conversation with their broker this week will answer these questions.

What Does PHP2Shell Say About How Vulnerabilities Are Now Found?

The most significant detail in the PHP2Shell disclosure may be how the flaws were discovered. Both Calif and Wiz used frontier AI models to find weaknesses that had sat undetected in one of the most widely used programming languages on the internet for decades.

The NCSC's Cyber Threat Report 2026 urged business leaders to prepare for a threat environment being transformed by AI. PHP2Shell is a concrete example of what that looks like. The same class of tools that found these flaws for defenders is available to attackers, and the time between a vulnerability becoming public and exploitation attempts beginning was measured in hours this week.

For NZ businesses, the practical implication is that the volume and pace of critical vulnerabilities in widely used software is likely to increase. A patching process that relies on someone noticing a headline will not keep up.

What a sustainable approach looks like

The NCSC's message on basic security has been consistent for years, and PHP2Shell reinforces it. As we covered in our post on why NZ businesses are still getting hit despite basic cyber hygiene working, the controls that matter are well understood. The challenge is applying them consistently.

For public-facing systems like websites, that means three things.

An accurate inventory - A current record of every public-facing system the business runs: the website, where it is hosted, what it is built on, which version of PHP and other software it uses, and who is responsible for it.

Defined ownership of updates - A named person or provider responsible for applying security updates, with an agreed timeframe for critical patches and a record of when they were applied.

Continuous visibility - Regular scanning to identify known vulnerabilities before attackers do, and monitoring to detect when something has been exploited despite those efforts.

This is the work vulnerability management is designed to do: identifying known weaknesses across a business's systems, prioritising them by risk and confirming they have been fixed. PHP2Shell is a high-profile example. Most critical vulnerabilities are disclosed without the headlines, and they need the same response.

Frequently Asked Questions

What is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the PHP programming language, tracked as CVE-2026-109618 and CVE-2026-109619 and disclosed on 21 October 2026. Both allow an attacker to run code on an affected web server without logging in, and both are rated 9.2 out of 10 for severity. PHP underpins WordPress, Drupal, Magento and many hosting platforms used by NZ businesses.

How do I know if my business website is affected?

If your website runs on PHP and hasn't been updated to version 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor-patched equivalent), treat it as affected. Most WordPress, WooCommerce, Drupal and Magento sites use PHP. The quickest way to confirm is to ask whoever manages your hosting which PHP version the site runs and when it was last updated.

Does PHP2Shell affect websites built on Wix, Squarespace or Shopify?

Fully hosted website builders manage the underlying servers on their customers' behalf, so applying security updates is the platform's responsibility. Customers of these platforms have no PHP version to update themselves. Businesses concerned about a specific platform should check its status or security page for a statement on PHP2Shell.

Should I take my website offline?

Not as a default response. If the update has been applied and the server has been checked for signs of access, the website can continue operating. The NCSC recommends considering temporarily disabling public access only where an affected service can't be updated straight away.

My website has been patched. Do I still need to do anything?

Yes. Amazon Threat Intelligence recorded exploitation attempts from 17 October, before fixes existed, so the server should be checked for signs of access from that date onwards. Where there is any doubt, the website's administrator passwords, database credentials and API keys should be changed, because one of the flaws can expose them without leaving visible changes on the server.

Do I need to report PHP2Shell to the NCSC or the Privacy Commissioner?

Applying the update does not need to be reported. If the investigation finds signs that the server was accessed without authorisation, the incident can be reported to the NCSC, and the business should assess whether personal information was exposed. A privacy breach likely to cause serious harm must be notified to the Privacy Commissioner and affected individuals under the Privacy Act 2020. Cyber insurers should also be notified early.

Who Is Looking After Your Systems?

PHP2Shell will be patched and largely forgotten within weeks, and the same question will come up again with the next critical flaw. For most NZ SMEs, the real exposure this week was the website nobody was clearly responsible for maintaining.

NSP's managed services put a dedicated team in charge of the work that tends to fall between the cracks: applying updates, monitoring systems and resolving issues before they become incidents. A conversation with our team covers what you run today, who maintains each part of it, and where responsibility is unclear.

Talk to our managed services team →

Or call us directly: 0508 010 101

Related Reading

• How Long Was Your Business Exposed Before Anyone Noticed?
• Basic Cyber Hygiene Works. Why Are NZ Businesses Still Hit?
• Vulnerability Management - NSP
• Managed Detection and Response - NSP
• Managed Services - NSP