PHP vulnerability fix guide: from checking to moving off PHP

What should you do first about a PHP vulnerability?

Check, update, mitigate, inspect. Do these four steps in order. As of October 25, 2026, the PHP project and CISA, the US cybersecurity agency, point to the same order.^1·2

Say you hear burglars are working your neighborhood. First you look at what kind of lock you have. If it's weak, you replace it. Until the new one is in, you slide the bolt. Then you walk through the house to make sure nobody's already been inside. Handling a PHP hole works the same way.

1. Check: the PHP version your website really runs, and who manages your server
2. Update: move to a fixed release (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 or later) and always restart
3. Mitigate: if you can't update right away, buy time with PHP settings (php.ini) and a web application firewall (WAF)
4. Inspect: look for signs that someone got in before the fix, and change your passwords
5. Root fix: for a company website, consider a setup that doesn't run PHP at all

On shared or managed hosting (where the hosting company runs the server for you), most hosts handled step 2 for their customers. A tenant doesn't fix the building's boiler. Your first move is to read your host's notice.

Just go top to bottom.

There are no complete mitigations, updating is the only safe choice. — PHP Group release notes, Oct 21, 2026

Everything other than the update just buys time. The PHP project says settings changes "reduce exposure" but "do not make an installation safe."¹

Jeensuk's takeWith an order to follow, there's no need to panic. Just don't skip step 2, replacing the lock, and stop at step 3, sliding the bolt.

Step 1: How do you find your site's real PHP version?

Look at the PHP that actually serves your web pages. Running php -v on the server shows the command-line PHP, which can differ from the PHP-FPM process (the program that runs PHP for each page request) your site uses.

If your house has several clocks, the kitchen clock isn't right just because the living room clock is. Vercel's advice puts it simply: "Verify that the deployment serving web requests is running the patched runtime."³

The other trap is the version number. A number is just the label on the outside. Linux distributions such as Ubuntu and Red Hat often keep the old number and slip the fix in. Red Hat says that "just looking at the version number of a package will not tell them if they are vulnerable or not."⁴ In that case, check the package changelog for the CVE number (the worldwide ID each vulnerability gets).

Many hosts said customers didn't need to do anything. Hostinger said every plan except VPS needed no action,⁶ and Kinsta patched PHP 7.4 through 8.5 for its customers.⁷

Jeensuk's takeDon't decide "we're fine" or "we're in trouble" from one number. The first question is, "Who looks after our server?" Once you have that answer, the rest gets easier.

Step 2: Why restart after you update?

Because the PHP processes already running (called workers) keep holding the old code. Hostinger's advice to people who run their own PHP was to "update it and restart it now."⁶

Buying medicine doesn't cure you. Taking it does. Installing new PHP isn't enough while the workers already on the job keep using the old one. A restart swaps those workers for new ones running the fixed PHP.

On Debian or Ubuntu, that usually means updating packages with apt; on Red Hat–family systems, with dnf. Then restart PHP-FPM or Apache. These commands update other software too, so do it at a quiet time. Containers can't be fixed from the inside. Vercel's advice is to "rebuild with an updated PHP base image and redeploy."³

PHP 8.1 and older get no official fixed release. This time the PHP team published only minimal source patches for them, and the vendor packages to check are your Linux distribution's.¹ CISA's advice for anyone who can't update or is on 8.1 or older: take the site offline until it's patched.²

Jeensuk's take"We updated" and "we're done" aren't the same thing. You're done when you've restarted and checked again from the web.

Step 3: What if you can't update right away?

Put temporary settings into php.ini (PHP's settings file) or the PHP-FPM pool settings, then restart every worker. It isn't full protection.¹

It's like taping plastic over a broken window on a rainy night. It keeps tonight's rain out, but you haven't replaced the glass.

A WAF is a guard at the door who turns away suspicious requests. It buys time too. Cloudflare rolled out protection on "all plans with WAF deployed, including Free users," but warned that sites that changed session.upload_progress.name "are not covered by the WAF rule."⁹

Even so, CISA says a WAF "may provide some protection" and still tells you to update, or go offline until you can.² Cloudflare itself says customers should patch "even with WAF protections."⁹ A guard at the door doesn't fix the lock.

Jeensuk's takeOn the day you put in a temporary fix, also decide who will update and by when. It's only "temporary" if there's an end date.

Step 4: How do you check whether someone already got in?

Look in three places: logs, processes and files. And before you restart or rebuild anything, save the logs. TechTarget's advice: "Preserve all server logs from Oct. 20 onward."¹⁰

A house a burglar has visited has traces: footprints at the door, a stranger inside, things that weren't there before. On a server, those are the logs (the server's visitor record), processes (the programs running right now) and files. Here's what the investigators list.

1. Logs: unusual multipart requests (the format used to send files) followed by memory-limit errors or repeated HTTP 500 errors¹¹
2. Processes: PHP workers launching shells or downloading tools, or unexpected child processes of the web server^2·12
3. Files and accounts: web shells (back-door files planted to control a server from outside), unexpected or modified PHP files, new admin users and unusual outbound connections. CybelAngel suggests looking back to at least June 2026¹²
4. Passwords and keys: the bugs could expose passwords, tokens and API keys from PHP's memory,¹¹ so rotate database and admin passwords and API keys. If you suspect a break-in, isolate the system and preserve evidence first¹³

Our risk series covers this in more detail in "What if someone got in before the patch? Three signs" (English edition coming soon).

Jeensuk's takeNo traces doesn't prove nobody came. Changing the keys doesn't take much effort, so changing passwords is the one step I recommend to everyone.

What if your site breaks after the update?

Usually it comes back once you find the plugin or theme causing it and turn it off or replace it. WordPress can log errors to wp-content/debug.log, which shows which file failed.¹⁵

Kinsta notes the culprit is "almost always a plugin or an active theme," and advises testing in a staging copy first.¹⁶ WordPress also says not to leave debug tools on for a live site, so turn the log off once you've found the cause.¹⁵ That's why everyone says: back up before you update, and try it in a test copy if you can. A backup is a bridge back. A river with a bridge across it isn't scary.

In my experience, a security fix within the same branch (say 8.3.x to 8.3.36) rarely breaks a site. The trouble usually comes with big jumps, like moving from 7.x to 8.x.

Jeensuk's takePutting it off because "the site might break" is the riskiest choice. With a backup, you can always go back to yesterday.

The root fix: what happens if your site stops using PHP?

You no longer need PHP updates, restarts or checks. In exchange, the jobs PHP did, like forms, search and comments, need another solution.

A PHP site is a restaurant that cooks every order from scratch. A static site (one that serves only HTML files made in advance) is a shop that hands out meals already boxed. No stove, no kitchen fire. But it's harder to make something different for every customer.

Tools such as Simply Static turn a WordPress site into "static HTML files,"¹⁷ and Cloudflare's official docs show how to put those files on Cloudflare Pages.¹⁸

The official pages are honest about the limits: in the free version, forms and search won't work,¹⁷ comments aren't supported, and you need a new export every time you change something.¹⁸ ATATAKAI Digital's PHPFree handles that move and the running of the site afterward.

Jeensuk's takeNot every site needs to move. But for a company website, there's a way to drop steps 1 through 4 for good. You can lock your doors well, or you can have fewer doors to guard.