Security Tab causes error 503

Before creating a new thread please be sure to check our support forum for other issues that may be similar.

If there are no other similar threads, please provide a general summary of the issue in the Title above.

Expected behavior

Clicking on the Security tab in the backend should open security features.

Current behavior

Clicking on the tab causes an error 503. Any other plugins under security also cannot be opened.

Possible solution

This appears to be a cPanel problem as it doesn’t happen on a server running Direct Admin

Steps to reproduce

Click on Security tab or any plugins under that tab.


How has this issue affected you? What are you trying to accomplish?
Providing context helps us come up with a solution that is most useful in the
real world.

Cannot use plugins installed under the Security tab.

I get a 404: Page cannot be found.

That’s a relatively new error as it was working in April when I wrote a blog post about adding settings pages to it.

There is a security.php in /wp-admin/ but I get 404 if I try to access it; if I try themes.php in the same folder it loads correctly.

1 Like

Yes, this is a recent problem. I only noticed it when making a new site. But it’s definitely being caused by cPanel as my web host agrees.

Does anyone have any contacts within the cPanel world who can help with this?

Either that or what is causing wp-admin/security.php to generate the error?

After all, ClassicPress is supposed to be promoting itself on its security. But it doesn’t look good when its own security tab doesn’t work.

Since that file is in CP since at least 20 Sep 2019, and you say the issue is recent… this can’t be a CP issue, I think.

While 404 errors are not helpful at all, the first report here says it is a 503 error and that error does always have some more context that will tell us exactly what is happening.

Please make sure the server has debugging enabled, and logs errors.
Also, add this to WP Config file:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

This will create a debug log file in wp-content. Trigger the 503 error and let us know what is logged in the error log.
Enabling server level logging might throw additional error logs in the particular folder where the error happens (wp-admin folder in this case).
Share that too.

Note that 503 errors are usually just meaning the site or server is not available, but it could be some sort of memory exhaustion or whatnot killing it.
The error log will hopefully tell more.

About 404… they don’t throw error logs, but it is still worth checking if you can see anything in it, @azurecurve

From there we can work forwards.

It is a CP issue in that WP doesn’t use that file (as far as I’m aware). My web host thinks it might be a Litespeed issue. As I said, it doesn’t happen on other servers I use running Direct Admin, so something has changed at cPanel.

My post is about error 503, not 404.

The changes to the config file did not produce any error file.

Yes, I know your post is about 503, and that is why my previous reply.
Without more error details we can’t make fixes.

The 404 reference is due to this Security Tab causes error 503

If you get no errors in the wp-content folder after adding the debug log commands to the wp-config.php file, then either the server disables error logging, or there are no errors.
If there are no errors, no 503 can happen either as far I know :slight_smile:
Thus I suspect your host or server turns error logging off in php directive.

But this is just a guess. You could confirm by adding this to your themes functions file:
error_log( print_r("errors are logged", true) );

Now, load your website.
Then, check wp-content folder for the debug log again.
If that produces no error log, then your server or host is blocking it, and you can’t see actual errors either.
A trick then could be to check the server level error logs (access and error logs) for errors.

I was looking in the wrong place. I was looking in /wp-admin for error.php (or whatever it’s called).

I found the debug.log and it shows:

[06-Jul-2021 10:12:30 UTC] errors are logged

The raw access log shows:

GET /wp-admin/security.php HTTP/1.1" 503 719 "

Don’t know if that helps at all.

My host (LightningBase) also uses cPanel and Litespeed. I am not seeing this issue at all; the security tab is working fine, and so is the plugin I have installed there.

Strange. I have two different web hosts using cPanel and the problem occurs on both.

My guess is that either your hosts have updated something recently or that you are running PHP 8 (which I am not and have not tested).

That does not seem to be the (full/complete) error log.

Please copy paste the full error stack here, or into a
It will show more than the line you shared.

Proceed like this:

  1. Please, remove the error_log( print_r("errors are logged", true) ); from your theme file.
  2. Please enhance your debugging commands in the wp-config with this (keep the lines already added, and adde these additional ones)
ini_set( 'log_errors',TRUE );
ini_set( 'error_reporting', E_ALL );
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true );
  1. Trigger the error again (visit the screen that is failing) and then send us the report. The full report, not just some lines of it, but the entire thing (that why you may want to use pastebin if it is large).

As soon we seen an actual error, we will be able to tell the solution.

