Harden WordPress Files After the PHP RCE: 6 Checks

Patch PHP first. Then spend 30 minutes on six file-level checks: correct folder and file permissions, a locked-down wp-config.php, the dashboard file editor switched off, and two small .htaccess blocks. None of this fixes the PHP flaw, but it makes life harder for anyone who gets a foothold on your site.

On 21 October 2026 the PHP project shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical bugs, CVE-2026-109618 and CVE-2026-109619, that "can allow unauthenticated remote code execution". That means someone could run their own code on a server without logging in. WordPress.org said the same day that "No WordPress update is required or planned for these issues". The fix lives in PHP, not in WordPress.

So why touch WordPress files at all? Because patches arrive on your host's schedule. By the end of this guide you will have applied the six checks from the official WordPress hardening page, tested each one, and you will know how to undo any of them in under a minute.

Heads up: this guide does not replace updating PHP. If you have not done that yet, read our companion post on patching PHP after the October 2026 security release first, or ask your host which PHP version your site runs right now.

What "hardening WordPress files" actually means

Hardening means removing easy wins for an attacker. You are not adding a new security product. You are changing settings so that a mistake or a stolen login can do less damage.

Think of your WordPress folder like a shared office. The kitchen (/wp-content/) is open, because that is where the work happens. The cabinet with the master keys (wp-config.php) stays locked. The server room (/wp-includes/ and /wp-admin/includes/) says "staff only", so visitors from the street get turned away.

At the time of writing (23 October 2026), the WordPress Advanced Administration page "Hardening WordPress" was last updated on 14 October 2026. Every rule below comes from that page or from another official source listed at the end.

Why this matters: tight permissions and a disabled file editor will not stop a PHP flaw, but they close a few easy doors that attackers like to try first.

Before you start

• Access to your hosting control panel (cPanel or similar) with File Manager, or SSH access to the server.
• The full path to your WordPress folder. In this guide we use /home/example/public_html as the example. Yours will be different.
• A WordPress administrator login, so you can check Site Health afterwards.
• A fresh backup of your files and database, stored somewhere other than the server. If you do not have one, follow our guide to back up your website in cPanel with an offsite copy and a test restore before you continue.
• About 30 minutes, plus 10 more for testing.
• To know your web server. The .htaccess steps work on Apache and LiteSpeed. They do nothing on Nginx, which has its own section below.

Risk level: low to medium. Permission changes and .htaccess rules can break a site if you mistype them, which is why every step starts with a copy of what you are about to change.

Quick tip: if you are not sure whether your site runs on Apache, LiteSpeed or Nginx, ask your host. cPanel's own support article says LiteSpeed reads Apache configuration files directly and is compatible with Apache .htaccess rules, so the .htaccess steps apply there too.

The six checks, step by step

Work through these in order. After each step, load your home page and dashboard in a private browser window, so if something breaks you know which change caused it.

Step 1: Take a copy of the files you will change

You will edit two files: .htaccess and wp-config.php. A local copy of each lets you undo any change in seconds.

Over SSH, these commands copy both files with a date stamp in the name.

cd /home/example/public_html
cp .htaccess .htaccess.bak-2026-10-23
cp wp-config.php wp-config.php.bak-2026-10-23

In cPanel, open File Manager. Files that start with a dot are hidden by default, so click Settings, select Show Hidden Files (dotfiles) and click Save. Then select .htaccess, click Copy in the toolbar, enter the same folder with a new file name, and click Copy File(s). Repeat for wp-config.php.

What you should see: two new files ending in .bak-2026-10-23 sitting next to the originals.

Heads up: delete these backup copies once you are done testing. A spare copy of wp-config.php contains your database password, and you do not want it lying around in your web folder longer than needed.

Step 2: Set folders to 755 and files to 644

What the numbers mean, in plain words: each digit is a set of rights for the owner, the group and everyone else. A 7 means read, write and enter. A 5 means read and enter. A 4 means read only. So 755 lets you change a folder while others can only look, and 644 does the same for a file.

The hardening page recommends this layout:

• All files are owned by your user account and writable by you.
• The WordPress root folder, /wp-admin/ and /wp-includes/ are writable only by your account. The exception is .htaccess, if you want WordPress to write rewrite rules for you.
• /wp-content/ is writable by your account and the web server.
• /wp-content/themes/ is writable by the web server only if you use the built-in theme editor.
• /wp-content/plugins/ is writable only by your account.

This command sets every folder under your WordPress install to 755.

find /home/example/public_html/ -type d -exec chmod 755 {} \;

This command sets every file under your WordPress install to 644.

find /home/example/public_html/ -type f -exec chmod 644 {} \;

When it finishes you get your prompt back with no output. No output is good news.

In cPanel File Manager you can do the same for single items: select the file or folder, click Permissions in the toolbar, tick the boxes or type the number, and click Change Permissions. For a whole site with thousands of files, SSH is much faster.

