Advisory
Would you know today if your platform was exposed?
On 21 October 2026, PHP released fixes for two critical flaws, known as PHP2Shell, which it rates 9.2 out of 10. Before the fix landed, Cloudflare said it was already seeing early attempts to exploit them.
Simon Bestbier
5 min read
People were sharing a one-line configuration change online as a workaround, and the security firm that first suggested it later said it was not a complete fix. PHP's own developers put it more plainly, as reported by The Hacker News: the only protection is to update PHP.
For a business with a security team, that was a busy day. For a business whose website or platform was built on PHP years ago, by a developer who has since moved on, it was an ordinary Wednesday. Nobody inside the business knew the flaw applied to them.
Most exposure starts with not knowing what you run
Try answering three questions about your own platform. Which version of PHP, or whatever language it is built on, serves it today? Who would apply an emergency update, and how quickly? Where would you find out that one was needed?
If the honest answer to any of these is "the agency that built it" or "I'm not sure", the platform is carrying risk that nobody has priced. PHP fixes only its supported versions, 8.2 to 8.5. Anything older, including 8.1, 7.x and 5.x, gets no fix for PHP2Shell at all. The options for those systems are to upgrade, isolate them from the internet or take them offline.
PHP2Shell has a name and a news cycle, which is why people heard about it. Most of the risk on an ageing platform has neither: a library that stopped receiving updates, a password stored in the code, a test system nobody switched off. These problems do not make the news until someone exploits them.
Hosting it yourself only saves money if someone is watching
Running your own server looks cheaper than paying for managed hosting and support, and on paper it is. The saving assumes someone with the right experience is looking after it.
The advice published for PHP2Shell shows what that involves. Apply the update to the software that serves web traffic as soon as it is released. Until you can, take exposed systems off the public internet or put them behind access controls. Reduce the data stored on the server, cut its privileges, remove stored credentials and keep logs somewhere an attacker cannot delete them.
A security fix only helps a business that knows it applies, and has someone who can install it the day it lands.
None of those steps is exotic. Each needs a person who knows the server well enough to do it under pressure, at short notice. A business that hosts its own platform without that person has deferred the cost to the day something goes wrong.
Vibe-coded apps will make this more common
AI tools now let people with no development background build working software in a few evenings. That is useful. It also moves security decisions to people who may not know they are making them.
In October 2026, MyBroadband reported that an internal operations dashboard used by a South African coffee franchise had exposed contact details for franchisees, operators and managers, along with some business performance data. The app appeared to sit behind a login screen, but according to MyBroadband the login page itself sent the data, so anyone with the address could read it in the page source. MyBroadband described the app as vibe-coded. The franchise said it was a legacy version that had not been decommissioned, that no customer data was collected on it, and that it would notify the Information Regulator under POPIA.
Nobody had to break in. The data went out to anyone who loaded the page. A developer who knows what to look for checks what a login page sends before anyone logs in. Someone building their first app has no reason to know that check exists.
We expect to see more of this. People outside IT are building more internal tools, quickly, and some of those tools end up holding data the business would not want public.
Size does not buy safety
INTERPOL's African Cyberthreat Assessment Report 2026 found that South Africa accounted for 92 per cent of all ransomware detections in Africa in 2025, based on TrendAI data.
Reported breaches are rising as well. In the 2024/25 financial year, organisations notified the Information Regulator of 2,374 security compromises, an average of almost 200 a month.
South Africa accounted for 92 per cent of all ransomware detections in Africa in 2025.
Large organisations with dedicated security teams are breached too, and attackers hold some of them to ransom over their data. Preventing a breach is difficult at any size, and nobody can promise it will not happen.
What a business can control is how prepared it is. It can know what its platforms run on, what each one can reach, what data each one holds and who would fix a problem. That preparation decides whether the next PHP2Shell is a planned update or a scramble.
Give your business the best chance you can
A technical due diligence review is one way to find out where you stand before an attacker does. Specialists read the code and talk to the people who built it. The review rates security and vulnerabilities, and data protection against POPIA and GDPR. It checks the third-party software the platform depends on, including whether it still receives fixes, and looks at how much of the platform depends on one person or one supplier. It ends in a list of fixes, most urgent first. It needs only read-only access to your code, and it changes nothing.
No review makes a platform safe for good. It tells you which risks you are carrying, so that you can choose which ones to fix first.
If your platform was built a while ago, or built quickly, tell us what it does and who built it. We will set up a short call to scope a review.
