Every so often a serious vulnerability gets announced before the fix is ready. That's where we are this week with PHP. The PHP team has told admins to expect emergency updates on Wednesday, October 21, for two critical flaws, and BleepingComputer reports details leaked ahead of the planned disclosure.

So what do you do in the gap between "there's a problem" and "here's the patch"? You can't install a fix that doesn't exist yet. But you can make your server a much smaller target. That's exactly what our infrastructure team is doing right now, and here's the same checklist in plain language.

1. Know what you're running

You can't protect what you don't know about. Make a quick inventory:

Every server and site that runs PHP
Which PHP version each one uses
Old sites, test sites and forgotten subdomains (these are the ones that bite)

If you find something on an end-of-life PHP version, flag it. Those won't get the upcoming fix, so they need the most attention.

2. Close what doesn't need to be open

Look at what your server exposes to the internet. If a service doesn't need to be public, firewall it off. Database ports, remote management tools and old admin services usually have no business being reachable from anywhere in the world.

The rule of thumb: if you can't say why it's open, close it.

3. Lock down admin and monitoring panels

Admin logins, hosting control panels, phpMyAdmin and server monitoring dashboards are high-value targets. A few ways to tighten them:

Restrict access to known IP addresses with an allowlist
Add a second layer like basic auth in front of the panel
Turn on two-factor login where it's available
Remove admin tools you don't actually use

If your team works from changing locations, a VPN plus an allowlist is a solid middle ground.

4. Trim PHP down

Less running code means less to attack.

Disable PHP modules and extensions you don't use
Shut off old PHP versions that are still installed but no longer serving a site
Make sure PHP isn't allowed to run in upload folders where it has no reason to

Test changes on staging or one site at a time. Turning off a module a plugin quietly depends on is a fast way to take a site down.

5. Add a filter in front of the site

A web application firewall (WAF) can block a lot of junk before it ever reaches PHP. Once details about a flaw go public, WAF vendors often add rules for it quickly, so make sure yours is turned on and updating.

Rate limiting helps too. Capping how many requests one visitor can make in a short window slows down automated scanning and brute-force attempts.

6. Watch the logs

This is the one people skip, and it's the one that tells you whether any of this matters. Keep an eye on:

Web server access and error logs for strange requests
New or changed files in your site folders
Unexpected processes or outbound connections
Spikes in errors, CPU or traffic

Good monitoring turns "we found out a month later" into "we caught it the same afternoon."

7. Back up and get ready to patch

Take a fresh backup, and confirm you can actually restore it. Then line up your patch window so you're ready to apply the update as soon as it's released. If your host handles PHP for you, ask them now when they plan to patch.

The short version

Inventory your PHP versions
Firewall anything that doesn't need to be public
Restrict admin and monitoring panels to known IPs
Disable unused PHP modules and old PHP versions
Turn on WAF rules and rate limits
Watch your logs and monitoring
Back up, then patch the moment the fix lands

None of this replaces the patch. It buys you time and makes you a harder target while you wait. Once the update is out, apply it, then keep the hardening in place. Most of these steps are just good practice anyway.

If you'd like a hand with server maintenance and monitoring, our WordPress maintenance page lays out how our care plans work. And if you think something already got in, start with our WordPress incident response hub.

Before the Patch: A Practical Hardening Checklist When a Fix Isn't Out Yet