By Sian Clements, Client Relationship and Delivery Partner, Younity Auckland
If you work in tech, or hire people who do, your inbox has probably been full of PHP over the past week. Here’s what’s happened, and why I think the bigger conversation is about how engineers approach security.
On 22 October, a patch was released for two critical vulnerabilities in PHP, the language behind a huge share of the world’s websites. New Zealand’s NCSC urged organisations here to patch immediately, or take public-facing services offline if they couldn’t. AI tools helped researchers find the flaws, which had been sitting in the code for more than a decade.
Things have moved on since. On 26 October (US time), CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalogue, which means they’re now listed as actively exploited. The NCSC has also pointed out that patching won’t remove a system that’s already been compromised. Think of it as locking the door after a visitor has already come in, so if you patched late, it’s worth checking that nobody got in first.
It’s been coming up in conversations a lot, and I expect it will keep coming up as businesses work out what it means for them. It’s got me thinking about timing. What I keep hearing from security engineers is that building security in from the start is so much easier than adding it later, once software, integrations and customer bases have grown. And when I speak with engineering leaders, the teams that handle situations like this best are usually the ones where security awareness is already part of how people work, not something bolted on after an incident.
Security isn’t something you switch on when an alert lands. Like DevOps or culture, it’s something teams practise over time, and it doesn’t belong only to the specialists. It’s a bit like footy, really. The teams that look calm under pressure are usually the ones who did the unglamorous work at training, long before game day.
Every engineer can contribute to that, starting with the things they influence. And I think that’s a pretty exciting thought. It’s also the sort of thinking I’d encourage hiring managers to look for, and engineers to build and be able to talk about.
Where PHP might be hiding
PHP has a habit of turning up in places nobody remembers putting it. CISA notes that it’s often tucked inside other software, and the BBC reported that it turns up in network appliances and management interfaces that are easy to overlook. Finding those systems takes people who know where to look.
Older systems are another thing to keep in mind. The NCSC says the patch only covers supported versions, so end-of-life systems stay exposed unless teams compile their own fixes or get backports from their vendors. CISA lists the fixed versions as 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and recommends taking anything on 8.1 or earlier offline until it’s updated.
For a lot of businesses, that could mean upgrade and migration work that has been waiting for a quiet moment. That sort of work needs people who can work out what depends on what, plan the migration carefully and keep the business running while it happens.
If you’re not sure where to start
Based on the NCSC and CISA advice, a sensible first step is to find out where PHP is running in your organisation. Check with your suppliers and third-party providers, apply the patch if you can, look for signs of unusual activity, and take things offline if you can’t patch straight away.
If PHP is running anywhere in your business, it’s worth a quick chat with your IT team, hosting provider or web developer to check whether the fixes have been applied and whether they looked for signs of compromise. If you’re on an older version, it’s also a good idea to ask about vendor backports or an upgrade path.
There’s no finish line
New vulnerabilities will keep appearing, and some will have been sitting quietly for years. That’s why I’d encourage businesses to make security part of how their engineers work, from design through to testing, deployment and maintenance.
Not every business needs a dedicated security specialist. If you’re a smaller team without one, the same principle applies. The teams that cope best when something like this happens usually have engineers who understand risk, raise concerns early and make sensible decisions under pressure.
So while it’s natural to ask whether you need PHP developers right now, I’d encourage a bigger question too: is security part of how your engineers think from the start, or does it tend to come in later?
If you’d like a friendly chat about what this means for your team, whether that’s short-term help or building security thinking into how you hire, my door’s always open. Bring a coffee (or a footy score, if it’s been a good weekend).
