Allan Juma | Lead | Cyber Security Engineer | ESET Southern Africa | mail me |
October brought a wave of critical security vulnerabilities that tested how rapidly South African companies could respond. On Tuesday 20 October, details of two critical flaws in PHP, a programming language that powers millions of websites and online applications, leaked online before fixes became available. The PHP project issued emergency patches the following day. That same Wednesday, Node.js repaired ten vulnerabilities.
These included a Brotli decoder flaw that could lead to remote execution when applications decompress malicious data. GitLab also issued an emergency release addressing 12 vulnerabilities. The release included a maximum-severity CVSS 10.0 flaw. Under certain conditions, this flaw could 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. Researchers had found weak security keys that attackers could have used to create fake certificates for legitimate websites. Although there is no evidence that anyone misused the keys, the discovery added to an already demanding period. IT teams were still working through Microsoft’s 13 October Patch Tuesday, the largest ever reported.
PHP2Shell as a warning shot
Out of everything discovered and disclosed in October, PHP2Shell is a warning shot for South African companies. The two flaws, CVE-2026-109618 and CVE-2026-109619, can allow attackers to execute code without logging in. They 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. It addressed them in versions 8.5, 8.4.27, 8.3.36 and 8.2.35. Because the vulnerabilities exist in PHP itself, they do not affect a plug-in, theme or content management system. Therefore, updating WordPress or the application does not resolve the problem. Organisations must patch the underlying PHP runtime and restart their affected PHP services.
South Africa’s web infrastructure forms 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. Of the 17 websites that disclosed their PHP version, five reported a fixed release, while 12 reported older versions. These figures do not prove that the sites are vulnerable. Some vendors apply security fixes without changing the reported version number. Nevertheless, the findings show that the risks persist.
The public sector certainly felt the pressure. On Friday 23 October, the Presidency temporarily took its website offline as a precaution. Vincent Magwenya told Reuters that there was no indication of a security breach.
The speed of exploitation raises the stakes
What makes PHP2Shell a warning shot is how quickly the threat has developed. Amazon said its honeypots recorded an exploit attempt on 17 October. This happened four days before public disclosure. Cloudflare reported tens of thousands of attempts within 45 minutes of disclosure.
These attempts had risen to millions by 22 October. By the same day, VulnCheck researchers said they had developed an exploit. It achieved remote-code execution on PHP 8.4.26 running on x86-64 systems. BleepingComputer also reported confirmed exploitation. A honeypot had recorded successful code execution against an Apache installation.
For a business, the consequences of a compromised PHP server extend well beyond a defaced homepage. Remote-code execution can allow an attacker to 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 face risks.
The legal consequences are equally challenging. POPIA requires a responsible party to notify the Information Regulator. This applies when reasonable grounds exist to believe that an unauthorised person accessed or acquired personal information. Finding a vulnerable server does not, by itself, establish a breach. However, confirmed data theft is not a prerequisite for notification. An organisation needs sufficient visibility to assess what happened and explain the potential consequences.
What South African companies need to do
Companies need to establish where their PHP runs. They must identify every website, portal and application that uses it, including those built by agencies or hosted by third parties. Request evidence of patch status from every relevant provider.
Ask each hosting provider, developer or managed service provider to confirm the following in writing:
- Which applications use PHP.
- Which PHP builds those applications currently run.
- Whether the relevant security fixes have been applied.
Systems running PHP 8.1 or older need a plan to migrate to a supported release. Companies should also review logs for suspicious activity. Furthermore, they must check applications and servers for unfamiliar accounts, files or changes. Threat intelligence can help companies distinguish attempted attacks from confirmed exploitation. It can also help them prioritise their response.
Turning vulnerability management into a business priority
The lasting lesson is not simply to remain aware of patches or update rapidly, although both actions are critical. Instead, companies must shorten the time between the next warning and a verified fix. PHP2Shell is a warning shot that highlights the importance of effective vulnerability and patch management.
Vulnerability and patch management can support this process. It helps identify vulnerabilities in supported managed systems, prioritise affected devices and track remediation. However, companies still need clear ownership of systems outside that coverage. They must also ensure that they remain prepared for whatever may come next.