Running PHP older than 8.2? October's flaw has no official update for it

Picture opening your laptop on Monday morning to find your online store down, or your customers getting strange emails in your company's name. It almost always starts with something nobody was watching: the version of some forgotten software on the server.

Right now, for a lot of companies, that software is a PHP version older than 8.2, usually PHP 7.

First: what PHP is, and why this is about you

PHP is the programming language that runs a huge part of the internet: online stores, WordPress sites, customer portals, custom internal systems. You probably never chose PHP. Someone chose it for you, years ago, and it has worked fine until now.

What happened

On October 21, the people behind PHP warned about two serious flaws, rated 9.2 on a scale that goes up to 10. In practice, they let someone on the internet take over the server your site runs on, without needing a password. Five days later, the US government's cybersecurity agency (CISA) added both to its list of flaws already being used in real attacks.

The fix came out that same day, the 21st, but only for PHP 8.2 and newer. If you're on anything older (all of PHP 7, 8.0 or 8.1), you got no official update, and that changes everything: it's not a matter of clicking "update", because for those versions there is no fixed release to install.

What this could cost you

The worst case is your site or system going down in the middle of the working day, or right on the day of a sales campaign. But there are others, and they don't always make noise. Customer data can leak, like accounts, orders and emails, and besides the hit to trust, that can mean lawsuits and fines under data protection laws like Brazil's LGPD. The server can also start working for criminals, sending spam or spreading scams, until Google begins warning people that your site is dangerous. And the cleanup bill is usually far bigger than the cost of prevention.

We're not saying this to scare you. Flaws like these are exploited at scale, by bots that sweep the internet for any vulnerable server. Nobody has to pick your company on purpose: it just has to be in the way.

So, just update?

That would be great, but it's rarely simple. Companies still on a version older than 8.2 are usually there for a good reason: the system works, it makes money and nobody wants to touch it. Moving to PHP 8 changes some of the language's rules, and parts that used to work can stop. Old plugins, outdated frameworks and code written years ago are the first to break.

Updating blindly just trades one risk for another. The safe way is to know beforehand what will break, what it costs and in what order to do it.

To see where you stand: if you run PHP 8.3, 8.4 or 8.5, you're protected as long as you updated after October 21 (8.3.36, 8.4.27, 8.5.12 or newer). On 8.2, protection starts at 8.2.35, and anything earlier is still exposed; its support ends on December 31, 2026, so it's worth planning the next move already. Below that there's no official update. For 8.1, 8.0 and 7.4 there's only a source code patch, useful for those who build PHP themselves, and for 7.3 and older there's nothing at all.

Don't know which version you run? That's normal. You can find out right now, below.

Five questions to answer today

Before talking to anyone, it's worth answering this: which PHP version do your company's sites and systems run on? Who takes care of server updates, and do they still work with you? When was the system's last big update? If your site went down today, how much would the company lose per day? And is there a recent backup, and has anyone tested that it works?

If any answer was "I don't know", you're not alone. Plenty of companies are in the same spot, and that's exactly where we come in.

How 360 Brave sorts this out with you

We're a software engineering studio. In our PHP impact assessment, we look at everything your company has running, explain the risk in business terms and hand you a plan with an agreed timeline and price.

We start by talking, your way and without jargon, about how your operation works. Then, with read-only access, we map every PHP site and system, their versions, what's exposed to the internet and what would break in an update. You get a list of what to do first, ranked by risk to the business, with timeline and price, including immediate steps to reduce exposure while the update isn't ready. Then we update in stages, with tests and a way back, so the system doesn't stop. If you prefer, we hand the plan to your team to carry out.

Afterwards, if it makes sense, we look after your server on an ongoing basis. That way the next flaw becomes a routine update, not a Monday-morning emergency.

If you want to know whether your company is exposed, reach out. First we listen and understand what you have running; after a careful look, we propose scope, timeline and price. If you're not exposed, we'll tell you that too.