I did a one-click install on a different server. PHP is 7.4

I got this in the debug.log, but it was created straightaway and not as a result of clicking on the security tab:

[07-Jul-2021 06:58:24 UTC] PHP Notice: ob_end_flush(): failed to send buffer of zlib output compression (0) in /home/xxxxxx/public_html/wp-includes/functions.php on line 3798

Clicking on the tab did not create any further entries.

I have uploaded the raw access log to (deleted)

You can see the 503 error near the end.

I don’t see anything that gives a hint of why the error 503 is triggered.

What you pasted there is the access log, not an error log.

Try disabling output compression in PHP settings, or enabling it if its disabled. Looks like a lack of memory issue to me which is kinda normal for cpanel these days

The red text is from the debug.log and that is the only entry.

There was no error.log created.

I have plenty of memory and this problem happened out of the blue on all my sites that were working fine one day and then started producing the error the next.

I did turn off zlib compression, but it had no effect.

Surely the obvious, five-seconds-thought, non-rocket-science explanation is that cPanel believes the installation is a WordPress one (where security.php does not exist), and has a mechanism to block access to URLs within wp-admin that should not be there.


The access log does not tell any error.
The error log does.
The error log generated by WP by default will be named debug.log
The server error log will NOT be in your WP Install. It will be in your server root level. It usually is named error.log, but, it could be named anything really, just like the WP debug log can be named anything the webmaster or server host wants.

Your server has both, an access and an error log. Always. There is no host without errors, because they log everything, which includes false alarm errors such as when upstream files are requested by hackers that are not there. And that happens daily thus the error log exists, unless your host consciously hides or disables it. At which point I would consider changing hosts.

However, if wp debug does not log any error it is likely a server issue that can’t be read or caught by WP.
Thus, please share the server error log, or ask your host to give it to you (perhaps only the relevant time, so it is not too long.)

The flush error you got there instead is not due to CP or even WP and has nothing to do with the thread here. It is something else, see

If you search for this error you will see it is a common WordPress error, which pops up when you have zlib output compression enabled. Disable it and it should be solved. For more info, do a search on the error, or see this thread:

@zigpress makes a valid point there. However, I’ve never seen cPanel “thinking” for me unless the host configured it to follow some rules. I’ve used cPanel with partial WP installs, with custom codes, etc, and never had any issue, as long there where no rules saying “do not open file XY” or whatever.

I suggest, at this point, asking the host why the file is not opened or why it throws a 404 (for some) and/or why it throws a 503.
The very least they will be able to tell you “there is a PHP error” or “there is a permission issue”

Since the error is not isolated to one person, we cannot simply write this off as “cPanel fault” or “host fault”. It would be something rather common, since more than one person seems affected.

Just thought of another possible experiment.

Try this:

  • add a return; to the top of the file just after <?php
  • reload the security page
  • what do you see/get?

If you still get the precise same issue then the issue is not due to any code in that file but to the file permissions or server not liking the file. If you instead do not get the 503 anymore, then something in the code is causing it.

@smileBeda Adding the return; didn’t fix the problem.

So I uploaded a copy of index.php that I renamed to security.php so there was no content at all. I still got the error.

Tried various permission settings to no avail.

It does appear cPanel doesn’t like that file, because as I said, the error doesn’t occur on a server running Direct admin.

I will contact one of my hosts and tell them what I did and see what they say.

Yes, I did not mean it will fix the problem.
Adding a return simply makes the code stop and return to main thread. That means, each line of code inside that file wont be executed. Thus, if the error still happens, of course, by logic we can now say “the code in that file is not what causes the issue”

It is the file itself, the file name, or else, and only related to the host, not to CP, WP or even else.
I am pretty sure at this point, if you put any such file into any folder of your install it wont work, even if it is named “abc.php”
That means your host secures the install and thinks to know exactly the names and number of files in a given install, thus, blocking any unknown file.

Pretty sure even if you add a file with any non-wp name (such as your-name.php for example) you also wont be able to call it.
If you can call that, but not the file named security.php, then perhaps it has to do with the peculiar name of this file.

However, this shouldn’t be a CP related issue in the sense that it is fixable on CP. Rather, we will be very interested in the solution made by your host as it seems to affect several users (given @azurecurve sees the same).
And that is suboptimal, at least we’d need a notice on the “how to install CP” doc…

Thanks for keeping us in the loop.

1 Like