The past week has tested how rapidly South African companies can patch. On Tuesday 20 October, details of two critical flaws in PHP leaked online before fixes became available. The PHP project issues emergency patches the following day. On the same Wednesday, Nodejs repaired ten vulnerabilities including a Brotli decoder flaw that can lead to remote execution when applications decompress malicious data. GitLab also issued an emergency release addressing 12 vulnerabilities led by a maximum severity CVSS 10.0 flaw that could, under certain conditions, allow unauthenticated remote-code execution on self-managed Community and Enterprise Edition servers.
At the same time, browser and software vendors moved to distrust certificates associated with eMudhra after researchers found weak security keys that could have been used to create fake certificates for legitimate websites. While there is no evidence that the keys were misused, this arrived while IT teams were still working through Microsoft’s 13 October Patch Tuesday that was the largest ever reported.
Out of everything that was discovered and disclosed in October, PHP2Shell should serve as a warning to South African companies. The two flaws – CVE-2026-109618 and CVE-2026-109619 – can allow attackers to execute code without logging in and put all PHP installations serving web requests at risk. In practical terms, an attacker could make a vulnerable server run malicious code without first gaining authorised access.
PHP rated both flaws 9.2 on the CVSS v4 scale and addressed them in versions 8.5, 8.4.27, 8.3.36 and 8.2.35. Because the vulnerabilities are in PHP itself, not in a plug-in, theme or content management system, updating WordPress or the application doesn’t fix them. Organisations need to patch the underlying PHP runtime and restart their affected PHP services.
South Africa’s web infrastructure is part of the PHP patching challenge. On 23 October, TechCentral checked more than 100 websites belonging to government departments, metros, regulators and state-owned companies and of the 17 that disclosed their PHP version, five reported a fixed release and 12 reported older versions. These figures don’t prove the sites are vulnerable because some vendors apply security fixes without changing the reported version number, but the findings show that the risks are persistent.
The public sector certainly felt the pressure. On Friday 23 October, the Presidency temporarily took its website offline as a precaution and Vincent Magwenya told Reuters that there was no indication of a security breach.
What makes PHP2Shell a warning shot is how quickly the threat has developed. Amazon said its honeypots recorded an exploit attempt on 17 October four days before public disclosure, Cloudflare reported tens of thousands of attempts within 45 minutes of disclosure, rising to the millions by 22 October. By the same day, VulnCheck researchers said they had developed an exploit that achieved remote-code execution on PHP 8.4.26 running on x86-64 systems. BleepingComputer reported confirmed exploitation with a honeypot recording successful code execution against an Apache installation.
For a business, the consequences of a compromised PHP server goes well beyond a defaced homepage. Remote-code execution can let an attacker run malicious code with the permissions of the affected PHP process. Depending on what that process can access, customer information and connected services may also be at risk.
The legal consequences are also challenging. POPIA asks that if there are reasonable grounds to believe that personal information has been accessed or acquired by an unauthorised person, the responsible party must notify the Information Regulator. Finding a vulnerable server doesn’t by itself establish a breach, but confirmed data theft is not a prerequisite for notification. An organisation needs enough visibility to assess what happened and explain the potential consequences.
Companies need to establish where their PHP runs and every website, portal and application that uses it, including those built by agencies or hosted by third parties. Request evidence of patch status and ask each hosting provider, developer or managed service provider to confirm in writing which applications use PHP, which builds are running and whether the relevant fixes have been applied. Systems running PHP 8.1, or older, need a plan to move to a supported release and review logs for suspicious activity and check the application and server for unfamiliar accounts, files or changes. Threat intelligence also helps companies distinguish attempted attacks from confirmed exploitation and will help you to prioritise your response.
The lasting lesson isn’t to be aware of patches or update rapidly, although these are critical, but to instead shorten the time between the next warning and a verified fix. Vulnerability and patch management can support the process by identifying vulnerabilities in supported managed systems, helping teams prioritise affected devices and tracking remediation. You still need clear ownership for systems outside that coverage, and to ensure that you are prepared for what may come next.
