Can security ever be a selling point in an era of breaches?

The flaws, now known as PHP2Shell, let an attacker run their own code on a web server without logging in. They affect every version from PHP 5.4 onwards, which means they have been sitting in a large share of the web for more than a decade.

A not so uncommon occurence

The latest PHP2Shell vulnerability is the future we have been warned about. The researchers at Wiz, OpenAI and Calif who found it said that turning these flaws into a working exploit took a chain of steps at the very edge of what human researchers could manage, and that frontier AI models brought it within reach.

This time the defenders found it first, but only just. Details leaked before the planned disclosure, Cloudflare reported early attempts to exploit it before the patch was released, and one security firm predicted mass attacks within 15 minutes of the fix going live.

Headlines like this are now a weekly occurrence, whether it’s a breach at a household-name retailer, a compromised supplier, or an urgent patch for a tool half the industry relies on.

So can security really be a selling point in 2026?

Rarely in the way marketers would like. Customers don’t necessarily choose a bank, retailer or airline because of its security architecture alone, and no brand can credibly promise it will never be breached.

For most customers, security only becomes visible when it fails, and when it does, they don’t distinguish between a flaw in your code, one in a supplier’s, or one buried in a programming language. That is especially true on mobile. People experience an app as a single thing; they have no idea that their loyalty account, checkout or order history lives on servers and APIs that may well run PHP. If those are compromised, the headline will say the app was hacked.

What customers can see is how a business responds: how quickly it acts, how clearly it communicates and how competent it looks in the days after a story like this breaks. Hours before the PHP patch arrived, Wikimedia took one of its tools offline as a precaution. Someone there knew what they were running, understood the risk and acted before being forced to. That kind of readiness varies enormously between organisations, and it is usually what decides whether a vulnerability becomes an incident.

The SPEED OF RESPONSE

The speed of that response is mostly decided long before anything goes wrong. Fixes for supported versions of PHP arrived the next day, but PHP 8.1 and older are end-of-life and will get no fix at all. Anyone still running them has no patch to apply, only an upgrade project, started under pressure while attackers are already scanning. A patch that should take days ends up taking months, and that gap usually comes from years of upgrades deferred because they didn’t add a feature or move a KPI.

Mobile teams already live with a version of this discipline. Apple and Google raise their OS and SDK requirements every year, and apps that don’t keep up eventually drop out of the stores. It can be frustrating, but it forces a regular rhythm of maintenance. The web services behind those apps rarely face the same pressure, which is why they are so often where the oldest code lives.

Knowing your systems

No organisation can avoid vulnerabilities entirely, but every organisation can control how quickly it responds. That means knowing exactly what you run, down to the version, across every system your apps depend on, including your suppliers’. It means treating upgrades as routine product work with a budget, rather than a project that waits for a crisis.

It means having an emergency patching process that has actually been rehearsed, so nobody is working out who needs to approve a change while exploit traffic is arriving, and it means deciding in advance how you will talk to customers if something does go wrong.

Here is a useful question to put to your technology team. If a flaw like PHP2Shell were announced tomorrow, how long would it take us to confirm whether we’re affected, and how long to be fully patched across every app and service? If the honest answer is measured in weeks, that number tells you far more about your security than anything written in your privacy policy.