South African web hosts race to patch PHP2Shell as early attacks raise the stakes

South African hosting providers are rushing security updates for two critical flaws in PHP, the software used by a large proportion of websites. The vulnerabilities, collectively called PHP2Shell, can allow attackers to run code remotely without logging in under affected configurations. Afrihost, Xneelo and 1-Grid have all described their response to customers.

The flaws are CVE-2026-109618 and CVE-2026-109619. The PHP development team issued emergency security releases on 21 October after a leak forced disclosure earlier than planned. Ubuntu confirmed that the two issues carry critical severity assessments and that patched packages are available for its supported systems.

The local question is whether patches have reached every relevant server. A provider updating its managed hosting fleet does not automatically secure a customer's self-managed virtual server, application container or unsupported PHP installation.

Patches are available

The upstream corrected PHP releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Older branches are out of standard upstream support. Linux distributors may ship backported fixes that retain an older-looking package version, so administrators should use the distribution's security notice rather than rely on the displayed PHP version alone.

The PHP team says there is no complete workaround. Updating is the safe course. Partial mitigations may reduce exposure while a patch is prepared, but they are not equivalent to fixing the vulnerable runtime.

The vulnerabilities affect PHP's underlying runtime rather than a single WordPress plugin or a particular web application. That makes the issue relevant to developers, agencies, hosting companies and small businesses running their own sites.

How South African hosts responded

MyBroadband reported on 22 October that Afrihost was patching affected managed and shared servers and advising customers to update supported PHP versions. Xneelo said it had introduced mitigations before the official releases and applied updates once available. 1-Grid said it was assessing potential exposure and deploying fixes.

Those statements describe the companies' actions, not an independent audit of every server or a guarantee that all customers were protected at the same moment. Businesses should establish which parts of their hosting stack the provider manages and which remain their own responsibility.

A search of Internet-facing South African PHP services cited in the report returned more than 9,800 results. This should not be presented as a confirmed count of vulnerable machines. A scan cannot establish from that number alone which hosts have the vulnerable code path, which have been patched or which have additional protections.

The risk extends beyond taking over a server

Remote code execution within a web-server account can expose application secrets and customer information even without full administrator privileges. It may also give an intruder a foothold for further attacks, depending on permissions and network design.

Amazon's threat-intelligence team reported an attempted exploit dating to 17 October, before the vulnerabilities were publicly disclosed. That makes log review important, but it does not establish that South African organisations were breached or quantify any local losses.

Site operators should verify the relevant package updates, restart affected services, inspect unexpected files and account changes, and review access logs. If there are signs of compromise, changing credentials and investigating the incident are necessary alongside patching. Updating alone cannot reverse an intrusion that happened earlier.

The remaining unknown is the extent of the window between early exploitation attempts and completed patch deployment. South African hosting companies have described urgent action, but there is no verified national count of compromised websites or of self-managed servers that remain exposed.

What updating actually means

The corrected upstream releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Older branches sit outside standard upstream support, so a version number that merely looks old is not the test. Linux distributors sometimes ship the fix inside a package that still displays an older PHP version. Ubuntu has said the two issues are critical and that patched packages are available for its supported systems. The check is the distribution's security notice, not a glance at the version string.

The PHP team says there is no complete workaround. Partial mitigations can shrink the window while a patch is applied. They are not the patch. A host that updates its managed and shared servers has not, by that act, updated a customer's own virtual server, a container or an unsupported install. That split is the South African question. Afrihost said it was patching affected managed and shared servers and telling customers to update supported PHP versions. Xneelo said it had put mitigations in place before the official releases and applied the updates once they existed. 1-Grid said it was assessing exposure and deploying fixes. MyBroadband reported those accounts on 22 October. They are the companies speaking about their own fleets. They are not an audit of every server on their networks, and they say nothing about hosts that have stayed quiet.

The flaws were disclosed earlier than the PHP team had planned, after a leak, with emergency releases on 21 October. The identifiers are CVE-2026-109618 and CVE-2026-109619. Under affected configurations they can allow remote code execution without a login. That is why a managed-hosting update and a self-managed server are different jobs, even when they sit in the same rack.

A scan count is not a list of victims

A search of internet-facing South African PHP services, cited in that report, returned more than 9,800 results. That number is a search result. It is not a count of machines running the vulnerable code path, not a count of machines already patched, and not a count of sites that have been broken into. Treating 9,800 as a list of compromised South African sites would be a different story from the one the figure can support.

The bugs sit in PHP's runtime, not in a single WordPress plugin and not in one application. Agencies, small businesses and developers on their own servers are in scope if the runtime is affected. Remote code execution inside a web-server account can expose application secrets and customer information without the attacker becoming a full administrator. Depending on permissions and how the network is built, it can also be a foothold for a further attack. That is the practical risk. It is not a nationwide incident report.

Amazon's threat-intelligence team reported an exploit attempt dated 17 October, before the vulnerabilities were public. That date is why logs from before the 21 October releases matter. It does not name South African targets, and nobody has published a local loss figure. There is no verified count of South African organisations breached through these two CVEs.

What is still uncounted

Operators can do a short list, and no more than the list. Confirm that the package on the server is the one that contains the fix, including where a distributor backported it under an older-looking version. Restart the services that may still be holding the old runtime in memory. Look for files and account changes that were not part of a deploy. Read the access logs. If those logs show an intrusion, rotating credentials and investigating are part of the response. Installing the patch today does not undo an intrusion that landed earlier.

What no one has published is the size of the gap between that 17 October attempt and the hour each South African server finished the update. Afrihost, Xneelo and 1-Grid have described urgent work on the servers they manage. There is no verified national count of compromised sites, and no verified count of self-managed servers still on the vulnerable runtime. Until those exist, the story is the patch, the three host statements, and the box the host does not manage.