But what if your host's PHP runs as a different user than your account? Then WordPress may need to write to more places than this layout allows, and updates or uploads can fail. The "How to check it worked" section shows you how to spot that, and Troubleshooting shows how to fix it.

Step 3: Lock down wp-config.php

wp-config.php holds the login details WordPress uses to reach your database. It is the most valuable file in your install.

The hardening page says to make sure "only you (and the web server) can read this file (it generally means a 400 or 440 permission)." A 400 means only the owner can read it. A 440 means the owner and the group can read it. Nobody can write to it until you change it back.

Run this after Step 2, because the find command in Step 2 just set this file to 644 along with everything else.

chmod 440 /home/example/public_html/wp-config.php

Quick tip: start with 440. If the site loads normally, you can try 400. If it stops loading, go back to 440 and ask your host which user PHP runs as.

When you need to edit wp-config.php later (for example in Step 4), give yourself write access first with chmod 640, make the edit, then set it back to 440.

You may also read online that you should move wp-config.php one folder above your WordPress install. WordPress does support this. The hardening page is honest about it: "Some people assert that moving wp-config.php has minimal security benefits", and it warns that a careless move "may actually introduce serious vulnerabilities." My advice: skip it, and do Step 5 instead.

Step 4: Turn off the dashboard file editor

The hardening page puts it simply: "The WordPress Dashboard by default allows administrators to edit PHP files, such as plugin and theme files." That means PHP code can be changed straight from the browser. That is handy for you. It is even handier for someone who steals an admin password.

Made-up example: Sam runs a small bakery site. An old admin password leaks from another service. The attacker logs in, opens the built-in theme file editor, and adds one line of PHP to functions.php that sends visitors to a spam site. With the editor turned off, that easy path is gone, and the attacker has to find a harder one.

This line in wp-config.php turns the editor off. Place it above the line that says /* That's all, stop editing! Happy blogging. */.

define( 'DISALLOW_FILE_EDIT', true );

If you have WP-CLI (the WordPress command-line tool), this command adds the same line for you. Remember to give yourself write access to wp-config.php first, as described in Step 3.

cd /home/example/public_html
chmod 640 wp-config.php
wp config set DISALLOW_FILE_EDIT true --raw
chmod 440 wp-config.php

What you should see from WP-CLI: a line starting with Success:, like the example in the official WP-CLI documentation for wp config set.

Be realistic about what this does. The hardening page says it "will not prevent an attacker from uploading malicious files to your site, but might stop some attacks." It is one small door closed, not a wall.

Heads up: the WordPress wp-config.php documentation notes that the functionality of some plugins may be affected, because they check whether the user can edit plugins. If a plugin screen stops working after this change, that is the first thing to check.

What about DISALLOW_FILE_MODS? It goes further and blocks installing and updating plugins and themes from the dashboard, and it disables the editor too. That also stops the dashboard updates you probably rely on, so only use it if you deploy updates another way. Our post on safe WordPress auto-updates with a backup plan explains why updates matter so much.

Step 5: Deny web access to wp-config.php

Nobody outside the server ever needs to request wp-config.php in a browser. This rule makes the web server refuse any such request outright, so the file is never handed to a visitor in any form.

The hardening page says to place this block at the very top of your .htaccess file. It tells Apache or LiteSpeed to deny every request for that one file.

<Files "wp-config.php">
Require all denied
</Files>

To edit .htaccess in cPanel, select it in File Manager, click Edit, paste the block on the very first line, and save. Over SSH, use any text editor you are comfortable with.

What you should see: your site loads exactly as before. The test comes in the "How to check it worked" section.

Step 6: Block the include-only folders

Some WordPress files are only meant to be loaded by other WordPress files, never opened directly in a browser. These live in /wp-admin/includes/ and in the top level of /wp-includes/. Blocking direct requests to them removes a little attack surface.

This block from the hardening page returns "403 Forbidden" for direct requests to those include-only files. Place it below the wp-config.php block from Step 5, and above the # BEGIN WordPress line, so WordPress never overwrites it.

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

Heads up for Multisite: the hardening page says this rule set does not work well on WordPress Multisite. The wp-includes PHP rule stops ms-files.php from serving images. You can remove that one line to make it work, at the cost of some protection. If you run a single site, which most people do, this does not affect you.

If you already have other rules at the top of .htaccess, such as an HTTPS redirect from our guide on redirecting HTTP to HTTPS with htaccess, keep them. Just keep everything you add outside the # BEGIN WordPress and # END WordPress lines.

If your site runs on Nginx

Nginx has no .htaccess. The WordPress Nginx documentation puts it plainly: Nginx has no directory-level configuration file like Apache's .htaccess or IIS's web.config. So Steps 5 and 6 do not apply as written. Steps 2, 3 and 4 still apply exactly as above.

That same official page gives a global restrictions example, including one rule worth knowing about right now. This location block inside your site's server {} block denies any .php file inside an uploads or files folder, which is a common place for attackers to drop a script.

