PHP2Shell and the patch wave: three things your business should be able to show 

PHP2Shell, the PHP flaw that made the news in October, was a reminder of how quickly a software weakness can become a practical problem. Governments across Europe temporarily took public websites and services offline while they applied fixes. If you run a UK business, the practical test is whether you could make a sensible decision quickly if a serious flaw hit a system your organisation relies on, whether or not you use PHP directly. 

PHP is software used behind many websites and online services. The issue had existed for years, but researchers used artificial intelligence tools to build a working attack far more quickly than would previously have been practical. That matters more than the PHP bug itself. For years, flaws like this were rated as complex and unlikely to be exploited, and businesses scheduled their fixes accordingly. AI has made exploiting them far cheaper, so that rating can no longer be relied on. The gap between a fix being published and attackers using it is shrinking towards the time it takes a model to read the fix. 

My view is that we should expect more moments like this, where urgent fixes need attention at once across software you use, software your suppliers use, and software you may not even realise sits inside your own infrastructure. Being ready means having enough information to decide what matters, who can act and what you would do if a supplier stepped away for a day. 

1. Know what your organisation has exposed online

The first problem in a fast-moving software issue is often simply finding out whether the affected technology exists in your business at all. If you do not know which systems are available online, you cannot quickly work out whether an urgent update applies to you. 

Start with a simple spreadsheet of the systems your organisation exposes to the internet. Include domains, websites, customer and supplier portals, remote access services, online administration pages and connected appliances. For each entry, record who owns it internally, who hosts or supports it, whether its software is still supported, and the contact details you would use if an urgent change were needed. 

Include any connections your website or product uses to exchange data with other systems (often called APIs), as these are exposed too. 

On the same sheet, note the software and services the business runs on day to day. Include systems created or connected by staff, including tools developed with AI assistance, where appropriate. The practical test is whether you could answer two questions within an hour or two of a major announcement. Do we use this product, and where is it used? 

For a small professional services firm, the list might include a public client portal, an old marketing site and a remote desktop service used by a small group of staff. The marketing site may no longer have a business purpose. The remote service may not need to be publicly accessible. Removing or restricting either one reduces the number of systems that need attention later. 

Unsupported software deserves particular attention because it may no longer receive security updates from its maker. If you are working towards Cyber Essentials, keeping unsupported software out of use supports that work. This is also part of vulnerability management, the routine process of identifying weaknesses and deciding how to handle them. 

2. Make sure someone can act when it matters

Knowing that you use an affected system is only useful if someone can make a decision about it. An urgent patch may need approval outside office hours, and the person who understands the business impact may not be the person who applies the technical update. Agreeing those roles in advance avoids trying to resolve both questions at the same time. 

For each important system, record how it would be patched, who would do the work, how long it is likely to take and whether the system could be temporarily taken offline. Cyber Essentials expects critical and high-risk fixes within 14 days. For an internet-facing system during an active patch wave, that period should be treated as a limit rather than a target to work towards. 

Prioritisation should reflect both exposure and evidence that attackers are using a flaw. The CISA Known Exploited Vulnerabilities catalogue is a free list that can help identify weaknesses known to be exploited. A serious issue on an internal system that cannot be reached from outside may be less urgent than a lower-rated issue on a public login page. 

Where software can update itself automatically, let it. The NCSC’s patch wave guidance recommends updating by default, and for most small businesses that removes a large share of the work before anyone has to make a decision. 

Consider a local firm with a client portal hosted by a third party. Its office manager has the hosting provider’s emergency contact details and knows which director can authorise a temporary shutdown. If an urgent update is announced, the business can establish its options, decide whether the portal should stay available, and give clients a clear explanation if access is interrupted. 

A web application firewall is a service that filters some harmful traffic before it reaches a website. It can provide additional protection while a fast-moving issue is being assessed, but it does not replace a patch. The NCSC Early Warning service is also free and can help the appropriate people in your organisation receive relevant alerts. 

Patching is also not the end of it. With PHP2Shell, exploitation was reported before fixes were available, so any affected system that was online before you patched should be checked for signs of compromise as well as updated. Part of acting quickly is knowing when to stop a service safely. Keep logs in a place an attacker cannot easily remove, maintain offline backups and check that they can be restored. If you need an independent view of which public systems need attention, Cyber Alchemy can carry out external infrastructure penetration testing to show what an attacker could reach and give you a clear record of the issues and priorities to address.

3. Plan for suppliers taking services offline

Your own systems are only one part of the picture. A payroll provider, booking platform, payment gateway or online service may temporarily take itself offline to apply a critical fix. That may be the responsible decision for the supplier, but it can still affect your ability to serve customers or complete routine work. 

Choose the five to ten suppliers whose absence would materially disrupt your organisation. For each one, record the supplier’s status page or a named contact, the person internally who can approve a workaround, and what your team will do for 48 hours. 

A retailer that relies on a payment provider and delivery-booking service might agree an alternative process for taking orders and scheduling deliveries until those services return. The right workaround will differ by business and should be checked against your payment, data protection and operational requirements. The important point is to try the process once rather than assume it will work when people are under pressure. 

Ask key suppliers how they communicate serious issues and whether they may take a service offline to apply an urgent update. At renewal, where you have the opportunity, discuss notification and fix timescales. Where the supplier won’t move on its terms, and the big ones generally won’t, your own tested fallback is what protects you. 

If your organisation builds software

Your customers will need the same clarity from you. Keep an accurate record of the components used in your product, including those provided by third parties. When the next significant issue emerges, you should be able to establish whether you are affected without searching through old projects for days. 

Measure the time between an upstream fix becoming available and your customers receiving it. Revisit older code that was previously considered difficult to exploit, and avoid building new work on unsupported components. A customer notice prepared in advance can explain whether you are affected, what action is under way and when you expect to provide a further update. During PHP2Shell, the suppliers who sent a clear ‘affected or not, fixed by when’ note earned trust. The silent ones left customers assuming the worst. 

If responsibility for this work needs to sit clearly with leadership, a vCISO cyber strategy service can help maintain the roadmap, responsibilities and security artefacts as the business changes. 

Questions business owners ask

What is a vulnerability patch wave? 

It’s the NCSC’s term for a rush of urgent software updates across the whole technology stack, driven by AI making long-standing flaws much easier to find and exploit. The NCSC advises every organisation, whatever its size, to prepare for it now. 

Does the PHP issue affect my business if we do not build websites? 

It may do. PHP can be used within websites, devices, phone systems and services managed by other organisations. Your list of internet-facing systems and critical suppliers should help you establish whether it is present and who is responsible for the relevant service. 

What should we do first when a serious vulnerability is announced? 

Establish whether your organisation uses the affected product, whether any affected system is available online, who can authorise action, and whether anything exposed needs checking for compromise. The NCSC guidance on preparing for a vulnerability patch wave, the NCSC Early Warning service and the CISA Known Exploited Vulnerabilities catalogue are useful starting points for prioritising that response. 

None of this is exotic. Most of it is cheap, dull and easy to put off. What’s changed is the clock. Keeping this current gives you a more controlled starting point when the next issue arrives. 

If you would like help turning this into a practical security roadmap, get in touch.