One patch, every location: PHP2Shell when the franchisor runs the web

Over the last several years a lot of franchise brands pulled their web presence in-house. Location pages moved onto one platform. Franchisees stopped hiring their own local agencies. Booking, lead forms and the franchise development site all came under the franchisor’s roof, or more accurately under the roof of a vendor the franchisor picked. One template, one login, one standard. That was the right call, and I’d make it again.

It also means that this month, one server can be every location at once.

On October 21, the maintainers of PHP, the programming language underneath a big share of the web (WordPress runs on it, and so do plenty of booking tools, intranets, learning systems and online stores), shipped fixes for two critical flaws now known as PHP2Shell. In plain terms, someone on the internet can run their own code on an unpatched server without logging in to anything. On October 26 the Cybersecurity and Infrastructure Security Agency (CISA, the federal government’s cyber defense agency) added both to its list of vulnerabilities known to be under active attack. Things land on that list when there’s evidence people are already doing it.

The fix is to update PHP: versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 or later. If something runs 8.1 or older, no routine fix is coming, and CISA’s guidance is to take it offline until it can be updated.

Consolidation cuts both ways

When the franchisor runs the platform, one patch fixes 200 locations. That’s the upside, and it’s real. Compare it to chasing 200 franchisees and 40 local agencies, and you’d take this week’s problem every time.

The flip side is that one missed server is 200 locations too. And the franchisor platform usually does more than show hours and a phone number. Look at what often sits on it:

• Location pages and booking, which get each unit found and get the appointment on the calendar. Customer names, phone numbers, emails.
• The franchise development site. A candidate application form can be collecting contact details and financial qualification information from people who haven’t signed anything yet.
• The franchisee portal, intranet or training system. Every owner and manager in the network has a login, and some of them reuse that password elsewhere. Nobody likes to say that part out loud, but everybody knows it.
• Ordering and merch stores. Payment usually runs through a processor, but the store itself is still a server with your brand on it.

So I’d sort this by function, not by server. What job does each piece do, what data does it hold, and what breaks for the units if it goes down or gets compromised? The franchise development site and the franchisee portal usually belong near the top of that list, even though nobody thinks of them as “the website.”

“We’re on a platform” isn’t an answer yet

Most franchisors at 50 to 300 units don’t run their own servers. They buy a platform: a location-page vendor, a booking tool, a learning system, an agency-hosted WordPress install. That’s sensible. It also means the honest answer to “are we exposed?” is usually “I’d have to ask.”

I’ve sat in the vendor seat on this. At Adaptive, we were the first partner MindBody ever let into its database directly instead of going through an API. That’s the kind of access a franchise system’s vendors can end up with, and most brands couldn’t tell you which of their vendors have it. A platform with deep access to your data is part of your stack whether or not you ever see its servers.

The managed hosts and larger software vendors have mostly been on this since day one. The ones to worry about are smaller: the agency that built and still hosts the franchise development site, the niche plug-in on the intranet, the tool somebody set up years ago that still syncs data every night.

What I’d do now

Your IT partner or managed service provider does the patching and the forensics. The franchisor’s job is making sure nothing is missing from their list and that every vendor has actually answered.

1. List every system carrying the brand, by function. Location pages, booking, lead capture, the franchise development site, the franchisee portal, training, ordering. Next to each one, write the vendor and who holds the admin login. If a handful of one-off franchisee sites are still out there, they go on the list too.
2. Ask every vendor three questions, in writing. Do you run PHP anywhere in what you host or provide for us? Are you on 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later? If not, when, and what’s protecting us until then? A good vendor answers in a day. A vendor who can’t answer has told you something.
3. Anything on PHP 8.1 or older, or anything nobody can log in to, comes down. A dark page for a few days is an inconvenience. A compromised booking page across the whole network is a much worse week.
4. Then check whether anyone got in first. These flaws were being exploited before a lot of servers got updated, and the firms tracking this recommend looking for signs of an earlier break-in, not just applying the update. That’s your security partner’s job, but somebody has to ask them to do it.
5. Keep an eye on the next one. A third PHP issue disclosed on October 23 isn’t fixed by the October 21 updates. It depends on an unusual configuration and there’s a one-line workaround while a patch is pending. Make sure every vendor who answered question 2 knows about it too.

Tell the network before a customer does

Franchisees often pay for this platform through a technology fee, and most of them have no view into what it runs on. Some of them have read the headlines. A short note from the franchisor saying what you checked, what you found and what you changed does more for trust in that fee than any slide at convention. If you need them to reset portal passwords, that note is where you ask.

The longer fix is in the vendor agreements

Once this settles, the useful question is why the answers were hard to get. Most franchise technology agreements say plenty about uptime and almost nothing about how fast the vendor has to tell you what they run, when they’ve patched it, and whether your data was touched. That’s worth adding at the next renewal: version disclosure on request, notice within a set number of hours for anything on CISA’s list, and a named person who answers.

Centralizing the stack was the right move. It also made the franchisor the one who has to know. If you’d like a second set of eyes on the vendor list or the agreement language, I’m glad to help.