Guide

WordPress 500 internal server error — how to find the cause in logs

You open your WordPress site and the browser shows nothing but a sterile message: > 500 Internal Server Error No stack trace. No plugin name. No clue. The admin dashboard is gone too — /wp-admin returns the same blank 500.

Anonymized from a real site A small-business WordPress, first hours of monitoring

The site was publishing its user directory by default

At 15:01 UTC, three minutes after the integration started shipping signals, an unfamiliar IP made an unauthenticated request to /wp-json/wp/v2/users/. The endpoint returned an HTTP 200 with the full author list — usernames, slugs, Gravatar hashes — to a caller that had never logged in.

Three minutes after that, the same IP started a 60-request burst against //xmlrpc.php (the leading double slash is a routine bypass for naive .htaccess rules), targeting one of the accounts it had just learned existed. Ten other IPs joined within fourteen minutes. They all converged on the same target account.

The site's security plugin was installed and active. Neither of the two recon endpoints had been disabled by default.

The operator unregistered the REST users endpoint in a small mu-plugin and returned 404 on ?author=N author scans. The harvested usernames remained valid, but a hidden-login plugin made them useless without the login URL.

See what's actually happening in your WordPress system

Connect your site. Logystera starts monitoring within minutes.

Request a demo WordPress integration