location ~* /(?:uploads|files)/.*\.php$ {
    deny all;
}

The page also warns that "A typo in Global restrictions file can create loopholes." Test the config before reloading Nginx, and if you cannot edit Nginx yourself, send the block to your host.

How to check it worked

Test from outside the server with curl -I, which fetches only the response headers.

This request should now be refused because of Step 5.

curl -I https://example.com/wp-config.php

Expected: the first line shows 403 (for example HTTP/2 403).

This request tests the wp-includes rule from Step 6.

curl -I https://example.com/wp-includes/version.php

Expected: 403.

This request tests the wp-admin/includes rule.

curl -I https://example.com/wp-admin/includes/file.php

Expected: 403.

This request checks the site itself still returns a normal page.

curl -I https://example.com/

Expected: 200, or a 301 redirect to your preferred address, the same as before you started.

For the file editor, log in to WordPress as an administrator and look under the Appearance and Plugins menus. You should no longer find a way to edit theme or plugin PHP files.

Quick tip: check a second way. Open Tools > Site Health in your WordPress dashboard. The Status tab lists critical issues, and the Site Health screen flags an outdated PHP version as a critical item on the Status tab. Then open Tools > Site Health > Info and expand Server to see your PHP version, and Filesystem Permissions to confirm WordPress can still write where it needs to. The WordPress documentation says it should be able to write to the main WordPress directory, wp-content, uploads, plugins and themes.

Read the Filesystem Permissions panel carefully

This is the step people skip. If any of those folders show as not writable after Step 2, uploads or plugin updates may fail. The WordPress documentation says "If any of these are not writable, you might need to contact your host for assistance." That usually means PHP runs as a different user from your account on that server, and your host can tell you the right ownership.

Troubleshooting

500 Internal Server Error after adding the .htaccess rules

Symptom: every page shows "500 Internal Server Error" right after you saved .htaccess. Likely cause: a typo, a missing closing tag like </Files>, or a server that does not allow these directives in .htaccess. Fix: restore your backup copy over the live file, check the site loads, then add the blocks back one at a time to find the culprit.

This command restores the copy you made in Step 1.

cp /home/example/public_html/.htaccess.bak-2026-10-23 /home/example/public_html/.htaccess

Rules added but curl still shows 200

Symptom: curl -I https://example.com/wp-config.php still returns 200. Likely causes: your site runs on Nginx, which ignores .htaccess, or you edited a .htaccess in the wrong folder. Fix: confirm your web server with your host and make sure the file sits in the same folder as wp-config.php.

Images missing on a Multisite network

Symptom: uploaded images return errors on sub-sites after Step 6. Likely cause: the wp-includes PHP rule blocks ms-files.php, as the hardening page warns. Fix: remove the line RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] from your block.

Site stops loading after changing wp-config.php permissions

Symptom: a blank page or an error right after chmod 400 or chmod 440. Likely cause: the web server cannot read the file because PHP runs as a user outside the owner and group. Fix: set it back with chmod 644 /home/example/public_html/wp-config.php so the site works again, then ask your host which value fits their setup.

Plugin updates or uploads fail after Step 2

Symptom: plugin or theme updates fail, or media uploads fail. Likely cause: the web server user cannot write to /wp-content/ with the new permissions. Fix: check Tools > Site Health > Info > Filesystem Permissions, then ask your host to set ownership so /wp-content/ is writable by the web server, as the hardening page recommends.

A plugin screen breaks after disabling the editor

Symptom: one plugin's settings page stops working after Step 4. Likely cause: the WordPress wp-config.php documentation warns that plugins which check current_user_can('edit_plugins') may be affected by DISALLOW_FILE_EDIT. Fix: comment out the define line, confirm the plugin works, and tell its author.

Security notes and when to call for help

These checks reduce damage. They do not clean a site that is already hacked. If you see files you did not upload, strange admin users or redirects you did not add, stop hardening and follow WordPress.org's own "FAQ: My site was hacked" page, linked from its October 2026 PHP security post.

Also lock the front door. A stolen admin password beats every file permission in this guide. If you have not turned on two-factor login for your hosting panel yet, our guide to two-factor authentication on cPanel, Plesk and DirectAdmin takes about ten minutes.

The one message worth forwarding

Copy this and send it to your host, developer or whoever looks after your site:

"Hi, after the PHP security release on 21 October 2026 (CVE-2026-109618 and CVE-2026-109619), can you confirm our server runs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer? I have also hardened our WordPress files following the official WordPress hardening guide: folders 755, files 644, wp-config.php at 440, DISALLOW_FILE_EDIT set to true, and .htaccess rules that deny wp-config.php and the include-only folders. Can you tell me which user PHP runs as on our account, so I know whether 400 or 440 is right for wp-config.php, and whether anything in our setup needs different ownership for /wp-content/? Thanks."

Patch PHP first, then these six checks make sure that if something does slip in, it finds very little it can change.