Short answer: Ask your hosting provider whether your websites or applications use affected PHP installations, get written confirmation of the fixes, and ask whether they have checked for signs of compromise. Patching is urgent; an exploitation attempt or precautionary shutdown is not proof of a breach.

Information checked on 24 October 2026 (London). General operational guidance, not a technical assessment of your website. Security advice can change; check the linked live advisories with your provider.

Your website can look perfectly healthy while the software underneath it needs an urgent security update. For a business owner, that creates an uncomfortable question: would you know who to call, what needs checking and how quickly your team could act?

This week’s PHP security emergency has made that question immediate. Two critical vulnerabilities, widely discussed as PHP2Shell, prompted urgent updates and precautionary service shutdowns. The flaws are serious. Understanding exactly what has happened is the first step towards responding sensibly.

What actually happened?

On 21 October 2026, the PHP project released fixes for two vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Under exploitable conditions, they can allow an attacker to execute code on an affected server without logging in. This is known as unauthenticated remote code execution. Exposure and attack conditions depend on the deployment and configuration. [1]

PHP is software used on servers to run websites and applications. It remains actively developed; describing it simply as the way “old websites” were built misses the point. A recently redesigned website can still depend on PHP underneath its pages.

These vulnerabilities concern PHP’s handling of memory and internal request state. Under exploitable conditions, a request can interfere with the server’s normal operation and allow an attacker’s code to run. The weakness is in the underlying runtime, so refreshing a website’s design does nothing to resolve it. [1]

For businesses, the potential consequences include disruption, unauthorised changes and exposure of information accessible to the compromised application. Exactly what an attacker could reach depends on the system and its permissions.

Did Wikipedia get hacked?

The evidence reviewed for this article does not establish that Wikipedia was breached.

Wikimedia’s own incident page says it took certain services offline as a precaution while applying patches. Those services included Toolforge, Cloud VPS and Phabricator. Its 23 October update says Phabricator was fully restored, while some Cloud VPS projects and PHP-based Toolforge services were still unavailable. That is evidence of a substantial operational response, not proof that attackers took control of Wikipedia. [2]

The same distinction matters when reading wider headlines. A vulnerability is a weakness. An exploitation attempt is an effort to use it. A confirmed compromise means that an attacker actually succeeded. A website going offline can also be a deliberate protective measure.

Amazon Threat Intelligence recorded an attempted PHP2Shell exploit in its MadPot honeypot network on 17 October, before the fixes were released. Its current account describes broad exploitation attempts, but also says it is unclear whether the early attempts would have succeeded against real-world systems. [3]

The threat deserves urgent action. It does not justify treating every exposed website as a confirmed breach.

How could a problem remain unresolved for so long?

The story is more complicated than a bug that nobody noticed for a decade.

According to the PHP Foundation, developers identified early signs of the out-of-memory problem in 2024. At that stage, a possible exploit had been theorised, but a concrete attack route had not been established. Proposed fixes involved difficult compatibility and engineering trade-offs. The Foundation acknowledges that limited resources and its decision-making process delayed resolution. [4]

In August 2026, researchers demonstrated a practical remote code execution route, making the impact clearer and the fix a top priority. The Foundation also describes using AI tools in security research and validation, alongside human engineers who assess reports and develop patches. [4]

For business leaders, this is a useful reminder that discovering a problem, understanding its consequences and deploying a reliable fix are separate pieces of work. Each needs resources and someone able to make decisions.

AI is changing the time available to respond

AI’s role here extends beyond finding weaknesses.

Amazon warns that AI-assisted analysis makes it easier to turn technical disclosures and software changes into working exploits. Its advice is to measure responses to critical vulnerabilities in internet-facing systems in hours. It also recommends that investigations into PHP2Shell consider activity from at least 17 October. [3]

Our operational takeaway is straightforward: an emergency plan cannot begin with finding out which supplier owns the server.

Consider a small business whose website enquiries feed into a CRM and then trigger automated follow-ups. During a security incident, the team needs to know which connections exist, what access they have and whether enquiries can still be handled safely. That visibility is part of building dependable automation.

What should business owners do now?

  1. Establish whether PHP is involved. Ask your hosting provider or developer to check the live website, customer portals, older subdomains and other applications. CERT-EU notes that third-party products can also contain PHP, making exposure less obvious. [5]
  2. Get specific confirmation of the fix. The initial patched upstream releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Your provider should confirm the applicable patched release or vendor package, deployment time and verification. Older installations may require an upgrade or a vendor-provided backport. Vendor packages can use different version numbers, so confirm their security status with the operating-system or hosting provider rather than judging only by the upstream number. [5]
  3. Check the follow-up advisory. On 23 October, PHP published informational guidance for CVE-2026-115560. It concerns an unusual configuration where an application switches its session serialisation handler at runtime before starting a session, with session upload progress enabled. PHP recommends disabling session upload progress until the next regular bugfix release to cover this unlikely vector. Applications that do not switch the handler at runtime can leave the feature enabled. Ask your administrator to check the exact conditions in the advisory; this is not evidence that every PHP application is affected. [1]
  4. Agree what happens if updating is delayed. CERT-EU advises considering isolation of affected internet-facing applications until fixes are applied and verified. Temporary mitigations do not fully resolve the original pair of vulnerabilities. This decision belongs with the responsible technical team. [5]
  5. Ask about investigation as well as patching. Amazon recommends reviewing server logs, unexpected process execution and file changes. Installing a fix does not, by itself, establish that an earlier compromise never happened. [3]

A useful message to your provider is:

Message to your provider: Please confirm whether any of our websites or applications use affected PHP installations, which fixes have been applied, whether the 23 October advisory is relevant, and whether you have checked for signs of compromise. Please include any outstanding actions and the person responsible for completing them.

Make maintenance part of how the business works

For a founder, reliable systems start with a few practical records: what the business runs, who owns each service, which supplier maintains it and how an urgent change is approved. Add a tested recovery process and a clear route for communicating service disruption.

These records need to be usable when the usual developer is unavailable or the person who commissioned the website has left.

At Decode & Grow, our emphasis on clear processes, documentation and ownership applies here too. Automation becomes more dependable when the systems around it are understood and maintained. An emergency like PHP2Shell exposes how much a business relies on those foundations.

Start with one concrete action today: get a clear, written answer from the person responsible for your website’s hosting and maintenance.

Need a clearer picture of how your tools, suppliers and workflows connect? Start with a free systems audit and a conversation about your business systems.

Sources

  1. PHP — 21 October security release and 23 October session upload progress advisory
  2. Wikimedia — PHP security update community incident notice
  3. Amazon Threat Intelligence — PHP2Shell exploitation attempts before public disclosure
  4. The PHP Foundation — Today’s PHP Security Release, and How We’re Strengthening PHP Security
  5. CERT-EU — Critical Vulnerabilities in PHP (updated 23 October)