PHP announced two emergency patches dropping this week. If your reaction was "do we even run PHP?" — that's the problem. Most 15-person companies run three or four PHP apps and don't know it. WordPress site. Billing portal. That old intranet tool nobody logs into but is somehow still on the network.
You can't patch what you can't see. Spend an hour and make a list. Open your hosting dashboard, your server inventory, and your domain registrar. Anything running WordPress, Magento, Drupal, Joomla, Laravel, Nextcloud, or Moodle is PHP. Your bookkeeper's old invoice tool is probably PHP. The forum your sales team set up in 2019 and forgot about is almost certainly PHP.
Write it down in a spreadsheet with four columns: app name, URL, where it's hosted, and who owns it internally. That spreadsheet is the thing you'll pull up every time one of these advisories hits. Build it once, update it when things change, and you've killed 80% of the panic that comes with emergency patch cycles. The remaining 20% is actually doing the work.
For each app on your list, one of three things is true. It's on managed hosting (WP Engine, Kinsta, SiteGround, your Dell server with cPanel) — the host usually patches PHP for you, but you still need to verify and bump the app version yourself. It's on a VPS or your own Linux box — you own it, nobody's coming to save you, and apt update is on your Friday calendar. Or it's an app your developer built and ghosted on three years ago — in which case the patch is the smaller problem.
Assign a human to each row. Not "IT" — a name. If you don't have a named human, the row is a liability. For small shops without in-house ops, this is where a managed service provider earns their keep. Pay someone $300 a month to own that spreadsheet instead of hoping you remember.
Emergency patches shouldn't feel like emergencies. They feel like emergencies becuase most small businesses treat patching as a thing that happens when a headline scares them. The fix is boring. Weekly patch window, 30 minutes on a Thursday morning, same time every week. Snapshot the server, run updates, click around to confirm nothing broke, done. When the next PHP advisory drops, you're already on a current version and the patch is a non-event.
Front-load the two hours of setup now. The alternative is scrambling every three months when something breaks and you're trying to remember which version of PHP that one app needs to not explode.
If your PHP inventory is a mystery and the idea of a Thursday patch window sounds like a chore nobody will own, that's the kind of cleanup we do for growing offices. Send us a note and we'll help you build the list.
— Alexander @ SBATC
